Date: Wed, 15 Jul 2020 18:57:18 +0200 From: Solar Designer <solar@...nwall.com> To: owl-dev@...ts.openwall.com 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: > +#ifdef CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY > + 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. I have similar concerns about CRYPT_GENSALT_IMPLEMENTS_DEFAULT_PREFIX. What will happen if this is defined at compile time, but then the run time library has no default? Alexander
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.