Re: ' command -p' in Makefile.in

[Graham Percival <gperciva@tarsnap.com>]

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
>