Skip to content
Snippets Groups Projects
  1. Feb 08, 2025
    • Rob Swindell's avatar
      Native JS methods must return JS_FALSE for (Error) exceptions to be thrown · 6ed4a05f
      Rob Swindell authored
      I discovered the first case when FileBase.get_path() failed, but didn't
      (immediately) throw an exception. Reviewing the other instances of
      JS_RepoertError() calls found several that either reported a garbage (e.g.
      NULL) string value or returned JS_TRUE.
      
      The design pattern used a little in js_socket.c probably should be used more:
      
      	if (JS_IsExceptionPending(cx))
      		return JS_FALSE;
      	return JS_TRUE;
      
      ... but that's more of a refactor than I had the stomach for right now.
      6ed4a05f
  2. Feb 05, 2025
  3. Feb 03, 2025
  4. Feb 02, 2025
  5. Feb 01, 2025
  6. Jan 21, 2025
  7. Jan 15, 2025
  8. Jan 14, 2025
  9. Jan 07, 2025
    • Deucе's avatar
      Fix apparent copy pasta of the total/len in recv. · a4c676ed
      Deucе authored
      a4c676ed
    • Deucе's avatar
      Fix TLS short send issue. · bf7ad258
      Deucе authored
      On JS TLS sockets, sends over 16384 bytes would be truncated to
      the next multiple of 8192 higher than half the buffer length.
      
      This was triggered because we send chunks of 8192 bytes at a time,
      and decrement the length each time through the loop.  We return
      "success" when the total sent so far is higher than the length
      remaining.
      
      Fixes bug reported in #Synchronet by Accession.
      bf7ad258
  10. Jan 06, 2025
  11. Jan 05, 2025
    • Deucе's avatar
      Remove sendfilesocket() and recvfilesocket() · 951c22af
      Deucе authored
      Make js_socket_sendfilesocket() suck a lot less.
      This commit brought to you with limited rants by Synchronet 3.20b
      
      "Warning: Your BBS may become habit forming."
      
      You could run Synchronet or you could settle for mediocrity.
      
      Once in a great while, there comes BBS software that really makes waves.
      Get out your surfboard.
      
      The best BBS software is the most expensive BBS software.
      NOT!
      
      If you had three wishes, you could toss the other two.
      
      They couldn't top Synchronet.  So we did.
      
      Accept the inevitable, switch to Synchronet
      951c22af
  12. Dec 02, 2024
  13. Nov 12, 2024
  14. Nov 10, 2024
    • Rob Swindell's avatar
      Don't check recvline() timeout *before* checking if there's data to receive · f1cdaea3
      Rob Swindell authored
      This was a regression: Socket.recvline() used to not care what the timeout
      duration was so long as there were bytes to receive.
      
      Also, remove the ".0" from timeout values in documented mehtods that don't
      (any longer) accept floating point timeout durations. We used to support
      fractional seconds for some of these methods, and that was implied by using
      the floating point default values, but that's no longer the case. poll()
      still accepts a floating point timeout.
      f1cdaea3
  15. Oct 03, 2024
  16. Aug 08, 2024
    • Rob Swindell's avatar
      Prevent NULL pointer dereference when 'null' object passed to JS functions · 54523145
      Rob Swindell authored
      As was discovered as part of investigation into issue #769, a JavaScript
      could crash SBBS (cause a segfault) due to a NULL pointer dereference when
      the script passes 'null' to native JS functions where an object is expected.
      
      The issue raised was with console.gotoxy(), but it turns out that *many*
      Synchronet native JS functions would call JSVAL_TO_OBJECT() and then, without
      checking for NULL/nullptr, pass its return value to JS api functions such as
      JS_GetPrivate, JS_GetProperty, JS_GetClass, JS_ObjectIsFunction,
      JS_IsArrayObject, JS_GetArrayLength, JS_DefineProperty, JS_Enumerate, etc.
      All of these JS API functions dereference the passed object pointer without
      NULL/nullptr checking.
      
      The fix here is to either call JSVAL_IS_NULL() or JSVAL_NULL_OR_VOID() and
      if true, not call JSVAL_TO_OBJECT() and/or check the return value for the NULL
      value before using as an argument to any other JS API functions.
      54523145
  17. Feb 24, 2024
    • Rob Swindell's avatar
      Report getaddrinfo() failure result in Socket.error and error_str (not errno) · 6a5cf7f6
      Rob Swindell authored
      As Nelgin pointed out, a Socket.connect() failure for reasons of address/host
      lookup failure would report a stale/nonsense Socket.error/error_str value.
      
      This change required us to query/store the socket API/getaddrinfo error string
      at the time of failure (for the Socket.error_str property value) rather than
      converting from number to string at the time the property is read.
      
      This does mean that sometimes Socket.error is a errno value and sometimes its
      a getaddrinfo (EAI_*) error value. Since the EAI_* values are negative, it
      should be obvious which is which.
      6a5cf7f6
  18. Jan 21, 2024
  19. Jan 20, 2024
    • Rob Swindell's avatar
      The great BOOL->bool conversion in xpdev · 118984e9
      Rob Swindell authored
      Still using BOOL where we need Win32 API compatibility.
      Using JSBool instead of BOOL or bool where it matters.
      Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).
      
      You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
      Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.
      
      For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).
      
      I didn't convert UIFC yet.
      
      This addresses issue #698
      118984e9
    • Deucе's avatar
      Only tls servers should call destroy_session() · 4ce3dfab
      Deucе authored
      TLS clients don't (currently) add a certificate, so there's no need
      to delete it.
      4ce3dfab
    • Deucе's avatar
      Don't call destroy_session() until after add_private_key() · bc564c22
      Deucе authored
      Use cryptDestroySession() instead.
      bc564c22
    • Deucе's avatar
      Ugh, spaces instead of tabs... so gross. · 70ccc5a6
      Deucе authored
      70ccc5a6
  20. Dec 31, 2023
  21. Dec 23, 2023
  22. Dec 21, 2023
    • Rob Swindell's avatar
      Change ssl.c API to include an lprintf callback function for proper logging. · 69eb741b
      Rob Swindell authored
      The JS objects will still log to the terminal server (regardless of which server created/used the objects) however - so that's still a TODO.
      Change do_cryptInit() to return bool, since it does.
      Log detailed error if pthread_once() call fails.
      Lowered-severity (to DEBUG) the log messages related to TLS private key and cert creation and destruction.
      
      FIrst commit from within MSVS, so this might look weird.
      69eb741b
  23. Dec 20, 2023
    • Deucе's avatar
      get scfg from runtime before syncing cert · 6dde3ce2
      Deucе authored
      6dde3ce2
    • Deucе's avatar
      Fix invalid pointer type waring (and bug) · b430c2f3
      Deucе authored
      b430c2f3
    • Deucе's avatar
      Fix TLS handbrake/hang/crash issue · 97680179
      Deucе authored
      Private key objects in cryptlib are not copied into sessions when
      they're added, only the refcount is incremented.  These objects
      contain a bignum context, which therefore ends up shared across all
      instances of the private key.  Unfortunately, the locking is on the
      session context, not the private key objects, so shared bignum contexts
      can cause memory corruption.
      
      Further, even if the locking issue was fixed, the performance handbrake
      would still exists... activating sessions that use the same private key
      would be serialized, with the results we've been seeing lately.
      
      With this, each session gets a unique private key, which is loaded
      from the file.  When a session is finished with the key, it is cached
      in a list with an epoch, so when the date on the key file changes, old
      private keys will be eliminated.
      
      While this solves a lot of issues, logging of certificate generation
      and loading issues has regressed to the point where it's effectively
      not done at all. Logging was previously passed back to the caller,
      but given the much longer call chain to get to where a cert is created,
      the extra parameters was just too much. Something better should be
      done here at some point.
      97680179
  24. Dec 19, 2023
    • Deucе's avatar
      Fix locking for JS TLS connections · 178ebf28
      Deucе authored
      Also, expand the lock in websrvr to the correct scope.
      178ebf28
    • Deucе's avatar
      Now that we have a rwlock, extend it back to where it was. · 7695d05b
      Deucе authored
      We'll hold a reader lock under the session is established, which
      should prevent blocking other threads unless something is beating
      on get_ssl_cert() (which would be a different bug).
      
      This still needs to be figured out, but at least this should fix
      the immediate issue.
      7695d05b
    • Deucе's avatar
      Only mutex proect tls_certificate usage. · ab8d98a7
      Deucе authored
      Holding the lock around session establishment should not be needed,
      but we need to protect tls_certificate read and usage.  Since we
      don't have rwlocks in xpdev (yet?), hack together a crappy rwlock
      that does what we need.
      ab8d98a7
  25. Nov 22, 2023
Loading