On Thu, 2017-08-17 at 08:51 -0400, Wes Young wrote:
> i think i did this right, but not sure- first time PR’ing to RFC:
> 
> https://github.com/zeromq/rfc/pull/123
> 
> i’m still doing testing in my local ZYRE branch to make sure this RFC
> “works IRL”, but effectively the gist is:
> 
> https://github.com/wesyoung/rfc/commit/8fbebfa8e326701458b3282246ef92
> a20dba38af
> 
> which adds a 32-byte field to the end of a beacon packet. in the
> implementation, if you have “curve enabled” zyre will ignore non v3
> packets (eg: v2 packets) to avoid downgrade. if you don’t have curve
> enabled (eg: no public key set), it’ll accept v2 packets.
> 
> the zyre bits themselves mostly work- just cleaning up some of my
> rusty C work and checking for leaks. also- because the protocol
> version is changing, trying to stumble my way through re-creating the
> protocol bits with zproto(?) which is a bit awkward. need to do some
> more reading (unless im missing something stupid here..).
> 
> comments welcome,

Looks great, thanks!

The only comment I have, as I've written on the PR, is whether the
requirement to ignore v2 packets when CURVE is enabled should be
upgraded from SHOULD to MUST, given the security implications.

> > On Jul 15, 2017, at 5:38 AM, Luca Boccassi <[email protected]
> > > wrote:
> > 
> > > > Perhaps add it as an option, but fail hard if it is enabled and
> > > > the
> > > > peer does not support it. This way backward compatibility by
> > > > default
> > > > can be saved, but if enabled it's robust against downgrade.
> > > 
> > > i like this idea. may run with it a bit. it’s *probably* a new
> > > version of the RFC, just to be consistent, and then doing what
> > > you
> > > describe, make sure it’s not a default, but that you set it and
> > > it
> > > locks down. if only to see how it reacts in the wild.
> > 
> > It would be a new RFC yes, but it's fine, we can create version as
> > DRAFT and follow the usual process. Feel free to send a PR to
> > create it
> > in zeromq/rfc, doesn't matter if it's rough on the edges, we can
> > iterate as needed.
> 
> --
> wes
> wesyoung.me
> 
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- 
Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to