[zeromq-dev] curve public key distribution (and zyre?)

[Wes Young]

[i’m kinda sorta thinking out-loud here, seeing if this strikes a chord with 
anyone, see if i’m missing something stupid here..]

i’m wondering if anyone has examples (or war-stories) of this in the wild 
distributing curve public keys outside of what the doc thus far spec’s… the 
good, bad, ugly? short of posting them in a binary[1], or to a web page, maybe 
creating a public side channel (good ole REQ/REP) that hands out the key sorta 
like pgp.mit.edu does for GPG. let’s also assume at this stage, you don’t care 
who’s on the network, just that the traffic is encrypted (push those other 
problems higher up the stack for the time being).

i’ve dug through some of the archives which talks a little about the theory 
between CA’s and WoTs, thinking about this from a Zyre[2] perspective where it 
may be less easy to keep track of all the public keys. course if you’ve messed 
with zyre and/or gossip at all, one of the things that first pops to mind is 
setting a header for the gossip traffic that not only highlights the endpoint, 
but the public cert of that end-node.. which seems logical, just a matter if 
it’s rational (again, if you don’t care who’s on the network) and where to 
bootstrap the initial gossip traffic (if you wanted to TLS gossip and the 
initial connection). this doesn’t work well in beacon, but that may be a non 
issue for other reasons.

+ connect to initial gossip node via non gossip channel that hands you it’s 
public key
+ connect to gossip channel with public key (assume we’ve patched czmq to deal 
with this at the socket level)
+ work gossip through encrypted channel
+ pull down list of peers and each of their public keys
+ connect to peers directly since we have their public keys

i think some of the answers are contained within the 2015-January thread, just 
curious if there were more war-stories out there, what works, what doesn’t, 
etc..


[1] http://lists.zeromq.org/mailman/private/zeromq-dev/2014-April/025394.html
http://lists.zeromq.org/mailman/private/zeromq-dev/2015-January/027703.html
http://lists.zeromq.org/mailman/private/zeromq-dev/2015-June/028551.html

[2] https://github.com/zeromq/pyre/issues/94
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What is the canonical handling of zeromq sockets when fork+exec?

[Luca Boccassi]

On Fri, 2016-11-25 at 12:22 +0100, zmqdev wrote:
> On 25.11.2016 11:50, Luca Boccassi wrote:
> > What I can say is that we have a unit test for this situation:
> >
> > https://github.com/zeromq/libzmq/blob/master/tests/test_fork.cpp
> >
> > And the child closes the (TCP) socket explicitly before the context.
> > Which is in fact what should happen in all cases.
> >
> > The parent then can receive messages on the sockets just fine.
> >
> > Maybe it's a linger issue? By default a socket has 30s of linger grace
> > period.
> >
> > Try setting ZMQ_LINGER to 0 in the socket in the child, close the socket
> > and then terminate the context perhaps.
> 
> thanks. Formatted differently:
> 
>   1. zmq_close sockets in child (perhaps setting ZMQ_LINGER to 0 
> beforehand)
>   2. zmq_term context in child
> 
> and only then
> 
>   3. close rest of file descriptors in child
> 
> The reason I went directly to point 3 is this line from the man page of 
> fork(2):
> 
>  The child process is created with a single thread—the one
>  that called fork().
> 
> (see http://man7.org/linux/man-pages/man2/fork.2.html)
> 
> Michael Kerrisk in "The Linux Programming Interface" insists:
> 
>  When a multithreaded process calls fork(), only the calling thread is
>  replicated in the child process. (The ID of the thread in the child 
> is the
>  same as the ID of the thread that called fork() in the parent.) All 
> of the
>  other threads vanish in the child; no thread-specific data 
> destructors or
>  cleanup handlers are executed for those threads.
>  (...)
> 
> Of course, that's where I run into the problem?!

Yes I suspect the background I/O thread suddenly going missing might
have caused issues.

Did setting the linger and closing the socket help?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Call for maintainers [JeroMQ, JZMQ]

[Luca Boccassi]

Hi Colin,

Being a ZeroMQ maintainer is easy and fun and I definitely recommend
it :-)

The actual maintainer role is well codified in the C4 process that
Trevor mentioned and it's very simple in the end.

And if you have used the library for a long time I'm sure you'll do a
great job developing it further.

So if you are interested let us know and we can add you as a maintainer
in the organization.

Thanks!

On Tue, 2016-11-22 at 11:20 -0400, Trevor Bernard wrote:
> Colin,
> 
> You can read about the responsibilities in the C4 contract:
> https://rfc.zeromq.org/spec:42/C4.
> 
> -Trev
> 
> On Mon, Nov 21, 2016 at 8:09 AM, Colin Ingarfield  
> wrote:
> > Hi Trevor,
> >
> > I've been a user of jeromq for several years.  I might be interested in
> > maintaining it, but can you describe some more what would be required?
> > I'm a professional java developer and feel I have a good understanding
> > of jeromq, but I don't know its internals that well.
> >
> > Thanks,
> > Colin
> >
> > On 11/20/16 2:53 PM, Trevor Bernard wrote:
> >> Hi all,
> >>
> >> I've been happily the steward for ZeroMQ on the JVM for many years now
> >> but unfortunately, I don't have the time or energy to give these
> >> projects the attention they needs. I'm looking for someone to step up
> >> and take over managing the releases to Maven Central. I will help
> >> ensure a smooth transition but I will unfortunately take an indefinite
> >> leave from jzmq/jeromq. It's been a blast but it's time to move on.
> >>
> >> Warmest regards,
> >> Trevor
> >> ___
> >> zeromq-dev mailing list
> >> zeromq-dev@lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev