https://gitlab.synchro.net/main/sbbs/-/commit/227e2f4986eb0b04c05cc6ea
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Stop classifying msgs for unknown areas as security violationsWhen Secure EchoMail is enabled and a Bad Echo Area (*) is defined in thearea file (areas.bbs), but the packet source address is *not* listed as alink to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknownareas in such a packet would cause the pkt to be considered a bad packetwith a security violation. Instead, the message should just be skipped.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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-messagesLog a warning message when either the "local" or "in-transit" flag has beenstripped 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 comingfrom HPT:Sender '56:43 'To Tommi KoivulaSubject testX-FTN-AREA FIDOSOFT.HUSKYX-FTN-TID hpt/os2-wc 1.9.0-cur 2021-03-14SBBSecho didn't use to convert/import the "in-transit" flag on importednetmail or echomail messages, ... until commit 446ab0ef7e09e5c61cf, whichwas needed to support the TickFix robot. So now, let's just sanitize thepacked-message attributes a little sooner in the import process and log awarning when such sanitization has taken place.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e76fafaae4580941b343253b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix type 2.2 packet header generationAs reported by Deon on DOVE-Net: type 2.2 packet generation was not (sinceSBBSecho 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 leavethe type 2.0 date values in there).Thanks for the report Deon!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/68df9812f31add3f94430d77
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Always delete the AREASxxxxxx temp fileWhen there are no changes (areas added or removed) via an areafix message, thedata/AREASxxxxxx temp file would be left behind. The file was only removed ifareas 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.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 msgsSome of the errors could be pretty vague since they looked the same andwe were depending on the path/file attempted to be opened in the log msgto clue us into what exactly was being attempted. But some of these filepaths are sysop-configurable, and they can put unexpected things in therethat make it difficult to determine exactly what file was trying to beopened and for what purpose. This should help a little bit.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/fc9d641054b36d9a84cc87da
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix typo in previous commit
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5a2a73ae1b20ddf3563c23fe
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix typo in previous commit to this file
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 *.?-? --- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 = ( " " | "," ) { " " }
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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).
--- SBBSecho 3.22-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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).
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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). --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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).
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c0305b87e10ec27852fe13f1
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log messages when (attempting) to notify mail recipients (via short messages)

ERROR-level messages with error number, upon failure and debug-level message upon success.

To hopefully help Deon get to the bottom of his SBBSecho echomail notification issue.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Rob Swindell (on Debian Linux) to Git commit to main/sbbs/master on Sun Jan 19 2025 02:56 am

Howdy,

Log messages when (attempting) to notify mail recipients (via short messages)

To hopefully help Deon get to the bottom of his SBBSecho echomail notification issue.

Thanks, I've kicked of a build and will try this tomorrow. Thanks :)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/4bad3a54de5334550d9f5466
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
More log messages around notifying users of imported echomail, for Deon

Log levels ERROR, NOTICE, and DEBUG
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ff1ebae7920c50df2855051c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add debug-level log messages when import_netmail() returns a non-zero value

To help debug any situations where import_netmail() might silently fail
(though I don't anticipate there are any, Accession suggested there was).
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Why are these being posted? Curious

--- Steve K9ZW via SPOT BBS

--- Mystic BBS v1.12 A49 2024/05/29 (Raspberry Pi/32)
* Origin: SPOT BBS / k9zw (1:154/154)

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Rob Swindell (on Windows 11) on Tue Feb 04 2025 06:54 am

Why are these being posted? Curious

This is the "Synchronet Programming (C/C++ and Git)" Conference, so the source code repository activity (changes to the Synchronet source, primarily) get posted here, so sysop can see what's changing (fixes, new features, etc.).
--
digital man (rob)

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 55.6øF, 78.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 04 Feb 2025, Digital Man said the following...

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Rob Swindell (on Windows 11) on Tue Feb 04 2025 06:54 am

Why are these being posted? Curious

This is the "Synchronet Programming (C/C++ and Git)" Conference, so the source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

--- Steve K9ZW via SPOT BBS

--- Mystic BBS v1.12 A49 2024/05/29 (Raspberry Pi/32)
* Origin: SPOT BBS / k9zw (1:154/154)

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Digital Man on Tue Feb 04 2025 05:48 pm

source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have. ---
þ Synchronet þ ::: BBSES.info - free BBS services :::
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

MRO wrote to k9zw <=-

source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment... appreciate the reply!

put your data files in their own sub directory for each msg network you have.

That isn't necessary and certainly is not the default way.



... He does the work of 3 Men...Moe, Larry & Curly
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: src/sbbs3/sbbsecho.c
By: MRO to k9zw on Tue Feb 04 2025 06:04 pm

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have.

I think it may be the internal sub-board code that matters, not really where the files are stored. The internal sub-board codes need to be unique. If 2 sub-boards share the same internal code, then I'm sure that would cause messages to get duplicated in both sub-boards. But it also doesn't hurt to have the files in separate directories.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: src/sbbs3/sbbsecho.c
By: Nightfox to MRO on Tue Feb 04 2025 05:28 pm

Re: Re: src/sbbs3/sbbsecho.c
By: MRO to k9zw on Tue Feb 04 2025 06:04 pm

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have.

I think it may be the internal sub-board code that matters, not really where the files are stored. The internal sub-board codes need to be unique. If 2 sub-boards share the same internal code, then I'm sure that would cause messages to get duplicated in both sub-boards. But it also doesn't hurt to have the files in separate directories.

In this case, the system with the issue is not a Synchronet system, so I don't know if "internal codes" apply. :-)
--
digital man (rob)

Steven Wright quote #7:
A clear conscience is usually the sign of a bad memory.
Norco, CA WX: 54.0øF, 78.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: src/sbbs3/sbbsecho.c
By: Digital Man to Nightfox on Tue Feb 04 2025 08:00 pm

In this case, the system with the issue is not a Synchronet system, so I don't know if "internal codes" apply. :-)

Ah, I didn't see (or notice) it's not a Synchronet system. :)

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/3ff043da84462d6cf5db9a64
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log warning-level message when we can't auto-add a sub

... because there's no linked-node configured as the uplink for the parent message group.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d652854faa37cb4cdf507938
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Address some MSVC static analysis warnings
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/fabef9ea90ed2758081eec2a
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Only log one warning per invocation about inability to auto-add sub

Just the first sub that couldn't be auto-added.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8010070c0bc86aaf8104a144
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Take the configured origin line chars into account when determining charset

and if the message is UTF-8, encode the origin line as UTF-8 too.
If the message is straight ASCII (e.g. the sub-board is configured as ASCII only), convert the configured origin line to ASCII, before appending.

At this time, only ASCII and CP437 encodings of originlines are supported
in Synchronet (imported and exported origin lines can contain UTF-8).

This should address the issue raise by Sergey Dorofeev (2:5020/12000) in the FidoNet UTF-8 echo whereby messages exported from Synchronet systems (presumably using SBBSecho) could contain a mixture of CP437 and UTF-8 encodings (!) when the sysop had CP437 chars in their configured origin line. --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f78d5395969b6a38a4db8adc
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add typecast to elminate GCC warning
--- SBBSecho 3.24-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)