Synchronet now requires the libarchive development package (e.g. libarchive-dev on Debian-based Linux distros, for more info) to build successfully.

  1. 15 Aug, 2019 1 commit
  2. 06 Aug, 2019 3 commits
  3. 05 Aug, 2019 3 commits
  4. 04 Aug, 2019 2 commits
  5. 21 Jun, 2019 1 commit
    • deuce's avatar
      Fix handling of responses with no content. · b311c1c3
      deuce authored
      This introduces a new request field send_content which indicates if the
      content should be sent.  This covers various cases like HEAD responses
      where there's an entity, but no content is sent as well as 204, 304, and 1xx
      responses where there is not even an entity.
      writebuf() will now enforce this, so there's no need for various checks
      throughout the code to see if data should be sent or not.
      Also, we now only set sent_headers after the headers are sent.
  6. 04 May, 2019 2 commits
    • rswindell's avatar
    • rswindell's avatar
      Define and use a wrapper for JS_GetInstancePrivate(): js_GetClassPrivate() · 6f83c4ff
      rswindell authored
      Use this in place of JS_GetPrivate() in native class methods that need the
      class instance's private data pointer and will do bad things if that pointer
      points to something other than what is expected. mcmlxxix (matt) discovered
      that using Object.apply(), you can invoke class methods where the 'this'
      instance is a different class. This would result in
      "Internal Error: No Private Data." or a crash.
      So now, gracefully detect this condition and report a meaningful error:
      "'<class-name>' instance: No Private Data or Class Mismatch"
      Also, important to note: if the method uses JS_THIS_OBJECT to get the JSObject*
      to pass to JS_Get*Private, then it must do this *before* it calls JS_SET_RVAL.
      From jsapi.h:
       * NB: there is an anti-dependency between JS_CALLEE and JS_SET_RVAL: native
       * methods that may inspect their callee must defer setting their return value
       * until after any such possible inspection. Otherwise the return value will be
       * inspected instead of the callee function object.
      The js_crypt*.c files still need this treatment.
  7. 07 Mar, 2019 1 commit
    • deuce's avatar
      There appears to be data corruption in cryptlib if a private key is added · 211a2a1a
      deuce authored
      to a second thread before the first has the session set active.  Add calls
      to lock/unlock the certificate to prevent this.
      The better options is likely to have a function that adds the key and socket
      and sets the session active in one call and handles the locking internally.
      But I'm lazy, so we get the lock functions.
  8. 12 Jan, 2019 1 commit
    • rswindell's avatar
      Bug-fix: Socket.connect() would return true (success) even though a · 7685c9d7
      rswindell authored
      TCP connection actually failed. This bug only appeared to affect *nix
      systems. This bug appears to be very old, introduced in rev 1.74 of
      this file (Mar-2003) by yours truly.
      From the Linux 'connect' man page:
                    The  socket  is  nonblocking  and the connection cannot be i
                    completed immediately.  It is possible to select(2) or poll(2)
                    for completion by selecting the socket for writing.  After
                    select(2) indicates writability, use getsockopt(2) to read the
                    SO_ERROR option at level SOL_SOCKET to determine whether
                    connect() completed successfully (SO_ERROR is zero) or
                    unsuccessfully (SO_ERROR is one of the usual error codes listed
                    here, explaining the reason for the failure).
      We weren't doing the 'getsockopt(SO_ERROR)' part.
  9. 07 Jan, 2019 1 commit
  10. 14 Aug, 2018 2 commits
    • rswindell's avatar
      Fix-up js_recvline() based on infinite error/log message report from Nelgin: · 13d22506
      rswindell authored
       term 0087 TLS ERROR 'Unexpected <Unknown type> (24) packet, expected application_data (23)' (-1) popping data
       message repeated 492 times: [ term 0087 TLS ERROR 'Unexpected <Unknown type> (24) packet, expected application_data (23)' (-1) popping data]
      When using TLS with a JS Socket object, if there was any kind of data error,
      the recvline() method would return a blank string rather than null/undefined.
      nntpservice.js just loops when it receives a blank string, so this caused an
      infinite loop (with disk-filling error log messages).
      First change: if no data has been received (i == 0) and there's any kind of
      receive error or timeout or disconnection, just return null. And not undefined,
      but null (!) like in v3.15 (before the great JS engine update of 2000-mumble).
      Also, there appeared to be a JS_RESUMEREQUEST call missing in the TLS error
      return case - so that's another bug fixed.
      Commented on the magic return values for js_sock_read_check()
      and js_socket_recv().
      Simplified js_sock_read_check() return value a tad: let the caller decide if
      they want to do something special based on the value of 'i'.
      Added some comments to make this code more readable.
      We are now no longer treating the different error return values (0 and -1) from
      js_socket_recv() special in this function, but we dont' treat them special in
      any of the other calls in this file/object either, so that seems to be the
    • rswindell's avatar
      The timeout parameter to js_socket_recv() is in seconds. I don't think · 8de4c1b7
      rswindell authored
      Deuce really wanted to pass 1000 as a value here (use 1 instead). I don't
      know if this was an observable problem or not, but it certainly *looks*
      like a bug.
  11. 08 Jul, 2018 2 commits
  12. 19 Mar, 2018 2 commits
  13. 18 Mar, 2018 1 commit
  14. 16 Mar, 2018 1 commit
  15. 15 Mar, 2018 8 commits
  16. 13 Mar, 2018 2 commits
  17. 12 Mar, 2018 1 commit
  18. 11 Mar, 2018 1 commit
  19. 10 Mar, 2018 5 commits