This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]