This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Björn Esser <bjoern dot esser at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 1 Jun 2017 13:55:48 +0000
- Subject: Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- Authentication-results: sourceware.org; auth=none
- References: <79469eab-c809-a5b8-3297-2536320a834d@gmail.com>
On Wed, 31 May 2017, Björn Esser wrote:
> From f781e7f3e151ed89edd357734dd457bd4cd39ec0 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bj=C3=B6rn=20Esser?= <besser82@fedoraproject.org>
> Date: Wed, 31 May 2017 13:37:36 +0200
> Subject: [PATCH] This is an implementation of a password hashing method,
> provided via the crypt(3) and a reentrant interface. It is fully compatible
> with OpenBSD's bcrypt.c for prefix "$2b$", originally by Niels Provos and
> David Mazieres.
This patch appears to add various new public APIs.
* Patches adding new public APIs need to include a proper explanation of
those APIs, and the justification for adding them to glibc, in the patch
submission mail (which would become the commit message); any new API that
is also an ABI, as here, is permanent and we need to be very careful about
making sure that we do want to add the interface and that the interface
being added is the best one to add for that functionality. Especially,
since no other crypt algorithm needs its own APIs, you need to explain
what's special about this algorithm to require such APIs. If the APIs are
independent of the new algorithm support, the new algorithm support and
the APIs should be submitted and considered separately.
* New APIs (and other new features, as here) need to be mentioned in a
NEWS entry.
* New APIs need to be documented in the glibc manual (crypt.texi in this
case).
* I don't see any tests of the new function crypt_gensalt_rn.
* Please don't add any miscellaneous README files like
crypt/README.crypt_blowfish, especially not ones with a load of text that
appears to be about an external package rather than a description of the
current state of glibc-with-this-patch-applied. Documentation of features
in glibc should be integrated into the glibc manual and kept up to date
there. Descriptions of changes in a release go in the NEWS file.
* All new tests should use the support/test-driver.c mechanism, see
support/README-testing.c, rather than defining their own main function.
* Unless the code is intended to be maintained in sync verbatim with some
external package, the new code should be formatted according to the GNU
Coding Standards.
* Given that crypt.h already has __USE_GNU-conditional declarations, I'd
expect these interfaces to be conditional on __USE_GNU as well.
(Although, strictly, crypt.h is not a standard header so the standards say
nothing about conditions for functions in it; the functions POSIX has are
declared by POSIX in unistd.h.)
--
Joseph S. Myers
joseph@codesourcery.com