On 1/19/2024 8:21 PM, Aon -> Al -> All wrote:

Hello all,

Testing Jamnntpd on 64bit Linux. The From field is still wonky.

Seems everything else works, except "Aon -> Al -> All" is also what appears in my From field now in Thunderbird.

I only see "%s -> %s" at two locations in nntpserv.c. So I have no idea where that's coming from. ;(

--
Regards,
Nick

... "Take my advice, I don't use it anyway."

--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (21:1/200.0)

On 2024-01-19 10:03 p.m., Aon -> Ac -> Accession wrote:

On 1/19/2024 8:21 PM, Aon -> Al -> All wrote:

; Hello all,

; Testing Jamnntpd on 64bit Linux. The From field is still wonky.

Seems everything else works, except "Aon -> Al -> All" is also what
appears in my From field now in Thunderbird.

I only see "%s -> %s" at two locations in nntpserv.c. So I have no idea where that's coming from. ;(

It looks like it might get that info when reading the headers of the messages from XOVER:

https://ibb.co/bzyLPxd

< GROUP NNTPTEST

211 10 1 0 NNNTPTEST Group selected

< XOVER 1-10

224 Overvew iinformation follows
1 Test ""Wde -> Al -> All" <unknown>
2 Test2 ""Wde -> Al -> All" <unknown>
3 Test3 ""Wde -> Al -> All" <unknown>
4 Test4 ""Jris -> As -> All" <0@664.229.1>

But the actual From line looks ok:

Path: JamNTPdd!not-for-mail
From: "Acessiion -> Accession" <0@200.1.21>
X-CommentTo: Accession
Newsgroup: fssx_tst
Subject: ot aa test
Date: Fri 19 Jan 2024 21:03:0 --0600
Message-I: <11003$fsx_tst@JamNNTPd>
Reference: <11001$fsx_tst@JamNNTPd>
X-JAM-Fro: Acccession <21:1/200.0>
X-JAM-To:Acceession

Jay

---
* Origin: Northern Realms (21:3/110)

On 1/19/2024 8:21 PM, Aon -> Al -> All wrote:

Hello all,

Testing Jamnntpd on 64bit Linux. The From field is still wonky.

Seems everything else works, except "Aon -> Al -> All" is also what appears in my From field now in Thunderbird.

I only see "%s -> %s" at two locations in nntpserv.c. So I have no idea where that's coming from. ;(

One thing I noticed when I was using some stuff that did something similar (Crashmail2 when I was working on Magicka) Is who ever wrote it made some assumptions about how the C library copied strings, which turned out not to be true anymore.

The specific bug I think (and it was a long time ago) was something along the lines of

strcpy(subject, &subject[4])

It was to do with stripping the (Re: from the start of messages), it expected strcpy to copy one character at a time sequentially.

The fix I used was to just:

char *subj_copy = strdup(&subject[4]);

strcpy(subject, subj_copy);

free(subj_copy)


I don't know it it will help you with JamNNTP but, I wouldn't be suprised if they used some "clever" tricks like that.

Andrew
--- Noddy git-4716e54
* Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)

Hello Warpslide,

On Sat, 20 Jan 2024 06:40:12 -0500, you wrote:

It looks like it might get that info when reading the headers of the messages from XOVER:

https://ibb.co/bzyLPxd

< GROUP NNTPTEST

211 10 1 0 NNNTPTEST Group selected

< XOVER 1-10

224 Overvew iinformation follows
1 Test ""Wde -> Al -> All" <unknown>
2 Test2 ""Wde -> Al -> All" <unknown>
3 Test3 ""Wde -> Al -> All" <unknown>
4 Test4 ""Jris -> As -> All" <0@664.229.1>

Definitely wierd.

But the actual From line looks ok:

Path: JamNTPdd!not-for-mail
From: "Acessiion -> Accession" <0@200.1.21>
X-CommentTo: Accession
Newsgroup: fssx_tst
Subject: ot aa test
Date: Fri 19 Jan 2024 21:03:0 --0600
Message-I: <11003$fsx_tst@JamNNTPd>
Reference: <11001$fsx_tst@JamNNTPd>
X-JAM-Fro: Acccession <21:1/200.0>
X-JAM-To:Acceession

Does it though? If you copy/pasted, it looks like there's a missing "c" and an extra "i" in the From field, an extra "s" in the Newsgroup field, "ot aa" in Subject field, then extra letters also in the X-JAM-FROM and X-JAM-TO fields.. :/

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Claws Mail 4.2.0 (GTK 3.24.38; x86_64-w64-mingw32)
* Origin: _thePharcyde distribution system (Wisconsin) (21:1/200.0)

Hello apam,

On Sun, 21 Jan 2024 00:36:20 +1000, you wrote:

One thing I noticed when I was using some stuff that did something
similar (Crashmail2 when I was working on Magicka) Is who ever wrote it made some assumptions about how the C library copied strings, which
turned out not to be true anymore.

The specific bug I think (and it was a long time ago) was something
along the lines of

