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

  1. 02 Aug, 2019 2 commits
    • rswindell's avatar
      Added missing return true; · 0da8188e
      rswindell authored
      0da8188e
    • rswindell's avatar
      There appears to be an issue with QWKnet messages being crossed-up where · b81a0c95
      rswindell authored
      a message is posted to a different conference than the original sub-board with
      completely different header information. I suspect this has something to do
      HEADERS.DAT creation or import - not sure. So I added a "Conference"
      headers.dat field for *messages* (it already existed for votes) and use that
      value to confirm that the message header at the associated offset value in the
      QWK packet has the same conference number as the section in the headers.dat
      file. This is really just a sanity check and will only catch messages that were
      mistakening cross-posted (to a different conference) - *but* it log errors and
      save the bad QWK or REP file for me to examine more closely and see what's
      going on - and the message won't be imported (just "lost", which is also bad).
      
      So added more QWK import success/error checking and logging (especially for QWK
      packets since REP importing already had a lot of stats covered).
      
      Another check would be to store the original message number in the headers.dat
      file as well and use that to confirm that the headers.dat section is the
      correct match for the QWK message at that offset. I did not implement this
      check, yet. The conference number check seems like it'll catch most of the bad
      msgs and lead me to the root-cause.
      b81a0c95
  2. 01 Aug, 2019 1 commit
  3. 26 Jul, 2019 1 commit
  4. 25 Jul, 2019 1 commit
  5. 24 Jul, 2019 1 commit
    • rswindell's avatar
      More UTF-8 goodness: · 52d5659f
      rswindell authored
      - Export all FIDOCTRL (other FTN kludge lines) to the QWK HEADERS.DAT file.
        These should already be imported if they exist, but were never added during
        export, so untested/new behavior. The control paragraph (kludge line) of
        specific interest here is the "CHRS" (charset) kludge we need for UTF-8.
      
      - Don't use the QWK "newline" character (0xE3) when the message is UTF-8.
        Use bare-LF's instead. This is pretty untested at this point as I will need
        another QWKnet board to post or receive UTF-8 encoded messages to test,
        getting the code into CVS is the first step. At least for now, there's no
        opt-in/out for this behavior. If your BBS has UTF-8 encoded messages, some
        QWK nodes or offline readers may have trouble with packets which include
        those messages. Or they may work fine (but likely display garbage CP437
        chars in-place of the proper Unicode codepoint glyph).
      
      - The beginning of UTF-8 input support in getstr() - which needs more work,
        particularly around character and word deletion and insertion.
      - The internal message editor now supports UTF-8 messages and kind of somewhat
        supports inputting UTF-8 characters in message text.
      
      New put/print text flag: P_AUTO_UTF8 which can auto-detect UTF8 strings and
      do the "right thing" for the user's terminal. New associated sbbs_t method:
      auto_utf8() which automatically sets P_UTF8 for any stirng that begins with
      a UTF-8 BOM (ZWNBSP). Else, if the P_AUTO_UTF8 mode flag is set, then
      it checks to see if the string contains invalid US-ASCII chars but valid UTF-8
      sequences and then sets P_UTF8 accordingly. Used by putmsg() and bputs().
      
      There's a new permuation of bprintf() which accepts a mode argument
      (i.e. for P_UTF8) and passes it on to the new mode-capable bputs().
      52d5659f
  6. 10 Apr, 2019 1 commit
  7. 17 Feb, 2019 1 commit
  8. 30 Oct, 2018 1 commit
  9. 03 Oct, 2018 1 commit
  10. 03 Aug, 2018 1 commit
  11. 20 Feb, 2018 1 commit
  12. 31 Jan, 2018 1 commit
  13. 10 Dec, 2017 1 commit
    • rswindell's avatar
      When importing QWK messages from a QWKnet hub, parse/strip all QWK kludge · 5a2fdb23
      rswindell authored
      lines - don't check the (invalid) sbbs_t:useron.qwk settings for QWKE
      support in this case (!).
      If you've been seeing the occasional message with "Subject:" as the first
      line followed by some @-kludge lines (e.g. @MSGID, @TZ, etc.) this would
      be the cause: you have QWKE support enabled on your hub BBS (e.g. VERT),
      which adds the "Subject:" kludge lines for subjects > 25 chars and when
      importing QWK messages from a *hub*, these lines weren't (normally)
      parsed/stripped.
      5a2fdb23
  14. 24 Nov, 2017 1 commit
  15. 12 Oct, 2017 1 commit
  16. 18 Nov, 2016 2 commits
    • rswindell's avatar
      Introduced 2 new poll concepts: · 0ac4f937
      rswindell authored
      - Closures (polls can be closed for new voting by the pollster)
      - Results can have configurable visibility:
        a. Only to voters (and the pollster) - the default
        b. Everyone
        c. Everyone once the poll has closed
        d. Only the pollster
      
      Changes to smb_getmsgtxt():
      Main change: poll questions can now be quoted when replying to a posted poll
      (the results cannot be quoted).
      Also: there's now automatically a blank line inserted between comment header
      fields and poll answers or the msg body text.
      Also: upon any malloc failure, the function now returns NULL.
      New functions: smb_msg_is_from() and smb_addpollclosure().
      0ac4f937
    • rswindell's avatar
      Address 2 QWK/REP-importing security issues: · 0e99d274
      rswindell authored
      1. If QWKE was enabled for the QWKnet account on the Hub, a user could spoof
         their name with a "From:" QWKE kludge line in the message body. Fixed by
         not processing QWKE "From:" kludge lines at all, ever.
      2. If an @VIA kludge line was in the message body, it could over-ride the
         correct value from the HEADERS.DAT (oops). Really, the SENDERNET* lines
         in the HEADERS.DAT were always being overriden by either the @VIA kludge
         line (if present) or just the auto-genereated SENDERNET info (from the
         QWK-ID of the QWKnet account or hub. Normally, in a single hop QWKnet
         message, there will be no @VIA line, so spoofing is still possible in that
         case.
      0e99d274
  17. 06 Dec, 2015 1 commit
    • rswindell's avatar
      QWK import/export now correctly handles the unexpected case of RECIPIENTNETTYPE · 3f587dd7
      rswindell authored
      and RECIPIENTNETADDR fields in messages posted to sub-boards. Apparently
      GoldEd+ does this and it triggered a chain of bugs (mostly cosmetic), but bugs
      that bugged me, so I'm squashing them. Now messages being export to QWK will
      not include the RECIPIENTNETTYPE/ADDR information unless it's netmail.
      Ditto for importing. Also, the net_type is more accurately determined (i.e. if
      there's no '@' in the address, as there not be any expected for QWK and Fido
      net addresses).
      3f587dd7
  18. 23 Nov, 2015 2 commits
  19. 02 Sep, 2015 1 commit
  20. 04 Nov, 2011 1 commit
  21. 19 Oct, 2011 2 commits
  22. 21 Sep, 2011 1 commit
  23. 21 Jul, 2011 1 commit
    • rswindell's avatar
      Complete QWKE support (using MultiMail for testing): · c9f6aaa5
      rswindell authored
      Create and include in packet TOREADER.EXT if QWKEsupport is enabled
      (MultiMail keys of this file for QWKE support, so without, no QWKE features are
      enabled in MultiMail).
      Parse TODOOR.EXT if included in REP packets (for adding/dropping subs or
      setting/resetting pointers).
      Parse To:, From:, and Subject: QWKE kludge lines and use if/when appropriate
      (e.g. to defeat QWK 25-char header field limits).
      Create To:, From:, and Subject: QWKE kludge lines in QWK/REP packets when
      QWKE support is enabled and those fields exceed QWK limits (25 chars).
      Also, legacy SyncQNET kludge lines (@VIA, @TZ, etc.) may now exist in the
      top of the message body in any order.
      Note: current versions of MultiMail do not support "To" fields > 25 chars, even
      in QWKE mode (though I have a patch pending) and do not (yet) support
      Synchronet HEADERS.DAT file (rendering QWKE kludges unnecessary).
      These are major changes in the QWK/REP creation/parsing code, so testing
      (especially with QWKE-compliant offline readers) and bug reports are welcome!
      c9f6aaa5
  24. 09 Nov, 2009 1 commit
  25. 25 Oct, 2009 1 commit
  26. 24 Mar, 2009 1 commit
  27. 20 Mar, 2009 1 commit
    • rswindell's avatar
      ARS improvements: · 1cdf2c10
      rswindell authored
      Added HOST and IP keywords to allow restricted access/privileges to/for
      specific remote hostnames or IP addresses (wildcards allowed).
      All string-argument type ARS keywords (e.g. SHELL, PROT, etc.) now support .can
      style wildcards.
      The current remote client is now used for protocol, host, and IP ARS checking,
      when available, so this requires passing the client pointer around (which
      explains why so many files are touched by this change) and takes care of a
      long standing to-do item (the user's 'modem' value was used for the PROT
      value checking, which was not always correct).
      1cdf2c10
  28. 16 Feb, 2009 2 commits
  29. 15 Feb, 2009 1 commit
  30. 19 Mar, 2008 1 commit
  31. 26 Feb, 2008 1 commit
  32. 25 Feb, 2008 1 commit
    • rswindell's avatar
      The Big Commit: · 73134a2c
      rswindell authored
      * Parses/consumes QWK headers.dat files
        - No more to/from/subj length limits
        - Extensive header details transferred for each message
        - IP/hostname filters (.can files) are applied to appropriate header fields
        - Code cleanup in the QWK functions
      * New functions to read/parse/search filter (.can) files as string lists
        - Performance boost - no need to open/read/close .can file for each message
      * More thread-safe Message-ID retrieval/generation (ftn_msgid and get_msgid)
      * Better Message-ID generation for misconfigured systems (e.g. no hostname)
      ! These changes require the latest smblib and xpdev libraries !
      73134a2c
  33. 21 Sep, 2007 1 commit
  34. 11 Apr, 2007 1 commit
  35. 05 Apr, 2006 1 commit