On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <pk...@debian.org> wrote:
> 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 >
