Jilles Tjoelker wrote this message on Sun, Feb 15, 2015 at 00:17 +0100:
> On Tue, Feb 10, 2015 at 07:26:07AM -0500, Derek (freebsd lists) wrote:
> > 3. updates userland to use this API, and removes totally the
> > {crypt_set_format, login_setcryptfmt, login_getcryptfmt} APIs
>
> Removing API functions completely requires a SHLIB_MAJOR bump. I think
> this can be avoided by replacing the functions with a stub instead, so
> they would behave as if the default always applied and not allow changes
> to it.
It shouldn't be hard to support crypt_{get,set}_format, since default
is supported for find_format...
As for login_getcryptfmt, I can't find it...
and if we keep crypt_{get,set}_format, we can keep login_setcryptfmt,
but just mark them as deprecated...
> > 4. switches crypt algorithms to use thread-local storage, so the
> > good old global crypt buffer is thread-local
>
> This uses quite a bit of memory for each thread created, even if it does
> not call crypt() at all. Fortunately, libcrypt is not commonly used.
And not linked against normally, so, I don't see an issue...
> Given that crypt() has never been thread-safe, consider implementing
> crypt_r() as in glibc and leaving crypt() thread-unsafe.
We should go full thread safe, though that requirese some work on most
of the functions, as it appears that only sha256 and sha512 are safe...
> Thread-local storage via pthread_key_create() (one key for libcrypt) is
> still "magic" but reduces the memory waste for threads that do not call
> crypt().
With the way the crypt is pluggable, sharing storage between
implementations doesn't seem doable...
Also, I just realized that crypt_sha256 and crypt_sha512 are not safe
in their use of __thread... As the buffer isn't static, if the same
thread calls again, it could be previously returns memory gets free'd
by the realloc call...
> rand_buf is a salt, not a secret, so clearing it afterwards is
> unnecessary.
>
> Consider memcpy() and adding '\0' afterward instead of strncpy(). It
> seems unnecessary to clear the buffer completely.
I had thought of both of these before, and agree that the salt is not
a secret (it is kept hidden), but, it leaks information, and _makesalt
is called so rarely, that saving the time doesn't make sense...
So, I'd prefer to keep the code as is WRT these points..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
