• src/sbbs3/sbbsecho.c

    From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Thursday, February 16, 2023 00:01:50
    https://gitlab.synchro.net/main/sbbs/-/commit/6fb20b919003c805a40c207c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Resolve signed/unsigned compare warning with MSVC

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Saturday, February 18, 2023 12:59:30
    https://gitlab.synchro.net/main/sbbs/-/commit/ccfad124e104b09bf825392e
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    More consistent 'exact' parameter values to findnodecfg() - e.g. false, not 0

    No functional change.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Saturday, February 18, 2023 12:59:30
    https://gitlab.synchro.net/main/sbbs/-/commit/15b230af547ff5932c6073e5
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Rework NetMail routing logic to handle point destinations better

    With this commmit, the logic is now:

    If the NetMail destination is a point and there's no linked-node for it
    and the boss node for this point is not one of our AKAs
    then route to the boss node (no linked-node match needed)
    if the boss node matches a linked-node with a route configuration
    then route to that configured route destination (2-levels of routing
    and thus 2 "Routing NetMail" msgs will be logged in this scenario)

    If the NetMail destination is a point and there is a linked-node for it
    then the netmail will not be routed
    unless that linked node has a route configuration

    NetMail destined for non-points are treated the same as before this
    commit.

    No change in the routing of echomail for points.

    I think this change fixes issue #520 which can be traced back to commit 45ced2a3b for poindexter FORTRAN (REALITY), 2 years ago almost to the
    day, where that change added point->boss routing, but only if the boss
    had a matching linked-node configuration (for both echomail and
    netmail).

    This commit also re-thinks commit ffe69b43623d (for Alterego) which
    would not route a point netmail if any our local AKAs matched the
    destination address, igorining the point value. I think what was
    intended here (I coudln't locate the original enhancmenet request or
    issue), was to not route if a local AKA was the *boss* of the point.
    And with this commit, that's now how it now works.

    As before, "test results appreciated".

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From poindexter FORTRAN@VERT/REALITY to Rob Swindell (on ChromeOS) on Saturday, February 18, 2023 18:45:27
    Re: src/sbbs3/sbbsecho.c
    By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 18 2023 12:59 pm

    As before, "test results appreciated".

    Thanks for doing this. I'm relying on the nightlies, so I'll download them tomorrow and test.
    ---
    þ Synchronet þ .: realitycheckbbs.org :: scientia potentia est :.
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Saturday, April 15, 2023 19:45:46
    https://gitlab.synchro.net/main/sbbs/-/commit/227e2f4986eb0b04c05cc6ea
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Stop classifying msgs for unknown areas as security violations

    When Secure EchoMail is enabled and a Bad Echo Area (*) is defined in the
    area file (areas.bbs), but the packet source address is *not* listed as a
    link to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknown
    areas in such a packet would cause the pkt to be considered a bad packet
    with a security violation. Instead, the message should just be skipped.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Tuesday, May 30, 2023 17:27:04
    https://gitlab.synchro.net/main/sbbs/-/commit/b185201161cd35dea8273d84
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Strip the "in-transit" attribute flag from imported packed-messages

    Log a warning message when either the "local" or "in-transit" flag has been stripped from ("Sanitized") imported packed-messages.

    Keyop reported a chksmb warning on a FidoNet message that contained the 'in-transit' attribute:
    <Keyop> Message flagged as 'In Transit' (?): 1
    <Keyop> fidonet_fidosoft Message Base has Errors!

    The message in question appears just to be a corrupted echomail msg coming
    from HPT:
    Sender '56:43 '
    To Tommi Koivula
    Subject test
    X-FTN-AREA FIDOSOFT.HUSKY
    X-FTN-TID hpt/os2-wc 1.9.0-cur 2021-03-14

    SBBSecho didn't use to convert/import the "in-transit" flag on imported
    netmail or echomail messages, ... until commit 446ab0ef7e09e5c61cf, which
    was needed to support the TickFix robot. So now, let's just sanitize the packed-message attributes a little sooner in the import process and log a warning when such sanitization has taken place.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Tuesday, May 30, 2023 17:27:04
    https://gitlab.synchro.net/main/sbbs/-/commit/d6eadf369e7ed75248b1819c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Truncate trailing whitespace from FidoNet message header fields

    It's unclear whether trailing whitespace is supposed to be significant or not (FidoNet specs don't say), but I don't see any reason why "John Doe" and
    "John Doe " should be considered unique senders or recipients. Remove any trailing whitespace from message subjects too.

    This change makes the trailing whitespace truncation in SMB hash functions unnecessary (at least for SBBSecho-imported messages), but most (all?) other message transports don't allow for this nonsense in the first place.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Monday, June 26, 2023 11:03:45
    https://gitlab.synchro.net/main/sbbs/-/commit/e76fafaae4580941b343253b
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix type 2.2 packet header generation

    As reported by Deon on DOVE-Net: type 2.2 packet generation was not (since SBBSecho v3.0) setting the origin and destination point values correctly:
    was leaving the packet type 2.0 date values in these fields.

    Also, zero-out the reserved bytes in the type 2.2 packet header (don't leave the type 2.0 date values in there).

    Thanks for the report Deon!

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thursday, July 20, 2023 11:53:05
    https://gitlab.synchro.net/main/sbbs/-/commit/68df9812f31add3f94430d77
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Always delete the AREASxxxxxx temp file

    When there are no changes (areas added or removed) via an areafix message, the data/AREASxxxxxx temp file would be left behind. The file was only removed if areas were added or removed from the area file via areafix message.

    The orphaned data/AREASxxxxxxx files were reported via DOVE-Net by Gamgee (PALANTIR)
    If you have these stale files, you can safely delete them.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sunday, September 17, 2023 23:27:45
    https://gitlab.synchro.net/main/sbbs/-/commit/f9b0dda5a1cac371a50f9f3f
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Add more detail (e.g. line number) to various "error opening" log msgs

    Some of the errors could be pretty vague since they looked the same and
    we were depending on the path/file attempted to be opened in the log msg
    to clue us into what exactly was being attempted. But some of these file
    paths are sysop-configurable, and they can put unexpected things in there
    that make it difficult to determine exactly what file was trying to be
    opened and for what purpose. This should help a little bit.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Monday, December 04, 2023 21:14:35
    https://gitlab.synchro.net/main/sbbs/-/commit/43fb687f2e138e183f841a42
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix issue when packing netmails for multiple different linked-nodes

    Introduced in commit 15b230af (9 months ago), the first linked-node config (including packet password!) for the first packed netmail message would be reused for subsequent packed netmail messages.

    Thank you to Wilfred van Velzen (2:280/464) for reporting this problem!

    Additional debug-level log message when using a packet password for a newly created packet.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Monday, December 04, 2023 22:57:40
    https://gitlab.synchro.net/main/sbbs/-/commit/28e435bdc2e909f38032afd4
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Combine the "new packet" and "password-protected" debug-log lines

    ... to de-clutter the log

    Also, don't log the packet passwords. Folks copy and post sbbsecho.log lines and that could seriously compromise the security of the Interwebs if those super-secret passwords were ever leaked!

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Friday, December 15, 2023 17:25:50
    https://gitlab.synchro.net/main/sbbs/-/commit/fc9d641054b36d9a84cc87da
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix typo in previous commit

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, December 31, 2023 17:16:52
    https://gitlab.synchro.net/main/sbbs/-/commit/6e1118af6abf0c55ca608a29
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Don't use wildcard node packet password (if one exists)

    This also addresses the addresses with 65535 in them in the new debug-level
    log messages "New packet (type x) created for linked-node" .

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, December 31, 2023 17:16:52
    https://gitlab.synchro.net/main/sbbs/-/commit/c2f663c30ab71c7493babab4
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Log message attributes in human-readable form (not just hexadecimal)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, January 07, 2024 20:47:22
    https://gitlab.synchro.net/main/sbbs/-/commit/623613492036f9806c225436
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Expand sole-LFs in message text (shouldn't normally be there)

    Expanded to CRLF or just CR (if strip LFs is enabled).

    It is possible for someone to stuff LF-terminated text in a message, so let's account for that possibility upon export to FTNs where LFs are supposed to be ignored.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Wednesday, February 07, 2024 10:47:17
    https://gitlab.synchro.net/main/sbbs/-/commit/20aecd3a4d979af82e3f509b
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix more warnings...

    It looks like we may need a set of PRI?TIME macros for printf()ing
    a time_t.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Saturday, March 16, 2024 20:11:36
    https://gitlab.synchro.net/main/sbbs/-/commit/9b28769f4b669763409f0435
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Bugfix: actually use the SMB netattr 'HOLD' attribute flag

    ... when exporting from SMB to .msg ("stored message") file

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Saturday, March 23, 2024 16:12:16
    https://gitlab.synchro.net/main/sbbs/-/commit/4c7a908f8ee55161faf3be71
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Insure buf is null-terminated in getzpt(), resoving CID 488308

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Saturday, March 23, 2024 17:13:28
    https://gitlab.synchro.net/main/sbbs/-/commit/5a2a73ae1b20ddf3563c23fe
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix typo in previous commit to this file

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Monday, September 09, 2024 18:29:23
    https://gitlab.synchro.net/main/sbbs/-/commit/0f0a8a1ae72c424509eaa72d
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Refactor the function: unpack_bundle()

    1. When a 0-length bundle file was encountered or an unpacking error occurred,
    any remaining bundles for the current search day-of-week (e.g. *.SU*) would
    be skipped/ignored. This bug (issue #764, regarding the 0-length file part),
    is fixed by not incrementing the day-of-week index in the main loop, but
    rather only incremeting the index when all bundles for the current
    day-of-week have been processed.
    2. The age calculation for 0-byte/length bundle files was incorrect, so all
    0-length bundle files would always be considered "less than 24-hours old"
    (and thus, never auto-deleted).
    This exacerbated the problem of issue #764 since it would persist until the
    0-length files were manually deleted. Fixed the file age calculation and
    now logging the date/timestamp of the 0-length file as well.
    3. Don't do the switch/case/sprintf dance when we're not re-running a glob()
    search.
    4. Replace the switch/case statement with an array of week day names/patterns. 5. Ignore (with a warning log message) any sub-directories of the inbound
    directory that happen to match the bundle file search pattern.
    6. Use better variable naming.
    7. Refer to files with a length of 0 as "0-length" instead of "0-byte" in log
    messages.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, September 22, 2024 16:57:13
    https://gitlab.synchro.net/main/sbbs/-/commit/6177a1c02241acc45a1b0858
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix potential null pointer dereference

    strListReadFile() can return NULL upon error

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, November 10, 2024 17:15:21
    https://gitlab.synchro.net/main/sbbs/-/commit/3c0a335de3ba7d0008134bd1
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Log a notice-level message when renaming a bad bundle file to *.?_? or *.?-?

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tuesday, November 12, 2024 20:08:03
    https://gitlab.synchro.net/main/sbbs/-/commit/fb138db6799daa4722bc8689
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support multiple filenames in subjects of file-attach netmails being packed

    When writing the attached file path/names to the FLO file, parse each
    filename out of the subject, accordingly. This should fix issue #824.

    There's an inconsistent support in SBBSecho for FileLists in the subjects of netmail messages. In a couple of places, single-space-separated filelists are fine (but not commas or multiple space, even though they are allowed per FTS-1).

    This particular fix is just for the packing of netmail messages and the appending the attached file(s) to the FLO file. Those other places (e.g.
    .REQ file creation) will need their own fixes for proper filelist support.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tuesday, November 12, 2024 21:11:32
    https://gitlab.synchro.net/main/sbbs/-/commit/25ed5ec70838f530e7fc04ba
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support multiple files ("FileList" per FTS-1) in subj when creating .REQ files

    Previously, this feature assumed just one request per FREQ message, however FTS-1 make this clear:

    If one or more of FileAttached, FileRequest, or FileUpdateReq are
    asserted in an AttributeWord, the subject{72} field is interpreted as
    a list of file specifications which may include wildcards and other
    system-dependent data. This list is of the form

    FileList = [ FileSpec { Sep FileSpec } ] Null

    FileSpec = (* implementation dependent file specification. may
    not contain Null or any of the characters in Sep. *)

    Sep = ( " " | "," ) { " " }

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Saturday, November 16, 2024 14:05:33
    https://gitlab.synchro.net/main/sbbs/-/commit/e55183c0953d0b033d9f1179
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Use fmutex_open for 100% locking and auto-removal upon close/termination

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sunday, November 17, 2024 16:40:39
    https://gitlab.synchro.net/main/sbbs/-/commit/dbf5e7758f297321c0b5260d
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Revert "Use fmutex_open for 100% locking and auto-removal upon close/termination"

    This reverts commit e55183c0953d0b033d9f11796f4290e488596e92.

    fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file systems: unlink() of a file immediately removes its directory entry allowing subsequent opens of the same file name, defeating the lock.

    I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I wanted (like the Windows version does). Still searching for a good solution:
    if a process terminates, gracefully or not, I'd like the file to be removed
    at that time and until then, other processes or threads can't create or open the same lock file (using O_EXCL and file locking to insure this).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, November 20, 2024 14:45:07
    https://gitlab.synchro.net/main/sbbs/-/commit/3f24e009942a2d66c1870f34
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix new potential NULL derefs (the add/del_area args can be NULL)

    ... in area manager code modified in previous commit.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, November 20, 2024 14:45:07
    https://gitlab.synchro.net/main/sbbs/-/commit/a8cf36696b038fc4815f1264
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix unsigned compare against >= 0 and nomatch misplacement

    I'm not clear if/why these would cause the issue reporetd by
    Fernando but they're definitely bugs in the areas.ini areafix
    code. No impact to the areas.bbs areafix handling.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, November 20, 2024 20:50:41
    https://gitlab.synchro.net/main/sbbs/-/commit/a225fd20b4236ff5f8f56cc5
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Detect and log warnings about duplicate area sections in areas.ini

    ... like how we do for areas.bbs files.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, November 20, 2024 20:50:41
    https://gitlab.synchro.net/main/sbbs/-/commit/6c85be290b34f6379cf56fe1
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support AreaMgr request messages with -L (list) or -Q (query) but no body

    I noticed through code review that these kinds of messages would be rejected
    as "No commands to process.". We just needed to increment the 'cmd' counter when parsing these options to be sure we don't think that no commands were
    in fact request. -R (rescan) is not by itself a command since it requires listed area-tags to have any effect.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, November 20, 2024 20:50:41
    https://gitlab.synchro.net/main/sbbs/-/commit/f37c0346b645496e4e591d10
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix stupid inverted logic bug: treating areas.ini as areas.bbs for AreaFix

    and vice versa - so area manager requests were broken since I introduced the areas.ini support. Oops.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Friday, November 22, 2024 17:50:50
    https://gitlab.synchro.net/main/sbbs/-/commit/2382d2987953d948a56b7612
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Clean up area management code

    I dislike this particular code a little less now:
    - no more redundant string compares
    - less deeply nested if() and for() blocks
    - remove added areas from the add list, rather than zeroing out the tag
    - a little more common code between areas.bbs and areas.ini handling

    No functional change (I hope).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Saturday, November 30, 2024 21:02:49
    https://gitlab.synchro.net/main/sbbs/-/commit/cee11a4e100dba897abc250c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Eliminate some harmless gcc warning about using uninitialized vars

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thursday, December 05, 2024 21:40:24
    https://gitlab.synchro.net/main/sbbs/-/commit/1520bba8c23f3e6b5d80de7f
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Truncate the GIT date (remove time) in Program ID.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, December 06, 2024 17:38:28
    https://gitlab.synchro.net/main/sbbs/-/commit/e2476ebbaa0a7d05e72bce2d
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix insufficient allocation bug in link_area() introduced in commit 813072cd4

    This is likely the cause of the areamgr issue that resulted in weird/invalid node address being added to the area file, reported by Tom Moore (1:135/205).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Saturday, December 07, 2024 14:08:12
    https://gitlab.synchro.net/main/sbbs/-/commit/c14cea13c153d2e18455823f
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    A differnt 'fix' to link_area()

    So, (sizeof *addr) now looks right got me (this should've been the same as sizeof(fidoaddr_t)), so the change in commit e2476ebbaa doesn't actually look like a fix, but maybee a regression.

    I need to test some area manager link additions and get to the bottom of this, but this particular change was not a fix (and caught/reported by Coverity -
    CID 515673).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Saturday, December 07, 2024 16:39:06
    https://gitlab.synchro.net/main/sbbs/-/commit/68e76982e0054dffec75b75c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix the areas.bbs AreaMgr addition bug created in commit 813072cd450c2

    The newly created/used link_aera() function was copying the address of the passed fidoaddr_t pointer rather than the value (fidoaddr) pointed to.
    This is the actual fix for the problem reported by Tom Moore (1:135/205)
    - tested and validated. It only immediately impacted areas.bbs use
    (not areas.ini), since we wrote a stringified address directly to the
    areas.ini file "links" key. This was not an allocation issue but a memcpy() issue.

    Other unrelated changes:
    - Log a debug-level message when ignoring a "NO-ECHO" message (subject "NE:*") - Log a notice-level message when ignoring a message due to GATEWAY VIOLATION
    (gating a message between net-types when not explicitly configured to do so)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net