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 >
