Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the >crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if >its supported on a given system as crypt() has the very unhelpful behaviour of >SIGSEGV'ing if you give it an invalid encryption algo number.
On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >>if
its supported on a given system as crypt() has the very unhelpful behaviour >>of
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
This has nothing to do with sockets.
Muttley@dastardlyhq.com writes:
On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >>>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >>>if
its supported on a given system as crypt() has the very unhelpful behaviour >>>of
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
This has nothing to do with sockets.
Openssl is a generalized cryptographic library that supports pretty much >every standard symmetric and asymmetric crypto algorithm. It does far
more than support transport level security. It's the primary toolkit
(aside from RSA BSAFE) used in cryptographic software of all forms.
On Fri, 28 Oct 2022 15:45:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.if
Some versions of glibc have been extended to support blowfish (algo 2a) in >>>>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
its supported on a given system as crypt() has the very unhelpful behaviourof
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
This has nothing to do with sockets.
Openssl is a generalized cryptographic library that supports pretty much >>every standard symmetric and asymmetric crypto algorithm. It does far
more than support transport level security. It's the primary toolkit >>(aside from RSA BSAFE) used in cryptographic software of all forms.
Looks like an absolute PITA to use for that with contect creation and init >calls (why?) whereas crypt() is a single standalone function call that returns >the encrypted data. I'll pass.
Nicolas George <nicolas$george@salle-s.org> writes:
Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
écrit :
Have you considered using openssl instead?
Are you sure you understand what crypt() does?
Are you sure you understand what opensll does?
Hint, it supports all forms of symmetric and asymmetric
cryptographic algorithms for stand-alone software as
well as supporting transport layer security.
Have you considered using openssl instead?
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >if
its supported on a given system as crypt() has the very unhelpful behaviour >of
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
écrit :
Have you considered using openssl instead?
Are you sure you understand what crypt() does?
On Fri, 28 Oct 2022 15:45:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.if
Some versions of glibc have been extended to support blowfish (algo 2a) in >>>>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
its supported on a given system as crypt() has the very unhelpful behaviourof
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
This has nothing to do with sockets.
Openssl is a generalized cryptographic library that supports pretty much >>every standard symmetric and asymmetric crypto algorithm. It does far
more than support transport level security. It's the primary toolkit >>(aside from RSA BSAFE) used in cryptographic software of all forms.
Looks like an absolute PITA to use for that with contect creation and init calls (why?) whereas crypt() is a single standalone function call that returns
the encrypted data. I'll pass.
Hint, it supports all forms of symmetric and asymmetric
cryptographic algorithms for stand-alone software as
well as supporting transport layer security.
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.
Nicolas George <nicolas$george@salle-s.org> writes:
Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
écrit :
Have you considered using openssl instead?
Are you sure you understand what crypt() does?
Are you sure you understand what opensll does?
Hint, it supports all forms of symmetric and asymmetric
cryptographic algorithms for stand-alone software as
well as supporting transport layer security.
On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.
Nobody needs crypt to be fast, other than password crackers.
Crypt is only required during password authentication. Maybe if you have
a single box with ten million users, each of whom is doing nothing
but logging in and out once a second, you might benefit from >hardware-accelerated crypt.
Kaz Kylheku <864-117-4973@kylheku.com> writes:
On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.
Nobody needs crypt to be fast, other than password crackers.
Crypt is only required during password authentication. Maybe if you have
a single box with ten million users, each of whom is doing nothing
but logging in and out once a second, you might benefit from >>hardware-accelerated crypt.
Who still uses crypt for password authentication[*]? Most use
algorithm with blowfish anyway, using openssl's BF_set_key() and BF_ecb_encrypt()
is relatively straightforward. Typical linux systems use MD5 hashes.
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >> calls (why?) whereas crypt() is a single standalone function call that >returns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that there >is a way to decrypt the results of crypt(3), which there is not.
On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
écrit :
Have you considered using openssl instead?
Are you sure you understand what crypt() does?
Are you sure you understand what opensll does?
Hint, it supports all forms of symmetric and asymmetric
cryptographic algorithms for stand-alone software as
well as supporting transport layer security.
It's an extra dependency to add to a program, whereas
crypt is in any POSIX glibc (and we can probe it at run-time
for glibc extensions).
Muttley@dastardlyhq.com writes:
On Fri, 28 Oct 2022 15:45:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in
the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to >checkif
its supported on a given system as crypt() has the very unhelpful >behaviourof
SIGSEGV'ing if you give it an invalid encryption algo number.
Have you considered using openssl instead?
This has nothing to do with sockets.
Openssl is a generalized cryptographic library that supports pretty much >>>every standard symmetric and asymmetric crypto algorithm. It does far >>>more than support transport level security. It's the primary toolkit >>>(aside from RSA BSAFE) used in cryptographic software of all forms.
Looks like an absolute PITA to use for that with contect creation and init >>calls (why?) whereas crypt() is a single standalone function call that >returns
the encrypted data. I'll pass.
openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.
Yes, it has a complex API.
On 2022-10-28, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >if
its supported on a given system as crypt() has the very unhelpful behaviour >of
SIGSEGV'ing if you give it an invalid encryption algo number.
I have experience in this area, having integrated crypt into the TXR
Lisp language, and worked around the embarrassing segfault issue.
Why doesn't it segfault for $7$?
Because my wrapper function lexically analyzes the salt
to validate for good cases that don't crash, and only those
go through to crypt. For the cases that would crash if
crypt were called, it simulates the EINVAL error.
See the crypt_wrap function and its validate_salt helper
in this source file:
http://www.kylheku.com/cgit/txr/tree/sysif.c
Kaz Kylheku <864-117-4973@kylheku.com> writes:
On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.
Nobody needs crypt to be fast, other than password crackers.
Crypt is only required during password authentication. Maybe if you have
a single box with ten million users, each of whom is doing nothing
but logging in and out once a second, you might benefit from >>hardware-accelerated crypt.
Who still uses crypt for password authentication[*]? Most use
message digests or secure hashes. The OP wanted to override the
algorithm with blowfish anyway, using openssl's BF_set_key() and >BF_ecb_encrypt()
Muttley@dastardlyhq.com, dans le message <tjin0r$9rb$1@gioia.aioe.org>,
a écrit :
How do we probe it without it crashing?
Fork to insulate the crash and probe.
How do we probe it without it crashing?
On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >>> calls (why?) whereas crypt() is a single standalone function call that >>returns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that there >>is a way to decrypt the results of crypt(3), which there is not.
That depends on how you personally define encryption. Others have different ideas.
https://man7.org/linux/man-pages/man3/crypt.3.html
"crypt() is the password encryption function."
On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >>> calls (why?) whereas crypt() is a single standalone function call thatreturns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that there
is a way to decrypt the results of crypt(3), which there is not.
That depends on how you personally define encryption. Others have different ideas.
https://man7.org/linux/man-pages/man3/crypt.3.html
"crypt() is the password encryption function."
On Sat, 29 Oct 2022 07:58:13 +0000, Muttley wrote:
On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >>>> calls (why?) whereas crypt() is a single standalone function call that >>>returns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that there
is a way to decrypt the results of crypt(3), which there is not.
That depends on how you personally define encryption. Others have different >> ideas.
https://man7.org/linux/man-pages/man3/crypt.3.html
"crypt() is the password encryption function."
Despite what the crypt(3) manpage's summary implies, the
manpage does detail the operation that crypt(3) performs:
"By taking the lowest 7 bits of each of the first eight characters
of the key, a 56-bit key is obtained. This 56-bit key is used to
encrypt repeatedly a constant string (usually a string consisting
of all zeros). The returned value points to the encrypted
password, a series of 13 printable ASCII characters (the first
two characters represent the salt itself). The return value
points to static data whose content is overwritten by each call."
So, as you can see, crypt(3) does /not/ encrypt the password, it
encrypts a "constant string" using a key derived from the password
and the salt. Decrypting the results of crypt(3), if at all
successful, will return only that "constant string" that was
encrypted.
On 10/29/2022 3:58 AM, Muttley@dastardlyhq.com wrote:
On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >>>> calls (why?) whereas crypt() is a single standalone function call thatreturns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that >there
is a way to decrypt the results of crypt(3), which there is not.
That depends on how you personally define encryption. Others have different >> ideas.
https://man7.org/linux/man-pages/man3/crypt.3.html
"crypt() is the password encryption function."
crypt() , at least in one place, is deprecated.
There is a substitution library which may be deployed.
You could check a Ubuntu Synaptic package manager or
The SHA512 might bring you closer in line with current practice.
If I look at /etc/shadow in Ubuntu in WSL2 in Windows 11, I see
paul:$6$Igyn9e...
and the $6 suggests SHA512 is being used.
On Fri, 28 Oct 2022 18:15:21 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
http://www.kylheku.com/cgit/txr/tree/sysif.c
That doesn't help to determine if a given system would support a given encryption function because your code simply has hard coded validation.
(crypt "abc" "$2a$salt")
My problem is that some versions of glibc support $2a$ and some don't and I can't find any way of determining on the fly which they are short of calling crypt() and seeing if it crashes which obviously is not very useful on a running system as I don't want to be catching SIGSEGV just for this case.
On 2022-10-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Fri, 28 Oct 2022 18:15:21 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote: >>>http://www.kylheku.com/cgit/txr/tree/sysif.c
That doesn't help to determine if a given system would support a given
encryption function because your code simply has hard coded validation.
That is partially true!
I neglected to emphasize that I have empirically determined that probing
the entire space "2a" through "2z" is safe; the function doesn't crash.
On Sat, 29 Oct 2022 16:08:38 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
On 2022-10-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Fri, 28 Oct 2022 18:15:21 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote: >>>>http://www.kylheku.com/cgit/txr/tree/sysif.c
That doesn't help to determine if a given system would support a given
encryption function because your code simply has hard coded validation.
That is partially true!
I neglected to emphasize that I have empirically determined that probing >>the entire space "2a" through "2z" is safe; the function doesn't crash.
Does when I try it.
On 2022-10-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Sat, 29 Oct 2022 16:08:38 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
On 2022-10-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Fri, 28 Oct 2022 18:15:21 -0000 (UTC)That is partially true!
Kaz Kylheku <864-117-4973@kylheku.com> wrote: >>>>>http://www.kylheku.com/cgit/txr/tree/sysif.c
That doesn't help to determine if a given system would support a given >>>> encryption function because your code simply has hard coded validation. >>>
I neglected to emphasize that I have empirically determined that probing >>>the entire space "2a" through "2z" is safe; the function doesn't crash.
Does when I try it.
Do you have a minimal repro sample?
On 10/29/2022 3:58 AM, Muttley@dastardlyhq.com wrote:
On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
Looks like an absolute PITA to use for that with contect creation and init >>>> calls (why?) whereas crypt() is a single standalone function call thatreturns
the encrypted data. I'll pass.
Actually, crypt(3) doesn't return encrypted data; that would imply that there
is a way to decrypt the results of crypt(3), which there is not.
That depends on how you personally define encryption. Others have different >> ideas.
https://man7.org/linux/man-pages/man3/crypt.3.html
"crypt() is the password encryption function."
crypt() , at least in one place, is deprecated.
There is a substitution library which may be deployed.
You could check a Ubuntu Synaptic package manager or
do "apt search crypt" and see what packages are available/installed.
https://launchpad.net/ubuntu/+source/libxcrypt/1:4.4.28-2
"libxcrypt is a modern library for one-way hashing of passwords.
It supports
If I look at /etc/shadow in Ubuntu in WSL2 in Windows 11, I see
paul:$6$Igyn9e...
and the $6 suggests SHA512 is being used.
Muttley@dastardlyhq.com, dans le message <tjin0r$9rb$1@gioia.aioe.org>,
a écrit :
How do we probe it without it crashing?
Fork to insulate the crash and probe.
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo
2a) in the crypt via the $2a$ preamble in the salt. Does anyone know
of a way to check if its supported on a given system as crypt() has
the very unhelpful behaviour of SIGSEGV'ing if you give it an invalid encryption algo number.
Kaz Kylheku <864-117-4973@kylheku.com> writes:
Crypt is only required during password authentication. Maybe if you have
a single box with ten million users, each of whom is doing nothing
but logging in and out once a second, you might benefit from >>hardware-accelerated crypt.
Who still uses crypt for password authentication[*]? Most use
message digests or secure hashes.
If that’s accurate then I don’t know why anyone would want the buggy 2a variant anyway.
Richard Kettlewell <invalid@invalid.invalid> wrote:
If that’s accurate then I don’t know why anyone would want the buggy
2a variant anyway.
Possibly, the thing that "wants" any of these variants is the datum in a sitting in a password file. If someone has a $2a$... password, and you
drop support for it, that user cannot authenticate. Not even to change
their password.
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your problem.
I wrote a quick pgm that calls crypt(3) using 3DES, MD5, Blowfish (both "a" and
"b" variations), SHA256 and SHA512, and, while Blowfish isn't supported in the version of glibc crypt(3) on my system, I don't get any SIGSEGV. Instead, I get the expected return of NULL with errno set to EINVAL on those calls.
On Mon, 31 Oct 2022 17:03:51 +0000, Muttley wrote:
On Mon, 31 Oct 2022 00:31:26 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >>>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
if
its supported on a given system as crypt() has the very unhelpful behaviour
of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your >>>problem.
Actually I can't reproduce it myself now. Now it seems to return NULL. I
must've cocked up somehow in my original code. Oh well.
FWIW, the only way I can get crypt(3) to segfault is to pass it a NULL >password or a NULL salt value. That is:
crypt(NULL,"ab"); /* will segfault */
or
crypt("password",NULL); /* will segfault */
So, it looks like, to answer your question as to how to check whether >crypt(3) supports blowfish or not, you simply have to check the
return value from crypt(3) for NULL after attempting to use the blowfish >algorithm.
On Mon, 31 Oct 2022 00:31:26 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >>the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >>if
its supported on a given system as crypt() has the very unhelpful behaviour >>of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your >>problem.
Actually I can't reproduce it myself now. Now it seems to return NULL. I must've cocked up somehow in my original code. Oh well.
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in >the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check >if
its supported on a given system as crypt() has the very unhelpful behaviour >of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your >problem.
On 2022-10-31, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:[snip]
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your problem.
I wrote a quick pgm that calls crypt(3) using 3DES, MD5, Blowfish (both "a" and
"b" variations), SHA256 and SHA512, and, while Blowfish isn't supported in >> the version of glibc crypt(3) on my system, I don't get any SIGSEGV. Instead,
I get the expected return of NULL with errno set to EINVAL on those calls.
Yes; on good arguments, there is no segfault, even on the unsupported arguments.
I joined this discussion with a "me too" because I was sure there is such segfault for bad arguments.
Unfortunately, this may might be turning out to be some shared hallucination.
In February 2020, I made an elaborate commit alleging that there is a
crash in glibc crypt when the salt argument has bad syntax.
https://www.kylheku.com/cgit/txr/commit/?id=c3a0ceb2cea1a9d43f2baf5a2e63d0d712c8df19
Unfortunately, I did a stupid thing there: not adding test cases
for the alleged issue!
Today, I'm not able to rediscover those test cases. I've tried all sorts
of bad inputs to crypt, and cannot get a segfault out of it.
The commit comment insists that it's a separate problem from the usage
error of failing to check for a null returned pointer, but that issue in
the code is fixed in the same commit.
In the absence of a repro sample coming from Muttley, and my inability
to repro any segfault, the issue has to be classified as nonexistent.
I'm planning to remove the validate_salt code in the next release
after one more review round.
On Mon, 31 Oct 2022 17:11:40 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Mon, 31 Oct 2022 17:03:51 +0000, Muttley wrote:
On Mon, 31 Oct 2022 00:31:26 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Fri, 28 Oct 2022 14:36:48 +0000, Muttley wrote:
Yes, I've googled this, no I didn't find an answer.
Some versions of glibc have been extended to support blowfish (algo 2a) in
the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to >check
if
its supported on a given system as crypt() has the very unhelpful >behaviour
of
SIGSEGV'ing if you give it an invalid encryption algo number.
Gotta ask, how do you invoke crypt(3)? I ask because I can't reproduce your >>>>problem.
Actually I can't reproduce it myself now. Now it seems to return NULL. I >>> must've cocked up somehow in my original code. Oh well.
FWIW, the only way I can get crypt(3) to segfault is to pass it a NULL >>password or a NULL salt value. That is:
crypt(NULL,"ab"); /* will segfault */
or
crypt("password",NULL); /* will segfault */
So, it looks like, to answer your question as to how to check whether >>crypt(3) supports blowfish or not, you simply have to check the
return value from crypt(3) for NULL after attempting to use the blowfish >>algorithm.
Yup. Still, led to an interesting thread :)
Just found what happened. I'm developing my code simultaniously on Linux and MacOS and on MacOS with clang, if you don't #include <unistd.h> then any
call to crypt() will return a bad (but non null) pointer no matter what the input parameters which then caused a crash later on.
On 2022-11-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
Just found what happened. I'm developing my code simultaniously on Linux and >> MacOS and on MacOS with clang, if you don't #include <unistd.h> then any
call to crypt() will return a bad (but non null) pointer no matter what the >> input parameters which then caused a crash later on.
If you dohn't declare crypt, an implicit declaration of it will be
used, which is incorrect: int crypt(char *, char *).
How are you not getting diagnostics for this? Even with no warnings
enabled, I get this:
I was. I didn't spot it as its a work in progress which still has warnings.
On 2022-11-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
Just found what happened. I'm developing my code simultaniously on Linux and >> MacOS and on MacOS with clang, if you don't #include <unistd.h> then any
call to crypt() will return a bad (but non null) pointer no matter what the >> input parameters which then caused a crash later on.
If you dohn't declare crypt, an implicit declaration of it will be
used, which is incorrect: int crypt(char *, char *).
Kaz Kylheku <864-117-4973@kylheku.com> writes:
On 2022-11-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
Just found what happened. I'm developing my code simultaniously on Linux and
MacOS and on MacOS with clang, if you don't #include <unistd.h> then any >>> call to crypt() will return a bad (but non null) pointer no matter what the >>> input parameters which then caused a crash later on.
If you dohn't declare crypt, an implicit declaration of it will be
used, which is incorrect: int crypt(char *, char *).
I think the implicit declaration would be int crypt() or, more
accurately, just crypt() with an implicit int return type.
Muttley@dastardlyhq.com, dans le message <tjrjj3$j4a$1@gioia.aioe.org>,
a écrit :
I was. I didn't spot it as its a work in progress which still has warnings.
I do not think fixing the warnings at the end is a winning strategy.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 308 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 92:57:56 |
| Calls: | 6,923 |
| Calls today: | 1 |
| Files: | 12,382 |
| Messages: | 5,434,104 |