You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that pymacaroons requires that caveats are valid utf8 strings. Is there a reason for that?
It appears like most of the implementations/examples of Macaroons expect that you're going to create some sort of arbitrary text based DSL for your caveats, but I've preferred to use actual real serialization formats because they're going to handle the various edge cases in a much cleaner fashion than any DSL I make is going to be able to. Readability of the raw bytes of a Macaroon caveat doesn't seem to be of huge importance to me, since you're going to need some tooling to decode the Macaroon to get access to the caveats to begin with, that same tooling can just present the caveats in a more human friendly way.
However, since there is a hard check that the bytes of a caveat are valid utf8, that severely limits the choices of serialization formats to only ones that guarantee that their output is valid utf8. We've currently been using json for this, but since the size of the serialized caveats affects the size of the final macaroon we've been trying to minimize the size of our caveats where possible, and using an alternative serialization format besides JSON is one of the options we're considering.
Is there a reason why caveats need to be valid utf8 strings, or can this restriction be relaxed to support arbitrary bytes?
The text was updated successfully, but these errors were encountered:
Note: It looks like the requirement for utf8 caveats might come from v1 serialization, but pymacaroons doesn't seem to limit this restriction to only v1, and just unconditionally requires it.
It appears that pymacaroons requires that caveats are valid utf8 strings. Is there a reason for that?
It appears like most of the implementations/examples of Macaroons expect that you're going to create some sort of arbitrary text based DSL for your caveats, but I've preferred to use actual real serialization formats because they're going to handle the various edge cases in a much cleaner fashion than any DSL I make is going to be able to. Readability of the raw bytes of a Macaroon caveat doesn't seem to be of huge importance to me, since you're going to need some tooling to decode the Macaroon to get access to the caveats to begin with, that same tooling can just present the caveats in a more human friendly way.
However, since there is a hard check that the bytes of a caveat are valid utf8, that severely limits the choices of serialization formats to only ones that guarantee that their output is valid utf8. We've currently been using json for this, but since the size of the serialized caveats affects the size of the final macaroon we've been trying to minimize the size of our caveats where possible, and using an alternative serialization format besides JSON is one of the options we're considering.
Is there a reason why caveats need to be valid utf8 strings, or can this restriction be relaxed to support arbitrary bytes?
The text was updated successfully, but these errors were encountered: