Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Jul 2020 18:57:18 +0200
From: Solar Designer <>
Subject: Re: [PATCH 0/5] pam_tcb update

> > > On Thu, Jul 05, 2018 at 02:29:19AM +0300, Dmitry V. Levin wrote:
> > > > I've got a few patches for pam_tcb.  Tested in Sisyphus.

On Wed, Jul 15, 2020 at 05:08:54PM +0300, Dmitry V. Levin wrote:
> I've finally managed to commit these changes.

Thank you!

On Wed, Jul 15, 2020 at 04:58:26PM +0300, Owl CVS (ldv) wrote:
> +	salt = crypt_gensalt_ra(pam_unix_param.crypt_prefix,
> +	    pam_unix_param.count, NULL, 0);

How exactly will this fail in case CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY
was defined at compile time, but the library in use at run time lacks
the support?  I am concerned that this will silently return an empty
salt for some hash types, instead of crashing.  Can we ensure there will
be a NULL pointer dereference crash, maybe by specifying NULL along with
non-zero size (and large enough that an implementation wouldn't likely
round it down to zero)?

Maybe we're better off not using CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY
and its corresponding feature at all, since we have our own code anyway?
Supporting both ways how tcb may be built increases the likelihood of
issues that we'd be responsible for.

What will happen if this is defined at compile time, but then the run
time library has no default?


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.