On Sep 2, 2013, at 9:25, Pieter Hintjens <[email protected]> wrote:
> MinRK, > > I've just pushed a patch that fixes authentication for PLAIN and > CURVE, and updated the test cases to match. > > It all works as expected... :-) > > One thing about CURVE authentication; client keys are passed to the > ZAP handler as 32 binary bytes. I'm wondering whether it would be > nicer to pass Z85 text strings instead, as everything else in ZAP is > text. I expect keysstored in databases and files to be in Z85, not > binary... any thoughts? I would leave it as bytes, personally. To me, z85 is convenience format for humans / text-only storage. If the keystore stores keys that are not raw, I would expect the zap_handler to be responsible for the conversions. > > -Pieter > > > On Sun, Sep 1, 2013 at 7:14 PM, Pieter Hintjens <[email protected]> wrote: >> That seems the simplest and cleanest result. We'll get authentication >> failed events via the ZAP handler, and we might see connection failed >> event at the client side too (via context monitor) but these should be >> invisible to message processing. >> >> -Pieter >> >> On Fri, Aug 30, 2013 at 11:50 PM, MinRK <[email protected]> wrote: >>> >>> >>> >>> On Fri, Aug 30, 2013 at 1:37 PM, Pieter Hintjens <[email protected]> wrote: >>>> >>>> On Thu, Aug 29, 2013 at 1:32 AM, MinRK <[email protected]> wrote: >>>> >>>>> Thanks. By closed, you mean the connecting peer (client) should be >>>>> closed, >>>>> or the inner pipe on the server side? What should be the user-visible >>>>> symptoms of failed authentication, both on the client side and the >>>>> server >>>>> side, if any? I'm looking to add a failed-auth test to test_security, >>>>> but it >>>>> is unclear to me what the expected behavior is. Is the symptom only >>>>> that >>>>> messages sent do not arrive, or should sending a message not succeed in >>>>> the >>>>> first place? >>>> >>>> I think the net result of a failed authentication should be the same >>>> as if there was no network connection; no pipes created on either side >>>> of the connection, and no route to or from the unauthenticated client. >>> >>> >>> Thanks - so as far as the connecter is concerned, it is as if the peer is >>> unavailable, >>> and for the binder, it is as if nobody connected. >>> >>>> >>>> >>>> -Pieter >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
