On Fri, 2017-07-14 at 08:55 -0400, Wes Young wrote: > > 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?e > xpand=1 > https://github.com/zeromq/czmq/compare/master...wesyoung:feat/curve?e > xpand=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.
Looks very interesting! I would recommend using actor calls rather than overloading. The endpoint format is already very overloaded and a bit confusing as it is, having clear API calls is much cleaner and understandable for users and developers IMHO. > > 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. 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. > > 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 > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
