qubes gpg-client[-wrapper] incompatibility

[ThomasWaldmann]

Qubes OS version:

4.0.1-rc1 + updates

Affected component(s):

split-gpg setup / qubes-gpg-client[-wrapper]

---

Steps to reproduce the behavior:

try to upload a python package to pypi.org using:

python setup.py register sdist upload --identity="your identity" --sign

Expected behavior:

Signing / upload succeeds.

Actual behavior:

Upload fails because package.tar.gz.asc does not exist.

Usually gpg puts the signature there, but the qubes-gpg-client[-wrapper] emits it onto the screen (so uses stdout or stderr).

General notes:

Reporting that as I remember it, happened some days ago, see borgbackup/borg#4213.

---

Related issues:

[marmarek]

Do you see with what options qubes-gpg-client-wrapper is called? If you have any control over that command line, try adding --output package.tar.gz.asc.

[ThomasWaldmann]

$ ln -s /usr/bin/qubes-gpg-client /home/user/w/proj-env/bin/gpg
or alternatively (same problem):
$ ln -s /usr/bin/qubes-gpg-client-wrapper /home/user/w/proj-env/bin/gpg

$ python setup.py sdist upload --sign --identity "Thomas Waldmann" --repository testpypi
...
Creating tar archive
running upload
gpg --detach-sign --local-user Thomas Waldmann -a dist/proj-1.0.0.tar.gz
-----BEGIN PGP SIGNATURE-----

iQJHBA...

-----END PGP SIGNATURE-----
WARNING: Uploading via this command is deprecated, use twine to upload instead (https://pypi.org/p/twine/)
error: [Errno 2] No such file or directory: 'dist/proj-1.0.0.tar.gz.asc'

So, gpg usually creates FILE.asc, but the qubes-gpg-client[-wrapper] does not.

[ThomasWaldmann]

BTW, is just created a custom gpg via that symlink.

Is that how it is supposed to be done or is there a more elegant way?

[ThomasWaldmann]

Should default to *.asc, if stdout is wanted, one needs --output -.

[pganssle]

@ThomasWaldmann setup.py upload is deprecated in favor of twine. It would be best to separate your upload into three stages, build, sign and upload, where sign explicitly calls gpg as desired, and upload calls twine.

[ThomasWaldmann]

@pganssle i know, but still this is a bug / incompatiblity in the qubes-gpg-client*. It is intended to implement the same cli api as gpg, but doesn't in this case.

[ThomasWaldmann]

i'll try to fix this. shell scripts are not my strong point, though.

[ThomasWaldmann]

I didn't find an easy fix, but keeping some notes here for someone who wants to try fixing it:

gpg-client-wrapper:

• the problem there is the default for target - it should default to the first non-option argument (== the filename, if any) + ".asc".
• this default might be overridden if -o or --output is given, then we have a non-default target.
• likely the variable output is not needed any more. the condition at the end of the script will just be "$target" = "-" to detect the "stdout wanted" case, in any other case there will be a filename in target.
• i found no easy way to reliably determine the first non-option argument.

gpg-client.c:

• this code also special cases the first non-option argument, so i guess it only works for 1 file?
• gpg --detach-sign --local-user "user name" -a F1 F2 F3 would produce F1.asc, F2.asc, F3.asc when using the original gpg executable.

What I said above applies to gpg signing. There might be other cases that might have a different desired behaviour.

[ThomasWaldmann]

borgbackup/borg#4301 switching to twine there (for whoever may find it useful).

[DemiMarie]

I didn't find an easy fix, but keeping some notes here for someone who wants to try fixing it:

gpg-client-wrapper:

• the problem there is the default for target - it should default to the first non-option argument (== the filename, if any) + ".asc".
• this default might be overridden if -o or --output is given, then we have a non-default target.
• likely the variable output is not needed any more. the condition at the end of the script will just be "$target" = "-" to detect the "stdout wanted" case, in any other case there will be a filename in target.
• i found no easy way to reliably determine the first non-option argument.

This is now fixed in the current wrapper script: qubes-gpg-client-wrapper knows exactly when the options end.

gpg-client.c:

• this code also special cases the first non-option argument, so i guess it only works for 1 file?

That is correct.

• gpg --detach-sign --local-user "user name" -a F1 F2 F3 would produce F1.asc, F2.asc, F3.asc when using the original gpg executable.

This is very difficult to implement in split-gpg, because split-gpg requires that GPG itself not write any files.

Fortunately, there is a solution on the way. split-gpg2 is the eventual replacement for split-gpg. Instead of filtering the options that can be passed to GPG and running the GPG command server-side, split-gpg2 leaves the GPG command alone and instead provides a custom gpg-agent implementation. This has the advantage that all of these corner cases, and more, are handled automatically. It also has vastly reduced attack surface and does not require the qubes.GpgImportKey service. For the specific case of signing, Qubes OS may eventually provide a bespoke qrexec service.

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)

[DemiMarie]

This is a legitimate bug that impacts all versions of split-gpg1, but I don’t think it is worth fixing, especially given that split-gpg2 is nearly ready.