Hmm. I think that the topic of discussion has strayed a bit from this
wishlist bug for the scrypt Debian package. I've just uploaded a PR that
makes the scrypt binary use libscrypt-kdf, so it's probably best to continue
the discussion there if you're interested:
It'd be pretty straightforward to tweak the build system to generate
both static and dynamically linked executables, or to have an option
for it. The automake stuff is designed for exactly that kind of thing
and makes it really easy.
Yes, it's intentional that the executable doesn't use the library. Colin
Percival wanted to minimize changes to the build system, and also to only have
the library as an optional compile.
That's fantastic. Working on a package.
One tiny question: the generated scrypt executable does not use the
shared library. Is that intentional?
Cheers,
--Barak.
Hi Barak and Micah,
As of scrypt-1.3.0, upstream now supports building a shared library with:
./configure --enable-libscrypt-kdf
(We named it libscrypt-kdf to avoid conflicts with the existing libscrypt [1]
library, which has slightly different functionality.)
[1]
5 matches
Mail list logo
