On 2023-09-02 21:23, cielesti wrote:
> 2) (crypt "a" "$0$") returns "$0UqSJBCvZvN."
> 3) (crypt "a" "$9$") returns "$9SxH5/IxLdbI"
>
> With TXR 278 that is in Alpine's package repo, those function calls error out as expected.
By the way, those function calls should not have been erroring out.
There is a funny/strange story behind that, which revolves around
how I totally confused myself one day, just before the start of the pandemic:
commit c3a0ceb2cea1a9d43f2baf5a2e63d0d712c8df19
Author: Kaz Kylheku <kaz@???>
Date: Fri Feb 14 21:55:24 2020 -0800
crypt: harden against crashes.
This went into TXR 233.
I was experimenting with crypt code and somehow fooled myself into
believing a falsehood: that the crypt (at least on Glibc) lacks robustness
and will segfault on bad inputs. To protect the TXR Lisp programmer
against this, I coded a validation of the salt argument. This checked
the salt for all the supported syntaxes like $6%, and valid DES
characters and such. If the syntax didn't validate, my crypt_wrap
function itself would throw the error exception, without ever calling
crypt or crypt_r.
In October 2022, I revisited the issue due to some Usenet discussions
about crypt. Try as I might, I could not reproduce the problem which
motivated the above commit---and the commit mentioned no repro steps.
I studied the source of several versions of the glibc crypt, to no
avail.
On Hallowe'en morning, removed the code:
commit 00d7b468e94d23646bb58b1774f5bec33b7c9fb1
Author: Kaz Kylheku <kaz@???>
Date: Mon Oct 31 07:18:41 2022 -0700
crypt: remove dubious validator.
[...]
And so, on this Halowe'en, we exorcise the ghost
that has been haunting the crypt.
That went into TXR 284. So after that, those tests would not fail
any more on Musl.
(text/plain)