Closed albrechtd closed 10 months ago
Oops, reverted the wrong thing.
I'll have to look at this again next time I'm on my Mac. Currently on Windows so I can't build or run the unit tests :(
Edited the code on Windows so I'm not even sure the above commit will compile, but theoretically, at least, it should be what is needed for this.
Edited the code on Windows so I'm not even sure the above commit will compile, but theoretically, at least, it should be what is needed for this.
The code compiles on Bookworm, with a (probably unrelated) warning:
url-scanner.c: In function 'url_web_end':
url-scanner.c:336:21: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
336 | end = inptr;
| ^
and works as expected. Thanks for fixing!
I think that is related to a previous change I made to fix the url-scanner. I'll have to take a look at that.
just released 3.2.14 with this fix
While re-building some of my software for Debian Bookworm I stumbled over different decoding of “chunked” Base64 encoded parts which are sometime used by Malware authors (see here for a description):
On Debian Bullseye, coming with GMime 3.2.7, the output of the attached trivial test application is
i.e. GMime does not stop decoding at the very first “=”.
However, on Debian Bookworm, with GMime 3.2.13, this is not the case, as the result reads
As my application tries to detect anomalies in messages and to completely extract possibly malicious content for further inspection, the new GMime version actually breaks this feature. I would prefer to avoid writing my own decoder – would it be possible to re-enable decoding chunked Base64 completely? This should make absolutely no difference for any well-formed messages, but would be extremely helpful for use cases like mine.
Thanks, Albrecht.