On Fri, 29 Apr 2011, Paul DeBruicker wrote:
You can't add symbol versions to existing libraries like that. If you
need a new symbol version for something in EGLIBC (or generally if you
wish to export an EGLIBC-specific symbol), it needs to be in an option
group that is disabled by default and the symbol version needs to be in
the form EGLIBC_* with a name reflecting the option group involved.
OK. I do not know the reasoning behind the change to the Versions.def file or
whether it is necessary or not. It was in the diff I linked to in my previous
email so I left it in when updating the diff to "work" with eglibc 2.12.1 and
crypt_blowfish.
It appears the code is adding new (undocumented) interfaces crypt_rn,
crypt_gensalt, crypt_gensalt_rn, crypt_ra, crypt_gensalt_ra which is why
it needs symbol versions for them. The threshold for adding new exported
symbols in certainly greater than for simply adding a new algorithm (and
certainly requires documentation in the glibc manual for the new
interfaces).
I don't think adding new algorithms ought to require glibc changes; it
ought to be possible to load them dynamically, just like gconv and NSS
modules. Such dynamic loading could be a useful feature.
There is a general principle that glibc is not meant to contain C
interfaces just because they are useful; it's meant to contain the basic C
and POSIX interfaces, interfaces to Linux system calls, and other
interfaces that are so closely related to the above that glibc is the only
natural place for them (for example, hooks into the malloc code). In many
cases, a separately maintained library is a better place for slightly more
specialized interfaces that are not in ISO C or POSIX. Even some of the
executable tools provided by glibc might better be distributed and built
separately rather than at the same time as libc itself is built (still
associated with the glibc project), and it would be logical for the locale
data, for example, to be a completely independent project rather than part
of glibc.
(The next merge from FSF glibc to EGLIBC will bring in the changes that
prevent the old sunrpc code being used by new programs, deprecating it in
favor of the separately maintained TIRPC library. This is an example of
these principles in action: code for niche interests is best maintained by
people with relevant expertise, in separate projects.)
So when you are adding new cryptographic interfaces such as this patch
does, one must ask whether glibc is really the right place for additional
cryptography support. Fedora recently looked at reducing the number of
different cryptographic libraries in use in that distribution, for a range
of reasons, and settled on NSS as the preferred library - see
<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>. This certainly
doesn't guarantee that other GNU/Linux distributions will follow, but it
does suggest you might want to consider NSS as a cryptographic library for
your application - and if other distributions do follow, libcrypt could
end up mainly as legacy code, given how limited its purpose is compared to
the complexity of modern cryptography.
The paper written by the algorithm's authors [1] describes the reasoning more
fully but the gist of it is this. In bcrypt the key set up phase has a
configurable number of rounds of encryption. As computers get faster this
So do the SHA-256 and SHA-512 based encryption algorithms. Comparisons
against plain SHA-256 or SHA-512 hashing (single-round) are completely
irrelevant here since that is not what is implemented in glibc.