|
|
Message-ID: <65c10e25-77af-4e29-88be-e38a7423cf46@gmail.com>
Date: Wed, 3 Jun 2026 13:16:43 +0900
From: Seo Suchan <tjtncks@...il.com>
To: musl@...ts.openwall.com
Subject: Re: musl crypt() fallback to DES for unknown hash algorithm
anywhy if patch is wanted here's below:
top of if here is if (salt[0] == '$' && salt[1] && salt[2]) { , looks
broad enough for to catch any unknown algo extension for me.
diff --git a/src/crypt/crypt_r.c b/src/crypt/crypt_r.c
index db6015e2..cc609331 100644
--- a/src/crypt/crypt_r.c
+++ b/src/crypt/crypt_r.c
@@ -16,6 +16,8 @@ char *__crypt_r(const char *key, const char *salt,
struct crypt_data *data)
return __crypt_sha256(key, salt, output);
if (salt[1] == '6' && salt[2] == '$')
return __crypt_sha512(key, salt, output);
+ /* we don't know this hash algorithm, make error */
+ return "*";
}
return __crypt_des(key, salt, output);
}
26. 6. 3. 10:31에 Rich Felker 이(가) 쓴 글:
> On Wed, Jun 03, 2026 at 12:40:58AM +0200, Thorsten Glaser wrote:
>> On Tue, 2 Jun 2026, Seo Suchan wrote:
>>
>>> better reject |any hash started with $ but musl doesn't about
>>> crypt_r() should return error. man crypt.3 suggest it'd set errorno to
>>> EINVAl and return invalid hash starting with *|
>> From the BSD side: yescrypt is an API misuse, the manpage clearly
>> documents that the extended mode is used if the string begins with
>> a dollar sign and a number.
>>
>> For applications wishing to use such nōn-standard extensions:
>> they should first run a known string through the crypt(3)
>> function and check its return value matches expectations.
>>
>> Please convey this to the busybox developers.
> Yes in general, I think you want to ensure that the setting/salt
> string you passed in is a prefix of what you got out. If not, it was
> interpreted differently from what the caller intended.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.