Well, I discovered an issue with 'repeated Enum flags' in protobuf
(KUDU-1850). But I went with an appropriate workaround.
You can find the complete patch here: https://gerrit.cloudera.org/#/c/5796/
Please take a look.
-Todd
On Wed, Jan 25, 2017 at 3:35 PM, Dan Burkert wrote:
> On Wed, Jan 25
On Wed, Jan 25, 2017 at 3:33 PM, Alexey Serbin wrote:
>
> Or it's proposed that if new
> fields are found in a token then don't accept the token at all? In that
> case it might be an issue during rolling upgrade, I think.
>
That's what I was thinking, but that's a good reason not to do it that
w
Probably we could, but I didn't make my research on that yet. Will need to
tinker a bit with that to get better understanding. At least I know that
in proto3 the unknown fields are no longer present when serializing
previously de-serialized message:
https://developers.google.com/protocol-buffe
Yea, that's a good idea. It's sort of like the 'critical' attribute in
X509. "If a reader sees an attribute listed as critical, and it doesn't
know what to make of it, don't accept the cert".
I'll add a repeated enum for this even though it will be empty for now.
On Wed, Jan 25, 2017 at 3:14 PM,
That's an interesting idea - say if the format evolved to have an
additional field which restricts use of the token? Could we use the
protobuf unknown fields API to recognize if this happened?
- Dan
On Wed, Jan 25, 2017 at 3:03 PM, Alexey Serbin wrote:
> I like this idea.
>
> Probably, that's
I like this idea.
Probably, that's too early at this point, but consider adding notion of
compt/non-compat feature flags into tokens. Imagine the new version of
token has some additional restriction field, which older code does not
understand. In that case, even if the token signature is correct
On Wed, Jan 25, 2017 at 12:52 PM, Todd Lipcon wrote:
> Actually had one more idea... how about:
> message AuthenticationToken {
> };
>
> message AuthorizationToken {
> };
>
> message TokenPB {
> // The time at which this token expires, in seconds since the
> // unix epoch.
> optional int64
On Wed, Jan 25, 2017 at 12:40 PM, Dan Burkert wrote:
> I think it must go in the 'token_contents' itself, otherwise it can be
> modified by a malicious client. Other than that, looks good.
>
>
well, if it went into a separate field, then we'd have something like:
optional bytes token_contents =
Actually had one more idea... how about:
message AuthenticationToken {
};
message AuthorizationToken {
};
message TokenPB {
// The time at which this token expires, in seconds since the
// unix epoch.
optional int64 expire_unix_epoch_seconds = 1;
oneof token {
AuthenticationToken aut
I think it must go in the 'token_contents' itself, otherwise it can be
modified by a malicious client. Other than that, looks good.
- Dan
On Wed, Jan 25, 2017 at 12:37 PM, Todd Lipcon wrote:
> Hey folks
>
> I'm working on the token signing/verification stuff at the moment. Curious
> to solicit
Hey folks
I'm working on the token signing/verification stuff at the moment. Curious
to solicit some opinions on this:
message TokenPB {
// The actual token contents. This is typically a serialized
// protobuf of its own. However, we use a 'bytes' field, since
// protobuf doesn't guarantee
11 matches
Mail list logo
