Itâs an interesting project with backing of a trust worthy foundation, but with all due respect to the authors, I wouldnât jump all in on it. GPG is just too critically important that you are better off sticking with the project that has more eyes on it and is constantly being developed. While buggy code can cause serious security risks, there isnât much record of that being the case with GPG. The other thing is competence of crypto implementations. Despite there being certain standards GPG follows, there are many instances of GPG-isms where they diverge from IETF standards that are cumbersome or donât make sense for them.
The RPM package manager was ported to Sequoia.
Qubes builder infrastructure uses sequoia. Source:
Gpg in default settings may not verify it, but we use sequoia which is much stricter.
dpkg-source internally uses sq. I figured that out because of a signature verification error trying to build a Kicksecure package. It failed because sq keystore is different from gpg keystore.
+ dpkg-source --require-strong-checksums --require-valid-signature -x /home/user/derivative-binary/genmkfile-packages-result/genmkfile_13.0-1.dsc /tmp/tmp.ImjZq87mKV/
No key to check checksum from 6E979B28A6F37C43BE30AFA1CB8D50BB77BB3C48
1 unknown checksum.
Error: Verification failed
dpkg-source: error: cannot verify inline signature for /home/user/derivative-binary/genmkfile-packages-result/genmkfile_13.0-1.dsc: no acceptable signature found
The dpkg-source issue hard to debug⌠Whatâs the file to add my sq public key? As per dpkg source code scripts/Dpkg/Vendor/Debian.pm
if ($hook eq 'package-keyrings') {
return ('/usr/share/keyrings/debian-keyring.gpg',
with /etc/dpkg/origins/default pointing to /etc/dpkg/origins/debian. Otherwise, dpkg might use different vendor (distribution) specific package-keyrings.
Importing my key to /usr/share/keyrings/debian-maintainers.gpg helped.
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/debian-maintainers.gpg --import /usr/share/keyrings/derivative.asc
I locally added some debug output to /usr/share/perl5/Dpkg/OpenPGP/Backend/Sequoia.pm
This is what dpkg-source is actually executing:
sq verify --signer-cert /usr/share/keyrings/debian-keyring.gpg --signer-cert /usr/share/keyrings/debian-nonupload.gpg --signer-cert /usr/share/keyrings/debian-maintainers.gpg /home/user/derivative-binary/genmkfile-packages-result/genmkfile_13.0-1.dsc
Command
sq keyring list /usr/share/keyrings/debian-keyring.gpg | grep adrelanos
showed that
0. 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA Patrick Schleizer <adrelanos@kicksecure.com>
Not the cleanest solution.
Debianâs version of sq might not have the new sq feature of a local keystore:
That would have probably made this a lot easier.
Debian -- Details of package sq-keyring-linter in bookworm not available in trixie, sid but thatâs okay.
Quote https://tracker.debian.org/news/1636301/removed-101-4-from-unstable/
deprecated upstream, functionality moved to sq as âsq cert lintâ
Use instead:
sq cert lint --cert-file
Comment, status of Sequoia-PGP:
port Qubes Split GPG to Sequoia-PGP ¡ Issue #8241 ¡ QubesOS/qubes-issues ¡ GitHub
Very minor, not affecting anything:
`--import-options show-only,import-minimal` not implemented (#157) ¡ Issues ¡ sequoia-pgp / sequoia-chameleon-gnupg ¡ GitLab
Qubes is also porting to Sequoia-PGP. Example use case of sq here:
The APT package manager has been ported to sqv as of Debian trixie.
Kicksecure, and Whonix have been ported from GnuPG ("gpg") to Sequoia-PGP (âsqâ).
Reasons:
- The APT package manager has been ported to sqv as of Debian trixie.
- The RPM package manager was ported to Sequoia.
- Qubes builder infrastructure uses sequoia.
- https://gpg.fail/
- Issues with PGP
- GnuPG Usability Security Issues
Therefore, gpg-bash-lib is no longer in use