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 This clearly writes the unencrypted tarball out to disk. 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)? 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. > 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