All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx+linux-man@kernel.org>
To: Vincent Lefevre <vincent@vinc17.net>,
	 Alejandro Colomar <alx@kernel.org>,
	Rich Felker <dalias@libc.org>,
	linux-man@vger.kernel.org,  libc-alpha@sourceware.org,
	Walter Harms <wharms@bfs.de>,
	~hallyn/shadow@lists.sr.ht,  musl@lists.openwall.com
Subject: Re: [musl] Re: [PATCH v1] man/man3/crypt.3: These functions accept many algorithms, not only DES
Date: Thu, 12 Nov 2026 14:26:15 +0100	[thread overview]
Message-ID: <avW906X136SKnaX_@devuan> (raw)
In-Reply-To: <20261112131547.GA1951@disset.lip.ens-lyon.fr>

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

Hi Vincent,

> Date: 2026-11-12 14:15:47+0100
> From: Vincent Lefevre <vincent@vinc17.net>
>
> On 2026-11-12 13:08:12 +0100, Alejandro Colomar wrote:
> > > This means that when "$" is supported by some implementation,
> > > the interpretation of the return value may be different from
> > > what POSIX specifies.
> > 
> > Kind of.  They better don't deviate from it in non-confirming ways;
> > one could argue that musl's "x" return value is indeed such a
> > non-conforming return value, and a NULL return value would be better
> > (both more conforming and safer).
> 
> This is more complex. The issue is that in the past, crypt() seemed to
> have been designed so that it could not fail (except in the case where
> it wasn't providing any implementation, i.e. it was always failing),
> so that applications did not expect a null pointer and some of them
> still do not check this case. Hence the choice done my musl.

It would be interesting to list all FOSS programs that forget to check
for NULL, and perhaps talk to them to update their code.


Cheers,
Alex

> Problems could be avoided only by writing more robust applications:
>   * They should have had a check for the null pointer.
>   * When a hash is obtained, applications should also check
>     whether the hash has the expected form (for instance,
>     the "*" returned by musl does not).
> 
> -- 
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-11-12 13:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 23:58 [PATCH v1] man/man3/crypt.3: These functions accept many algorithms, not only DES Alejandro Colomar
2026-11-10  0:01 ` Alejandro Colomar
2026-11-11 15:05   ` Serge E. Hallyn
2026-11-11 18:55     ` Alejandro Colomar
2026-11-11 21:13       ` [musl] " Rich Felker
2026-11-11 21:43         ` Alejandro Colomar
2026-11-12  1:52   ` Vincent Lefevre
2026-11-12  2:53     ` Rich Felker
2026-11-12  3:29       ` Vincent Lefevre
2026-11-12  3:37         ` [musl] " Rich Felker
2026-11-12 10:28           ` Alejandro Colomar
2026-11-12 11:40             ` Vincent Lefevre
2026-11-12 12:08               ` Alejandro Colomar
2026-11-12 13:15                 ` Vincent Lefevre
2026-11-12 13:26                   ` Alejandro Colomar [this message]
2026-11-12 12:08             ` Rich Felker
2026-11-12 12:27               ` Alejandro Colomar
2026-11-12 12:41                 ` Szabolcs Nagy
2026-11-12 13:12                   ` Alejandro Colomar
2026-11-12 13:27                     ` Vincent Lefevre
2026-11-12 13:17                 ` Vincent Lefevre
2026-11-12 13:23                   ` Alejandro Colomar
2026-11-12 13:45                     ` Vincent Lefevre
2026-11-12 13:55                       ` Rich Felker
2026-11-12 14:07                         ` Alejandro Colomar
2026-11-12 14:43                           ` Rich Felker
2026-11-12 14:58                             ` Alejandro Colomar
2026-11-12 18:08                               ` Rich Felker
2026-11-12 22:22                                 ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avW906X136SKnaX_@devuan \
    --to=alx+linux-man@kernel.org \
    --cc=alx@kernel.org \
    --cc=dalias@libc.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    --cc=vincent@vinc17.net \
    --cc=wharms@bfs.de \
    --cc=~hallyn/shadow@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.