Hi Sebastian, thanks for this report!
We did in fact change this in later development. scrypt 1.2.0 was
released on 2015-07-30, and this was changed on 2016-07-01:
https://github.com/Tarsnap/scrypt/commit/69a6776e211c084adb73cca0f69cd6f33f4cdfbd
https://github.com/Tarsnap/libcperciva/commit/e86fc8afdd11c643716b9f44c6abcdc72fb21384
In particular, we now pass $PATH explicitly to "command -p" to
work around this bash bug.
I know that your next question will be "when will scrypt 1.2.1 be
released?", and unfortunately I can only give the typical reply of
"when it's ready". Sorry I can't help more on that front.
Cheers,
- Graham
On Tue, Oct 04, 2016 at 11:12:56AM +0200, Sebastian Messmer wrote:
Hi,
I'm the author of CryFS (https://www.cryfs.org), an open source encrypted
cloud file system using scrypt for key derivation. When building CryFS, it
first builds the scrypt 1.2.0 source in a subfolder and then links it to the
file system code.
A few of our users ran into an issue compiling scrypt with hardening-wrapper
enabled. Namely, Makefile.in (line 1314) calls cpusupport.sh using 'command
-p'. This command overwrites the user-set $PATH and therefore uses the
default compiler at /usr/bin, not the one it should use at
/usr/lib/hardening-wrapper/bin.
This overwriting of $PATH seems to be a bug in Bash 4.3 (and below), that's
fixed in Bash 4.4 (see
https://groups.google.com/forum/#!topic/gnu.bash.bug/s0YnTR72BlQ ).
Unfortunately, it's going to be a while until Bash 4.4 is available on all
systems.
Can you release an scrypt fix that uses 'command' instead of 'command -p' in
Makefile.in? I don't think it's necessary to use 'command -p' here.
Thank you,
Sebastian