gpgtar: Removes existing output file on error
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• ikloecker
	Jun 22 2023, 5:44 PM

Description

gpgtar erroneously removes an existing output file if an error occurs.

Example:

# create an existing output file and a folder to archive:
$ touch do-not-remove-me
$ mkdir foo

# run gpgtar; enter a passphrase when asked for it; deny overwriting the existing file; press Return when asked for new filename:
$ gpgtar --encrypt --symmetric --output do-not-remove-me foo
File 'do-not-remove-me' exists. Overwrite? (y/N) 
Enter new filename: 
gpg: symmetric encryption of '[stdin]' failed: File exists
gpgtar: running /opt/gnupg/master/bin/gpg failed (exitcode=2): General error
gpgtar: creating tarball 'do-not-remove-me' failed: General error

# observe that your precious existing file is gone:
$ ls do-not-remove-me
ls: cannot access 'do-not-remove-me': No such file or directory

Revisions and Commits

rG GnuPG
	rG8d01725a96b5 common: Never remove /dev/null.
	rG7f9e05d73f2c common: Never remove /dev/null.

Related Objects

Mentioned In: T7189: Release GnuPG 2.5.0
T6578: Release GnuPG 2.4.4
T6307: Release GnuPG 2.2.42

Event Timeline

• ikloecker created this task.Jun 22 2023, 5:44 PM

• werner triaged this task as Normal priority.Jun 23 2023, 10:10 AM

• werner added projects: gnupg24, gnupg22.

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

It is not yet clear to me if it is the intended behaviour of GnuPG to remove the --output file on failure (in which case the Portage code would simply need adjusting to use some temporary file instead of /dev/null). Or if this is actually a bug in GnuPG that needs fixing.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Ingo's case is different and related to the fact that though it passes --yes, --no, and --batch to gpg it does not have its own code to to ask for overwriting. That is not consistent. Either we use the standard tar interface (which is to always overwrite) or we use the gpg (PGP2 based) behaviour to ask the user.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Thanks for clarifying!

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

I would simply redirect output via >/dev/null to avoid the problem. Or, if you want to avoid running the command with shell-mode in Python, then read the output in Python but just don't use it. The command doesn't produce large amounts of output.

Alternatively, send an email to gnupg-users mailing list to ask for a better solution to "unlock the binary package signing key". There may be a more elegant solution than your "sign /dev/null" hack.

thesamesam added a subscriber: thesamesam.Aug 28 2023, 5:33 PM

Thanks. For the record, done at https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html.

@iklocker: Which gpg bug to you mean?

For the gpgtar bug we need to decide whether we want to always overwrite or somehow implement an ask the user. Given that gpgtar has no user interaction I tend to go with the first option. Opinions?