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/8fbebfa8e326701458b3282246ef92a20dba38af 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, > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
