Hi,
rather than trying to appeal to authority like Marc - I could have been
wrong -, I will point out that my first point was not actually addressed
at all:
++ mktemp -d /dev/shm/pw.sh.XXXXXXXXXXXXX
+ WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
[...]
+ decrypt /home/pkern/.pw/pw.tgz
+ local archive=/home/pkern/.pw/pw.tgz
+ local 'opts=--quiet --yes --batch '
+ [[ -z '' ]]
+ gpg2 --quiet --yes --batch --passphrase-fd 0 /home/pkern/.pw/pw.tgz.gpg
+ local err=0
+ [[ 0 -ne 0 ]]
+ tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
+ rm -f /home/pkern/.pw/pw.tgz
So, you have not looked at the code trying to follow the logic.
You have just tried to debug it. This way you cannot get the full picture.
But nevertheless it is useful for finding ways to break the script.
By the way, you may notice that *there is* error checking there.
This clearly writes the unencrypted tarball out to disk.
It writes to `/dev/shm` which is not disk. It writes to a random
temporary directory, so that it cannot be guessed. It removes
the unencrypted content as soon as the operation is performed.
All this happens almost instantly, it never stays unencrypted
for a long time. It is almost the same thing as using a pipe (|).
What is wrong here? I have been using it for 2-3 years and
never had a problem.
Now you might say "I will fix that". But I think the behavior in this
thread was sufficient evidence to not package this in Debian. I know it
is hard to deal with criticism and I could have phrased my mail
differently, but this is clearly not the way. What if there is another
contentious bug? Will you also insult your users and your fellow
developers (no matter how senior)?
You comments showed that you did not study it carefully, it is not hard
to deal with criticism. For example you claimed there is no error handling,
which is not true.
I have almost 20 years programming experience, and have worked many
years with bash scripting, using it in unconventional ways as well (which
make you shy away from it). Maybe you have more experience than me
but you have to show it on your comments.
I could not have phrased it better than Simon with "let's not try to
audit scripts without `set -e`" and his other point of not using shell
scripts for non-trivial matters. Yes, it's a valid language. Yes, people
can write good scripts in it. But it is very hard and this thread has
not given me evidence that the creation process of this script mastered
it. Especially how hard it is to reason about a script that can fail
silently in all places. Especially if it's something that handles a
user's secrets.
Let's agree that we don't agree about the usefulness of `set -e`
and about the usefulness of Bash for serious matters.
Regards,
Dashamir
> Whoever stops auditing this Bash application because it does not> start with `set -e`, does not have the right skills and experience
for> reviewing/auditing it.
And these ad hominems are just unhelpful.
Kind regards
Philipp Kern