1. 04 Aug, 2017 1 commit
    • Simon Giesecke's avatar
      Problem: no tests for ZAP handler that has an invalid protocol (#2648) · 4b847f3f
      Simon Giesecke authored
      * Problem: no tests for ZAP protocol errors
      
      Solution: added first test for a bogus version number in ZAP reply
      
      * Problem: no tests for ZAP protocol errors
      
      Solution: added more test cases
      
      * Problem: cannot compile without ZMQ_BUILD_DRAFT_API
      
      Solution: conditionally compile parts that depend on draft API
      
      * Problem: test_security_curve times out in CI
      
      Solution: Increase timeout for this test to 20 seconds
      4b847f3f
  2. 03 Aug, 2017 2 commits
    • Simon Giesecke's avatar
      Problem: Misleading error code in case ZAP handler sends an invalid status code (#2646) · c191909c
      Simon Giesecke authored
      Solution: Use EPROTO instead of EACCES error code in that case
      c191909c
    • Simon Giesecke's avatar
      Replace console output by monitoring events for curve security issues (#2645) · 5d4e30eb
      Simon Giesecke authored
      * Fixing #2002 one way of doing it
      
       * Mechanisms can implement a new method `error_detail()`
       * This error detail have three values for the moment: no_detail
       (default), protocol, encryption.
          + generic enough to make sense for all mechanisms.
          - low granularity level on information.
      
      * Fixing #2002: implementation of the error details
      
      The ZMQ_EVENT_HANDSHAKE_FAILED event carries the error details
      as value.
      
      * Removed Microsoft extenstion for enum member access
      
      This was leading to compilation error under linux.
      
      * Adaptation of CURVE test cases
      
      * Monitoring event: changed API for detailed events
      
      Removed ZMQ_EVENT_HANDSHAKE_FAILED and replaced it by:
      - ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL,
      - ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL,
      - ZMQ_EVENT_HANDSHAKE_FAILED_ENCRYPTION
      
      Adaptation of text case `security_curve`
      
      * Removed event value comparison
      
      This was introduced for the previous API model adaptation
      
      * Removed the prints in std output and added missing details
      
      `current_error_detail` was not set in every protocol error cases
      
      * Fixed initialization of current_error_detail
      
      * Fixed error in greeting test case
      
      The handshake failure due to mechanism mismatch in greeting is actually
      a protocol error. The error handling method consider it like so and
      send a protocol handshake failure monitoring event instead of no_detail.
      
      Fixed the test_security_curve expectation as well.
      
      * Upgraded tests of monitoring events
      
      The tests check the number of monitoring events received
      
      * Problem: does not build under Linux or without ZMQ_DRAFT_API
      
      Solution:
      - properly use ZMQ_DRAFT_API conditional compilation
      - use receive timeouts instead of Sleep
      
      * Problem: duplicate definition of variable 'timeout'
      
      Solution: merged definitions
      
      * Problem: inconsistent timing dependencies
      
      Solution: reduce timing dependency by using timeouts at more places
      
      * Problem: assertion failure under Linux due to unexpected monitor event
      
      Solution: output event type to aid debugging
      
      * Problem: erroneous assertion code
      
      * Problem: assertion failure with a garbage server key due to an extra third event
      
      Solution: changed assertion to expect three events (needs to be checked)
      
      * Problem: extra include directive to non-existent file
      
      Solution: removed include directive
      
      * Problem: assertion failure on appveyor for unknown reason
      
      Solution: improve debug output
      
      * Problem: no build with libsodium and draft api
      
      Solution: add build configurations with libsodium and draft api
      
      * Problem: assertion failure on CI
      
      Solution: change assertion to reflect actual behaviour on CI (at least temporarily)
      
      * Problem: error in condition in assertion code
      
      * Problem: assertion failure on CI
      
      Solution: generalize assertion to match behavior on CI
      
      * Problem: assertion failures on CI
      
      Solution: removed inconsistent assertion on no monitor events before flushing
      improved debuggability by converting function into macro
      
      * Problem: diverging test code for three analogous test cases with garbage key
      
      Solution: extract common code into function
      
      * Problem: does not build without ZMQ_BUILD_DRAFT_API
      
      Solution: introduce dummy variable
      
      * Attempt to remove workaround regarding ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL again
      
      * Problem: EAGAIN error after handshake complete if there is no more data in inbuffer
      
      Solution: Skip tcp_read attempt in that case
      
      * Problem: handshaking event emitted after handshaking failed
      
      Solution: use stream_engine_t::handshaking instead of mechanism_t::status() to determine whether still handshaking
      
      * Include error code in debug output
      
      * Improve debugging output: output flushed events
      
      * Split up ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL into ZMQ_EVENT_HANDSHAKE_FAILED_ZMTP and ZMQ_EVENT_HANDSHAKE_FAILED_ZAP
      
      * Fixed compilation without ZMQ_BUILD_DRAFT_API
      
      * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
      
      * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
      
      * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
      
      * Fixed assert_monitor_event (require event instead of allowing no event)
      Reverted erroneous change to handshaking condition
      Renamed test_wrong_key to test_garbage_key
      Generalized assumption in test_garbage_key to allow for ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL with error == EPIPE
      
      * Better isolate test cases from each other by providing a fresh context & server for each
      
      * Added diagnostic output
      
      * Changed assertion to reflect actual behavior on CI
      
      * Fixed formatting, observe maximum line length
      
      * Fixed formatting, observe maximum line length
      
      * Increase timeout to check if this fixes valgrind run
      
      * Close server with close_zero_linger
      
      * Increase timeout to check if this fixes valgrind run
      
      * Increase timeout to check if this fixes valgrind run
      
      * Generalize assertion to also work with valgrind
      
      * Fixed formatting
      
      * Add more diagnostic output
      
      * Generalize assertion to also work with valgrind
      5d4e30eb
  3. 01 Aug, 2017 1 commit
  4. 31 Jul, 2017 5 commits
  5. 28 Jul, 2017 4 commits
    • Constantin Rack's avatar
      Merge pull request #2636 from bluca/tweetnacl_fd · 4a37ce9a
      Constantin Rack authored
      Problem: tweetnacl on *nix use of /dev/urandom is not thread safe
      4a37ce9a
    • Luca Boccassi's avatar
      Problem: reading from /dev/urandom is clunky · fbb6bbdc
      Luca Boccassi authored
      Solution: if available use the getrandom function as it doesn't
      require any synchronization, state or cleanup
      fbb6bbdc
    • Luca Boccassi's avatar
      Problem: tweetnacl leaks file descriptor on fork+exec · 2626fdfa
      Luca Boccassi authored
      Solution: open with O_CLOEXEC if available or set FD_CLOEXEC if not
      2626fdfa
    • Luca Boccassi's avatar
      Problem: fd leak in tweetnacl with one ctx per thread · e015a0f8
      Luca Boccassi authored
      Solution: add a crypto [de-]initialiser, refcounted and serialised
      through critical sections.
      This is necessary as utility APIs such as zmq_curve_keypair also
      call into the sodium/tweetnacl libraries and need the initialisation
      outside of the zmq context.
      Also the libsodium documentation explicitly says that sodium_init
      must not be called concurrently from multiple threads, which could
      have happened until now. Also the randombytes_close function does
      not appear to be thread safe either.
      This change guarantees that the library is initialised only once at
      any given time across the whole program.
      Fixes #2632
      e015a0f8
  6. 27 Jul, 2017 3 commits
  7. 22 Jul, 2017 2 commits
  8. 17 Jul, 2017 2 commits
  9. 14 Jul, 2017 6 commits
    • Constantin Rack's avatar
      Merge pull request #2625 from trofi/master · e1dfb2e3
      Constantin Rack authored
      configure.ac: allow user to disable libunwind discovery via --disable-libunwind
      e1dfb2e3
    • Sergei Trofimovich's avatar
      configure.ac: allow user to disable libunwind discovery via --disable-libunwind · 88487e7d
      Sergei Trofimovich authored
      on ia64 architecture libunwind comes with gcc. Unfortunately
      libunwind is not directly usable as-is and fails at link time:
      
      ```
          ia64-unknown-linux-gnu-g++ -o perf/.libs/local_lat perf/local_lat.o src/.libs/libzmq.so -lsodium -lrt -lpthread -ldl
          src/.libs/libzmq.so: undefined reference to `_ULia64_step'
      ```
      
      The change adds --{enable,disable}-libunwind flag to control
      automatic dependency. The default is unchanged: use if available.
      Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
      88487e7d
    • Luca Boccassi's avatar
      Merge pull request #2624 from msune/master · dfcf396d
      Luca Boccassi authored
      Problem: adapt, clarify docs ZMQ_ROUTER_MANDATORY
      dfcf396d
    • Marc Sune's avatar
      Problem: adapt, clarify docs ZMQ_ROUTER_MANDATORY · 609c1312
      Marc Sune authored
      Solution:
      
      * Document the new behaviour when generating 'ZMQ_POLLOUT' events
        for ZMQ_ROUTER sockets with 'ZMQ_ROUTER_MANDATORY' set to `1`
      * Add clarifications for 'ZMQ_ROUTER' socket when
        'ZMQ_ROUTER_MANDATORY' is set to `1`
      609c1312
    • Luca Boccassi's avatar
      Merge pull request #2622 from msune/master · bba4a937
      Luca Boccassi authored
      Fix ROUTER's xhas_out() in MANDATORY mode
      bba4a937
    • Marc Sune's avatar
      Fix ROUTER's xhas_out() in MANDATORY mode · b7b89a8f
      Marc Sune authored
      Before this commit, xhas_out() was returning true regardless. This
      was correct before the ZMQ_ROUTER_MANDATORY flag as introduced.
      However, ZMQ_POLLOUT.
      
      With this commit, _if_ ZMQ_ROUTER_MANDATORY is set, xhas_out() will
      return false if ALL peer's outgoing pipes are full.
      
      There is an outstanding high-level design question:
      
      If ZMQ_ROUTER_MANDATORY is set, and zmq_poll() waits for ZMQ_POLLOUT
      events, zmq_poll() will immediately wake up if only 1 pipe has
      room to send, regardless of the peer, creating a busy loop of
      zmq_poll() wake-up, zmq_send() (EAGAIN). There is no way for
      the application to selectively wait for ZMQ_POLLOUT for specific
      peer(s), which seems somehow necessary in ZMQ_ROUTER_MANDATORY.
      
      This discussion will be addressed in a separate issue.
      Signed-off-by: 's avatarMarc Sune <marc@voltanet.io>
      Signed-off-by: 's avatarFredi Raspall <fredi@voltanet.io>
      b7b89a8f
  10. 01 Jul, 2017 2 commits
  11. 29 Jun, 2017 2 commits
  12. 27 Jun, 2017 4 commits
  13. 23 Jun, 2017 2 commits
  14. 22 Jun, 2017 2 commits
  15. 21 Jun, 2017 1 commit
  16. 15 Jun, 2017 1 commit