On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote: > On 04/20/18 12:38, Brian wrote: > > T have a script. It contains an important password. > > > > I have encrypted the script with > > > > scrypt dec -t 10 /usr/local/bin/myscript > > Looking at: > > http://manpages.org/scrypt > > > That command decrypts /usr/local/bin/myscript (and I don't know if the -t > option is valid for decryption).
A typo. It should be "enc", not "dec". > > I can, of course, decrypt it with > > > > scrypt dec /usr/local/bin/myscript > > Assuming /usr/local/bin/myscript is ciphertext, that command will print the > script on STDOUT. Another bit of sloppiness. Redirection to a file should have been mentioned. > As scrypt is going to prompt you for a passphrase anyway, why don't you > leave the script unencrypted and revise it to prompt for the "important > password"? > > > and then execute the script. > > How are you executing a script printed on STDOUT? A pipeline? The redirected file was executed with 'eval'. > > The two last steps have been combined into > > > > DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT" > > > > Should I have any more concerns with this command than I have with the > > two-step process? > > If the script is too big to fit in an environment variable, that would be a > problem. That passed through my mind. The script is 73 lines and, fortunately. does fit. Putting the secret in a separate file is, however, a good way to avoid that problem and the one of having trouble evaluating the variable. > Assuming the script fits into an environment variable, evaluating that > variable in double-quoted context requires deep understanding of both your > shell and the script (especially if the script is written for a different > shell, and potentially a different version of the same shell). If you're > intent upon doing it this way, be sure to test thoroughly. > > A pipeline would be more conventional-- decrypt the ciphertext and pipe the > script to the appropriate interpreter. Here is an example using Perl and > the ccrypt tools: > > 2018-04-20 16:59:50 dpchrist@vstretch ~/sandbox/ccrypt > $ ll secret-script.pl > -rwxr-xr-x 1 dpchrist dpchrist 66 2018/04/20 16:58:19 secret-script.pl* > > 2018-04-20 17:00:02 dpchrist@vstretch ~/sandbox/ccrypt > $ cat secret-script.pl > #!/usr/bin/env perl > print "The important password is 'secret'\n"; > > 2018-04-20 17:00:08 dpchrist@vstretch ~/sandbox/ccrypt > $ ./secret-script.pl > The important password is 'secret' > > 2018-04-20 17:00:14 dpchrist@vstretch ~/sandbox/ccrypt > $ ccencrypt --key foo secret-script.pl > > 2018-04-20 17:00:26 dpchrist@vstretch ~/sandbox/ccrypt > $ ll secret-script.pl.cpt > -rwxr-xr-x 1 dpchrist dpchrist 98 2018/04/20 16:58:19 secret-script.pl.cpt* > > 2018-04-20 17:00:30 dpchrist@vstretch ~/sandbox/ccrypt > $ ll decrypt-run-secret.sh > -rwxr-xr-x 1 dpchrist dpchrist 86 2018/04/20 16:57:27 decrypt-run-secret.sh* > > 2018-04-20 17:00:40 dpchrist@vstretch ~/sandbox/ccrypt > $ cat decrypt-run-secret.sh > #!/usr/bin/env sh > echo "The decryption key is 'foo'" > ccat secret-script.pl.cpt | perl > > 2018-04-20 17:00:51 dpchrist@vstretch ~/sandbox/ccrypt > $ ./decrypt-run-secret.sh > The decryption key is 'foo' > Enter decryption key: > The important password is 'secret' I prototyped with gpg but ended up with scrypt because it is memory-hard and slow to decrypt. That seemed to be an advantage; the decryption passphrase could afford to be shorter and not give users here too much to remember or type. I'll certainly take a look at what you suggest, though. That's two recommendations for putting the secret in a separate file; I'll follow the advice. My concern was missing some important security implication but that doesn't appear to be the case. Thanks to Greg Wooledge and yourself. -- Brian.
