> On Jul 13, 2017, at 1:54 PM, Luca Boccassi <[email protected]> wrote: > > As usual I would suggest to follow our process, and send a PR with what > you have as DRAFT.
ack. did a first pass with #ifdef DRAFT, etc… now starting to clean up the gsl/xml bits and test to make sure the headers are correct.. have a sep build process parallel to yours on opensuse to test this in our live env while we figure out the nuances [for those that want to play along]. https://github.com/zeromq/zyre/compare/master...wesyoung:feat/curve?expand=1 https://github.com/zeromq/czmq/compare/master...wesyoung:feat/curve?expand=1 the thing i’m trying to work around is creating too many custom headers (which is easy todo, just looks awkward). so first attempt is/was to overload the SET/CONNECT variables and pick them apart before we connect/bind. which doesn’t break zmq_bind|zmq_connect but it does make the actors a little less … consistent. i have a feeling, for the sake of consistency the better way is going to be setting each of the keys via the normal actor calls [which we started out doing, just more code vs overloading the endpoint SET] and passing the vars through the headers to the correct functions. there are a few [simple] zcert functions that i think are no-brainers to PR sooner than later, just cleaning up the obvious gsl/xml stuff there too. > I don't think the zbeacon protocol change can be made backward > compatible unfortunately, as the library checks for the exact size of > the beacon, and discards if it doesn't match. > > Also not sure it should in the first place - given it's a security > feature, it would open up to a downgrade attack. There were CVEs in > libzmq with the exact same problem when Curve was first introduced. that makes sense. i kinda figured i was playing with fire on that one, but exploring the idea, getting it to work, etc. i hate having to do so much manual work (exchanging keys, etc) just to test stuff. it’s a pita (like having to remember wifi keys for basic tls functions). i get why, trying to think outside the box. back to the drawing board. > 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. > Also note that it's not only on a local network anymore, zbeacon > supports IPv6 multicast and although rare and difficult, it is possible > to use it beyond the LAN boundaries. you should see the env we’re testing this in (*heavily* Internet2 enabled ;), which is sorta why i’m asking some of these questions..). thanks for this, very helpful :) -- wes wesyoung.me
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