strcpy(subject, &subject[4])

There seems to be a lot of lines in Jamnntpd's code that looks similar to this. My first search for "strcpy" came up with:

strcpy(addr,&originbuf[d+1]);

... and there's many more. :(

It was to do with stripping the (Re: from the start of messages), it expected strcpy to copy one character at a time sequentially.

The fix I used was to just:

char *subj_copy = strdup(&subject[4]);

strcpy(subject, subj_copy);

free(subj_copy)

I don't know it it will help you with JamNNTP but, I wouldn't be
suprised if they used some "clever" tricks like that.

You definitely might be on to something there, since Jamnntpd is quite old. The only bummer is that it seems as though that's used just about everywhere, including fromaddr, fromname, toname, replyaddr, and many more variables. I'll see if I can compare the two a bit more and see why Smapinntpd works better in this regard. Thanks for the heads up!

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Claws Mail 4.2.0 (GTK 3.24.38; x86_64-w64-mingw32)
* Origin: _thePharcyde distribution system (Wisconsin) (21:1/200.0)

strcpy(subject, &subject[4])

There seems to be a lot of lines in Jamnntpd's code that looks similar to this. My first search for "strcpy" came up with:

strcpy(addr,&originbuf[d+1]);

That might be ok, the problem was if it's copying the same buffer into itself, if they're different buffers it should be ok.

Andrew

--- Noddy git-4716e54
* Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)

On 1/20/2024 11:39 PM, apam -> Accession wrote:

;   a> strcpy(subject, &subject[4])

; There seems to be a lot of lines in Jamnntpd's code that looks
similar to this. My first search for "strcpy" came up with:

; strcpy(addr,&originbuf[d+1]);

That might be ok, the problem was if it's copying the same buffer into itself, if they're different buffers it should be ok.

Nah, there's a lot of buf,whatever where "whatever" is different variables. Either way, I'm aiming more towards this is an issue with it being old code and the difference between Win32, Linux32, and Linux64, to be honest.

Smapinntpd was a bit of an update to use smapi libraries instead of the original jam libraries (jamlib is much older and hasn't been updated like smapi has - hpt uses smapi).

Either way, I'm using Smapinntpd on my main system here, I was just trying to install and see where the issues with Jamnntpd were.

--
Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (21:1/200.0)

Re: Not a test
By: apam to Accession on Sat Jan 20 2024 06:36 pm

On 1/19/2024 8:21 PM, Aon -> Al -> All wrote:

Hello all,

Testing Jamnntpd on 64bit Linux. The From field is still wonky.

Seems everything else works, except "Aon -> Al -> All" is also what appears in my From field now in Thunderbird.

I only see "%s -> %s" at two locations in nntpserv.c. So I have no idea where that's coming from. ;(

One thing I noticed when I was using some stuff that did something similar (Crashmail2 when I was working on Magicka) Is who ever wrote it made some assumptions about how the C library copied strings, which turned out not to be true anymore.

The specific bug I think (and it was a long time ago) was something along the lines of

strcpy(subject, &subject[4])

It's illegal for the source and destination strings (arguments to strcpy) to overlap.

It was to do with stripping the (Re: from the start of messages), it expected strcpy to copy one character at a time sequentially.

The fix I used was to just:

char *subj_copy = strdup(&subject[4]);

strcpy(subject, subj_copy);

free(subj_copy)

I don't know it it will help you with JamNNTP but, I wouldn't be suprised if they used some "clever" tricks like that.

Or use memmove() instead (where the source and destination may overlap).
--
digital man (rob)

Sling Blade quote #16:
Karl Childers (to Doyle, re: lawn mower blade): I aim to kill you with it. Mmm. Norco, CA WX: 56.6øF, 82.0% humidity, 9 mph SW wind, 0.05 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Not a test
By: Accession to apam on Sat Jan 20 2024 06:25 am

There seems to be a lot of lines in Jamnntpd's code that looks similar to this. My first search for "strcpy" came up with:

strcpy(addr,&originbuf[d+1]);

Use of strcpy() in general is considered unsafe. But that's not the same issue that apam posted about (overlapping source and destination string). The example use of strcpy() above may be fine or may not, depending on the size of the 'addr' buffer and the length string at originbuf + d + 1.
--
digital man (rob)

Steven Wright quote #6:
A conscience is what hurts when all your other parts feel so good.
Norco, CA WX: 56.6øF, 82.0% humidity, 9 mph SW wind, 0.05 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On Sat, 2 Mar 2024 19:41:02 -0800, Digital Man -> Accession wrote:

Use of strcpy() in general is considered unsafe. But that's not the same issue that apam posted about (overlapping source and destination
string). The example use of strcpy() above may be fine or may not, depending on the size of the 'addr' buffer and the length string at originbuf + d + 1.

I believe we have changed those to memmove() like you stated in your
previous post.

Carlos has a fork available on github for Jamnntpd off the original
master branch, and I will be working on one for Smapinntpd in the near
future. Both of them will include all of these changes, as well as some
others.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (21:1/200)