[zeromq-dev] Vulnerability of devices to incoming messages

[Brian Granger]

I think the core question that this bug brings up is the following:

In what situations do we want a 0MQ process to crash?

Here is my simple answer:  never

You could imagine giving less absolute answers such as:

* Only when sockets are used in unsupported ways.
* Only when a peer does something hostile or stupid.

But in a real life deployment situation, things like this do happen, and
most of the time (or even always) you don't want the process to crash.

In my opinion, the assert caused crashes that occasionally creep up in 0MQ
today are a way of helping us find latent bugs or other problems.  In other
cases, we simply have not decided what to do about the errors and the
asserts are placeholders to help us not forget to do something about it
later.  In the long run, these should all be replaced by more friendly error
handling or minimally by logging (each 0MQ process could have an internal
PUB socket that publishes these things).

Cheers,

Brian

On Wed, Aug 11, 2010 at 12:38 PM, Jon Dyte <jon at totient.co.uk> wrote:

> Matt Weinstein wrote:
> > On Aug 11, 2010, at 3:12 PM, Jon Dyte wrote:
> >
> >
> >> whilst on the subject of devices and the good points made within
> >> this thread
> >> I do have some reservations about these more 'esoteric' uses and the
> >> existing devices.
> >>
> >> initially we had
> >> 1) queue which conventionally takes XREP/XREQ pair
> >> 2) forwarder which conventionally is SUB/PUB
> >> 3) streamer which is UPSTREAM/DOWNSTREAM (or it's renames!)
> >>
> >> as people are pointing out it's quite possible to combine sockets of
> >> other types in the devices
> >> as well as connect other-than-intended peer sockets. some of these are
> >> really insightful ideas
> >> but i do wonder whether the 'core' devices shouldnt stick to intended
> >> sockets.
> >>
> >>
> >
> > In theory, you could do this:
> >
> > [[[ clients ]]] [ REQ ]* --- [ XREP ]  [ DEVICE ]  [ PAIR ] =/\/\/
> > (network)\/\/\= [ PAIR ]  [ DEVICE ] [ XREQ ] --- [ REP ]*
> > [[[ servers ]]]
> >
> > and it should work and be "standard" relative to the specs.
> >
> >
> >> Most of the other uses seem to have involved people writing new code
> >> as
> >> well which is fine,
> >> because I don't think these devices should cater for all situations,
> >> but
> >> equally not crash ....
> >>
> >>
> >
> > Standard devices are fine, but cannot be overly restrictive, because
> > they only have limited information.
> >
> > Don't forget a lot of the solutions out on this list are laboratory
> > specimens, and there's a bit of experimentation and caveat emptor if
> > you overshoot the limits.
> >
>
> Yes I realise, this, I think some the of uses posted are wonderful and
> clever.
>
> I have been looking at yr zmq_reactor for  example, because I think it
> could make writing more
> complex interactions simpler.
> > The crash occurred because an input specification was not met.   There
> > are several ways to fix that within the current architecture.
> > Ensuring it "stays fixed" crosses the old invisible line between
> > "coding" to "systems engineering".
> >
> > So far, I've been delighted with what ØMQ can achieve "out of the box"
> > and would have had to reinvent the paradigms if they weren't already
> > present.
> >
> >
> I think what you get out of the box is excellent and fairly easy to get
> going with.
>
> >> I was under the impression that the sockets exchanged a 1 byte message
> >> on connection. Could
> >> they also check they are compatible and terminate the connection if
> >> not?
> >>
> >> jon
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >
> > Best,
> >
> > Matt
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/d46d1a45/attachment.htm>