Hey, yes,
i wrote in January..
| ...
|I was just about to write to the list that i wonder whether that
|makes up a release, since i except v14.9.0 to be released some
|time in February:
Uh! Pain. But that summer will come.
|| FIX privsep.c, yes, vulnerability (wapiflapi)..
||
|| wapiflapi (wapiflapi at yahoo dot fr) reported a vulnerability
|| when the privsep program is driven directly: it is possible to
Oh, what a shame!
I took off the reporter of that vulnerability, thanks again.
v14.9.0 will obsolete [Rr]edirect, but these are only aliases for
[Rr]esend, which will both remain. (I hope the uppercase version
has been used for reposting this!)
Well, i have been working a bit feebly in the last days, we have
had nice weather in Germany for the first time since last
September, and light is important for the human species. Now it
is gray again. :) Anyway, since the last preview i have extended
our notion of reproducible-builds.org's $SOURCE_DATE_EPOCH to also
random numbers etc., and this allows use to test message output
_as is_. I thus could add a [test-out] branch and use it to store
test output in full text. 'Also added more tests, and, ah, in the
future it is possible to use the PROTO:// prefix, e.g., doing "?
copy * maildir://~/sweet-melissa" will do what one would expect
apart of any *newfolders*.
Actually i have touched maildir code as such a very little bit, we
now use Courier mail server names (the de-facto standard, and for
files, we don't support the internationalized Maildir folder
names, does any MUA do that, actually?), our sort function should
be compatible with Courier, dovecot, but still be compatible with
old Heirloom and, e.g., mutt. I added a missing memory
relaxation case here, too, and we now use the Torek hash to manage
the Maildir hashmap, so that in effect Maildir should have been
improved a bit.
And we gained generic `filetype' support, the old builtin support
for .gz etc., as well as my first primitive *file-hook** trial
will vanish in v15, all of this is simulated internally over the
new stuff as necessay. E.g.
filetype \
bz2 'bzip2 -dc' 'bzip2 -zc' \
gpg 'gpg -d' 'gpg -e' \
gz 'gzip -dc' 'gzip -c' \
xz 'xz -dc' 'xz -zc' \
zst 'zstd -dc' 'zstd -19 -zc' \
zst.pgp 'gpg -d | zstd -dc' 'zstd -19 -zc | gpg -e'
The zstd(1) file compressor is pretty cool, -1 is almost as fast
as lz4 but compresses much better, -19 is much slower but
compresses almost as good as xz, small, easy to compile, BSD
licensed with additional patent grant. I actually fully jumped on
that train and converted my entire archive, fixing many old MBOXes
therein via
define mboxfix {
\localopts yes; \wysh set mbox-rfc4155;\
\wysh File "${1}"; \eval copy * "${2}"
}
because indeed many had faulty From_ lines. Unfortunately we
cannot simply re-*encode* such faulty (or malicious) messages yet,
but apply the plain old MBOXO i think From_ quoting, but at least
the MBOXes are all valid now and cannot be misinterpreted by more
simple-minded MBOX parsers...
Yes, and then the usual internal purely technical progress to get
this thing out as a v14.9.0 that i can let alone for some time and
build upon in the future. (The large MIME, I/O layer and signal
rewrite for v15 will then gut a lot of old cruft and shrink this
codebase to a healthy state, what me hopes.)
Until in a few week (..oooohhh..),
Ciao!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
__________________________________
S-nail-users@lists.sourceforge.net
