I wrote a small script to get around the issue when using pdfencrypt on the command line the password is always echoed as well as being saved to the 'history'.
#!/bin/bash
export LC_ALL=de_DE.latin1
while true; do
echo "please select Pdf input file:"
read -e -r infile
if file --mime-type "$infile" | grep -q pdf$; then
echo
break
else
printf "\nis not a PDF file :-(\n\n"
fi
done
echo "please type in Pdf output filename"
echo "without extension (.pdf):"
read -e -r outfile
if [ -f "${outfile}.pdf" ]; then
echo
echo "File allready exists!";
echo "please enter a new filename, or the same to override: "
read -e -r outfile
fi
echo "please type in Password"
echo "(only ASCII chracters recommended)"
read -r -s
pdfencrypt "$infile" -p "$READ" -o "${outfile}.pdf" \
&& echo "success, ${outfile}.pdf is encrypted :-)" \
|| echo "failed, did you use non ASCII characters for Password?"
exit
I had the problem with following non ASCII-Characters in the password:
§ ä ö ü etc. When I used any of those for encryption I got the following error:
Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT
I solved this by including export LC_ALL=de_DE.latin1 in the script. Though there still are some compatibility problems when using any of those characters, therefore I added a recommendation not to use non ASCII in the password.
(I know that PDF encryption itself is pretty low-level security but I sometimes like to add this level when sending files via e-mail etc...)
bash(or any other shell) in an attempt to mask passwords is insecure: any(!) process or user on this machine can do aps -axand have a look at all processes... and all of their command line parameters. In some regard a password is more visible that way, and get an even wider audience, compared to only "on screen and in history". \$\endgroup\$pdfencrypton my machine (and thus, nomanpage), but the usual workaround for this is to check if the program in question can read the password from a file (with a different argument). If so, you could set an appropriateumask, write the password into a file using the built-inecho(which isn't a separate process and doesn't show up withps), andrmthe file after encryption. Files can be better protected than process information. - This might even be a workaround for the UTF-8 problem. \$\endgroup\$manpage ofpdfencryptunfortunately there isn't any, at least not installed with my package, got to check on github later... if I go for--helpI get about six option where reading the password from file is not supported. Maybe I'll make a feature request, when I visit the githup page later... :-) \$\endgroup\$