Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003601Site[All Projects] Documentationpublic2019-02-07 13:402023-05-17 01:01
ReporterWubTheCaptain 
Assigned ToBlzut3 
PrioritynormalSeveritytweakReproducibilityalways
StatusassignedResolutionopen 
PlatformOSDebian GNU/LinuxOS Version
Summary0003601: debian.drdteam.org suggests using deprecated "apt-key add" command
Description
Quote from apt-key(8)
Note: Instead of using this command a keyring should be placed directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive name and either "gpg" or "asc" as file extension.
Steps To Reproduce
Quote from https://debian.drdteam.org
To use, use the following command or add the "deb ..." line to your /etc/apt/sources.list:

$ wget -O-'http://debian.drdteam.org/drdteam.gpg [^]' | sudo apt-key add -
$ sudo apt-add-repository 'deb'http://debian.drdteam.org/ [^]' stable multiverse'
Additional Information'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774 [^]'
Attached Files? file icon drdteam-archive-keyring_2012.05.08+0.tar.xz [^] (6,060 bytes) 2022-01-16 00:44

- Relationships

-  Notes
User avatar (0020339)
WubTheCaptain (reporter)
2019-02-07 13:44
edited on: 2019-02-07 13:45

I suggest the following syntax to fix this issue:

wget -qO -'http://debian.drdteam.org/drdteam.gpg [^]' |
    sudo tee /etc/apt/trusted.gpg.d/drdteam.gpg |
    gpg -q -n --import --import-options import-show -


This will also dry-run GnuPG quietly to display the fingerprint for apt-secure(8) infrastructure. This requires GnuPG version 2.1.14 or later. No transitional package (gnupg2) is required in Debian, since Debian 9 (stretch).

(I didn't include HTTPS scheme here, as the original syntax doesn't either and apt can do fine securely with HTTP given apt-secure(8) precautions.)

User avatar (0020344)
WubTheCaptain (reporter)
2019-02-07 15:25
edited on: 2019-02-07 16:43

By the way: GPG keyboxes are unsupported by apt(8) at this time. This means the following two variations of GPG commands are incompatible (and probably overengineered):

wget -qO -'http://debian.drdteam.org/drdteam.gpg [^]' |
    sudo gpg -q --import --import-options import-show --primary-keyring \
    /etc/apt/trusted.gpg.d/drdteam.gpg -

wget -qO -'http://debian.drdteam.org/drdteam.gpg [^]' |
    sudo gpg -q --import --import-options import-show --no-default-keyring \
    --keyring /etc/apt/trusted.gpg.d/drdteam.gpg -


The warning would be:

Quote
W: The key(s) in the keyring /etc/apt/trusted.gpg.d/drdteam.gpg are ignored as the file has an unsupported filetype.


User avatar (0020350)
WubTheCaptain (reporter)
2019-02-07 16:59

Should 0003610 be fixed as I expect it to be, the command should become:

wget -qO -'http://debian.drdteam.org/drdteam.asc [^]' |
    sudo tee /etc/apt/trusted.gpg.d/drdteam.asc |
    gpg -q -n --import --import-options import-show -


If not, then the right choice (as a workaround) would be:

wget -qO -'http://debian.drdteam.org/drdteam.gpg [^]' |
    sudo tee /etc/apt/trusted.gpg.d/drdteam.asc |
    gpg -q -n --import --import-options import-show -
User avatar (0020357)
Blzut3 (administrator)
2019-02-10 07:39

Is the gpg import line actually needed? Experimenting with a docker container it seems that just adding the key to trusted.gpg.d is enough?
User avatar (0020361)
WubTheCaptain (reporter)
2019-02-11 14:26

Quote from Blzut3
Is the gpg import line actually needed?


TL;DR: I think so?

In an unlikely event the debian.drdteam.org server would be compromised by a third-party, displaying the fingerprints and verifying them against some chain of trust (OpenPGP signatures or documentation in Doomseeker, for example), the GPG dry-run import line may mitigate the effectiveness of such attack. apt-key add also wouldn't display the fingerprint.

The man page says:

Quote from apt-key(8)
It is critical that keys added manually via apt-key are verified to belong to the owner of the repositories they claim to be for otherwise the apt-secure(8) infrastructure is completely undermined.


In an unlikely event the HTTPS website is also unavailable or blocked at a site, the same principle of key fingerprint verification would also apply to connections over insecure HTTP.

I believe it's better than blindly trusting the key. https:// may provide some additional security (0003606), on the assumption the webserver/HTTP(s) proxy is configured securely.
User avatar (0020383)
WubTheCaptain (reporter)
2019-02-11 22:45

I'm probably going to actually end up submitting a package to Debian soon, called drdteam-archive-keyring.

Debian's soft freeze is tomorrow, so this won't make it to the next stable release however. It will be available from testing and unstable initially, maybe later backported to stretch-backports if feasible.
User avatar (0020384)
WubTheCaptain (reporter)
2019-02-12 00:05

Additionally, I'd like the drdteam-archive-keyring to prompt for a question "do you want to install drdteam.list to /etc/apt/sources.list.d?" with debconf. I'll do that, for convenience.
User avatar (0020385)
WubTheCaptain (reporter)
2019-02-12 13:47

By the way, ignore my suggestions too: Keys added to /etc/apt/trusted.gpg.d are valid signing keys for all repositories, including the main ones from your operating system. Yikes!

Fortunately, there is /usr/share/keyrings. I'll hope to set that up soon.

(oops, meant to post this yesterday)
User avatar (0021894)
WubTheCaptain (reporter)
2021-12-13 21:43

Quote from APT-KEY(8)
apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.
User avatar (0021895)
Blzut3 (administrator)
2021-12-14 06:08

Thanks for the heads up. Looked into possibly including GUI instructions and immediately ran into a bug from 2018 that still isn't fixed:'https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1795278 [^]' Fun!

Jumping off your mention of making a drdteam-archive-keyring. I wonder if it would be a good idea to make deb that users could download and install to provide the gpg key and list file (no prompt in this case).

Obviously would also provide the command line instructions for those that want it, just curious what we can do to make installing the repo as simple as possible for new users.
User avatar (0021901)
WubTheCaptain (reporter)
2021-12-16 03:16
edited on: 2021-12-16 23:03

Quote from Blzut3
I wonder if it would be a good idea to make deb that users could download and install to provide the gpg key

I believe this is the best practice, though it should also be then distributed via the apt repository for updates.
Quote from Blzut3
and list file (no prompt in this case).

I'm not sure. The debconf file (for Debian / .deb packages) has priorities for prompts. The list file can be manual or perhaps managed by a package manager, perhaps as a separate package.
Quote from Blzut3
just curious what we can do to make installing the repo as simple as possible for new users.

This is how my computer is configured to use the DRDTeam package repository somewhat securely without a keyring package right now. It is not newbie friendly in the first place.
SOURCEPARTS='/etc/apt/sources.list.d/'
PREFERENCESPARTS='/etc/apt/preferences.d/'
eval "$(apt-config shell SOURCEPARTS Dir::Etc::sourceparts/d)"
eval "$(apt-config shell PREFERENCESPARTS Dir::Etc::preferencesparts/d)"

wget -O -'https://debian.drdteam.org/drdteam.gpg [^]' | sudo tee /usr/local/share/keyrings/drdteam-archive-keyring.gpg 
# Spews binary garbage output to stdout.
# Legacy apt .list format:
# echo "deb [signed-by=/usr/local/share/keyrings/drdteam-archive-keyring.gpg]'https://drdteam.example/debian/ [^]' 
stable multiverse" | sudo tee ${SOURCEPARTS}drdteam.list
# Newer .sources format:
echo "Types: deb deb-src\nURIs:'https://debian.drdteam.org/\nSuites: [^]' stable\nComponents: multiverse\nSigned-By: 
/usr/local/share/keyrings/drdteam-archive-keyring.gpg" | sudo tee ${SOURCEPARTS}drdteam.sources

echo "Package: *\nPin: origin debian.drdteam.org\nPin-Priority: 100" | sudo tee {$PREFERENCESPARTS}drdteam.pref

On my computer, I actually also assume the system apt directory (Debian packages) is located at /etc/apt and then place some symlinks from there to /usr/local/etc/apt directories (config directories I've created for third-party packages) to keep the package-configured APT stuff somewhat separated from manual configurations. For the sake of above example, I did not do that symlink separation.
I wish this could be simpler:
wget'https://debian.drdteam.org.example/drdteam-archive-keyring.deb [^]'
# An (optional) step here to perhaps verify the signature of said keyring package (GnuPG)
dpkg -i drdteam-archive-keyring.deb
# Possibly repeat for a "drdteam-archive-sources.deb" package. Depends on drdteam-archive-keyring 
(which recommends drdteam-archive-sources).

Note there are some differences between Debian and Ubuntu and their various distributions: Some have cURL installed by default, some have Wget. I don't recall the details anymore.

User avatar (0021902)
WubTheCaptain (reporter)
2021-12-16 03:19

Quote from WubTheCaptain
I believe this is the best practice, though it should also be then distributed via the apt repository for updates.

Note this will fail if the keys in the keyring package also expire. Then it will require manually updating the keyring package again.
User avatar (0021903)
WubTheCaptain (reporter)
2021-12-16 03:24
edited on: 2021-12-16 03:25

Quote from Blzut3
Obviously would also provide the command line instructions for those that want it, just curious what we can do to make installing the repo as simple as possible for new users.

GUI: Download this package file to any directory on your computer and open it. Hope the .deb file association is right and the operating system knows what to do with it and install it (maybe often not, often opens up in an archive manager program like an unzipper program).

User avatar (0021904)
WubTheCaptain (reporter)
2021-12-16 03:43

As much as I don't also like Snap co-existing with dpkg/apt (Debian), using the Snap package manager and publishing the packages via the Snap Store is an option for Ubuntu distributions. Since Canonical created Snap, I would not be surprised if Ubuntu will make Snap the default manager in Ubuntu at some point (it's already the only package manager on Ubuntu Core, a distribution for Internet-of-Shit devices). At the moment, it also seems to require (?) manual user interaction on Ubuntu to install Snap first.
Full disclosure: Nobody's paid me anything to shill this interest of a third-party store service.
User avatar (0021905)
Blzut3 (administrator)
2021-12-16 04:14

My experience with snap wasn't very good (stuff like the app failing to launch the first time you run it in a boot), so I prefer building and using native packages. At least that was my experience when I used the Slack snap a few years ago that one time there was an issue with the native deb on the freshly released version of Ubuntu. Went back to native as soon as that was fixed. To this day I still hear about quirks of snap and flatpak where apps that interact with hardware resources tends to be hit and miss.

Snap is installed on Ubuntu by default, although I know many people like myself that just remove it. If I recall correctly with 21.10 they started installing the Firefox snap by default, but they still provide the deb in the repo.

In regards to Ubuntu Core, that's a totally different distribution model based around immutable file system images. So snaps make a lot of sense there. I don't really see that by itself as any indication that Canonical will move away from apt. Anytime soon at least, but it is true that they're trying to push third party devs to adopt it. I do see value in the immutable model, so in the long run you're probably right but there's a lot of work that still needs to be done to get the desktop user experience solid for those kinds of distros.
Quote from WubTheCaptain
I'm not sure. The debconf file (for Debian / .deb packages) has priorities for prompts. The list file can be manual or perhaps managed by a package manager, perhaps as a seperate package.

Separate package would definitely be out of the question on my end since we'd definitely need to work under the restriction that the user will only download one deb to install the repo.

If there's a prompt level that isn't shown by default to users then perhaps we can get the best of both worlds. I definitely wouldn't want to prompt standard users since there's only one reason anyone would download and install the deb in question. Users shouldn't be asked questions which the computer already knows the answer to.
User avatar (0021906)
WubTheCaptain (reporter)
2021-12-16 04:31

I'm creating a Debian source package for the DRDTeam archive keyring right now. If it's not posted here by tomorrow, I lost interest.
I'm deriving and adapting it for DRDTeam's needs from an older keyring source package I authored in 2019, matrix-archive-keyring.
User avatar (0021908)
WubTheCaptain (reporter)
2021-12-16 21:07

Quote from Blzut3
If there's a prompt level that isn't shown by default to users then perhaps we can get the best of both worlds.

The priority is "medium". See man 7 debconf. "Normal questions that have reasonable defaults."
Quote from Blzut3
I definitely wouldn't want to prompt standard users since there's only one reason anyone would download and install the deb in question. Users shouldn't be asked questions which the computer already knows the answer to.

I'll give the choice to opt-out of APT data sources anyway (dpkg-reconfigure --priority=medium drdteam-archive-keyring). My former matrix-archive-keyring already supported this kind of configuration, so much of it was ready for drdteam-archive-keyring. I've already found some improvements to be made, so this will take a moment to package and test.
User avatar (0021910)
WubTheCaptain (reporter)
2021-12-16 22:18
edited on: 2021-12-16 22:21

Alright, I'm using this issue as an epic (because I'm a currently lowly "reporter" in the "Site" project on this tracker).

Blzut3: I'd like the package to verify the integrity of the keyring file, so if you would, please publish an OpenPGP clear-signed SHA256 or SHA512 checksum file signed with the release key (SHA256SUMS.txt.asc). It should be similar to this:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

2657b4ea7c9f6bcc3a15c80cf0a052c77b61d11ba454c7f7311393c4b8627fae  drdteam.gpg
-----BEGIN PGP SIGNATURE-----

[signature goes here]
-----END PGP SIGNATURE-----

I've done the following to produce the above example:
$ wget -q'https://debian.drdteam.org/drdteam.asc [^]'
$ gpg --no-options --no-default-keyring --no-auto-check-trustdb --import-options import-export --import 
--no-keyring drdteam.asc > drdteam.gpg
gpg: Total number processed: 1
$ file drdteam.gpg
drdteam.gpg: OpenPGP Public Key Version 4, Created Tue May  8 06:31:46 2012, RSA (Encrypt or Sign, 2048 
bits); User ID; Signature; OpenPGP Certificate
$ sha256sum drdteam.gpg
2657b4ea7c9f6bcc3a15c80cf0a052c77b61d11ba454c7f7311393c4b8627fae  drdteam.gpg
$ sha256sum drdteam.gpg > SHA256SUM.txt
$ # sign with gpg --clearsign here, please.

This also matches the available drdteam.gpg file at the repository. NB: I will be installing it as drdteam-archive-keyring.gpg instead of the above filename.
It'd also be ever so slightly easier to have this info somewhere in a Git repository with the keys. Currently the package-in-works I'm authoring uses 3.0 native packaging format (inherited from matrix-archive-keyring), but it could be an improvement to switch to 3.0 quilt format if there was an "upstream repository" with this information for drdteam-archive-keyring (able to distribute/download the debian/ directory as a separate tarball from the upstream .orig tarball containing just the key and checksum file, and then able to apply quilt patches as necessary). I would then also add Version Control System (VCS) fields to the Debian package.
I assume at some point it makes sense to add a hyperlink from the repository index to the Git repository anyway for downloading the source or .deb release for the keyring to use it, so publishing the key info in a Git repository should be a win anyway.
Git repo idea: master branch is just the key and SHA256SUM (and maybe a README), debian branch is that plus the debian directory (easier to maintain that way when separately from the master branch).

User avatar (0021911)
WubTheCaptain (reporter)
2021-12-16 22:47

If we'll release a .orig source tarball from the Git repository (without the debian/ directory), the master branch version (Git tag) should be "2012-05-08" for the current keys to make 3.0 quilt detect it easier IIRC. I need to refresh my memory how exactly this is going to work.
User avatar (0021912)
WubTheCaptain (reporter)
2021-12-17 01:16
edited on: 2021-12-17 01:21

Quote from Blzut3
If there's a prompt level that isn't shown by default to users then perhaps we can get the best of both worlds.

I'll see if I can or should drop the debconf question thing (and thus the dependency), because of a bit confusing Debian policy on hard links (10.7.3. Behavior) to conffiles and policy requirements to preserve user configuration.
matrix-archive-keyring used the old one-line-style format sources.list file. The way to matrix-archive-keyring enabled and disabled the APT data sources was managed with symlinks (which was manually managed by maintscripts written by me as a best-effort, although unlikely it was still not 100% bulletproof to not unintentionally remove the user's non-package APT configuration). It was a requirement for that keyring to support the older one-line-style format for Debian 8 (jessie), because that upstream also supports/supported that distribution back in 2019. It also had code to automatically generate the appropriate sources.list for the architecture when the package was installed based on some lsb_release info; this also required using maintscripts, because a conffile could not be used (and that was problematic with user-made changes to config files).
Immediately from the start I had rewritten the sources.list to the Deb822-style format (drdteam.sources) for drdteam-archive-keyring, because from the start I decided to only support Debian 11 (bullseye/stable) and later. The Deb822-style format allows "Enabled: no" or "Enabled: yes". I've also taken the shortcut to hardcode the suites and components to "stable multiverse" for drdteam-archive-keyring with the current status quo of the repository, which has allowed to skip the sources.list generation in mainscripts.
Quote from Blzut3
I definitely wouldn't want to prompt standard users since there's only one reason anyone would download and install the deb in question.

OpenBSD likes to require manually enabling "services" after install, which is unlike Debian where services are enabled by default on install.
Debconf has a cache for answers. If the default answer is set to "yes" to enable the APT data sources, I would use sed to replace the user's configuration to "Enabled: yes" and/or ship the default source list with it enabled. However if the user edits APT $SOURCEPARTS/drdteam.sources manually and sets it to "Enabled: no" instead of using dpkg-reconfigure to reconfigure the Debconf answers, on next update the package may be programmed to set it back to "Enabled: yes" if the default is to answer yes without prompting the user? To solve this, I'd need more hacks to check the return status of "grep" and introduce that as a dependency to the package. So the package dependencies would now be grep, sed and debconf.
Now if the user removed the "Enabled:" line, sed/grep wouldn't be able to find/replace anything on next upgrade. The default meaning is "Enabled: yes". More branches to make debconf / dpkg-reconfigure work correctly.
The easiest approach for a developer is to not use debconf. Because the installed keyring can be used stand-alone to verify .deb packages, it has uses without using the APT data source. Now (as a developer) I don't have a sensible default value anymore. As an user, I would probably have a sensible default value to use the APT data sources, but I can't meet both expectations at once.
There's also the policy that configuration files must remain on the user's system until the package is purged. If the keyring package is removed but a configuration file is preserved at APT $SOURCEPARTS/drdteam.sources, APT will most likely complain the keyring is missing and the system seems broken. So back to square one, let's enable/disable APT data sources with maintscript symlinks, or forcefully overwrite the user's configuration to "Enabled: no"? With prior, dpkg is unaware of these symlinks (created by maintscripts) and will not prevent other packages from overwriting them. With the latter, it's probably a Debian policy violation.
I love packaging.

User avatar (0021913)
Blzut3 (administrator)
2021-12-17 01:35

Adding sources is definitely one of the things that RPM does better from an end user perspective. I honestly don't think Apt has the ability to do a repo source in a package cleanly. Consider that doing a distribution upgrade disables third party sources, so once you do that you can't just reinstall the package to enable the source. The user would have to go to software sources dialog and turn it back on or something like that.

Slack and Chrome solve this by having a daily cron job detect if a distro upgrade was performed and re-enable the repo source. Which is gross hack that I certainly wouldn't expect in an upstream package, but I may consider doing something like that in my repo. (Although I don't know why they did a daily task instead of a once per boot task. Seems overkill.)

Anyway, in regards to your package. I'm happy to create a repo on my personal Bitbucket if that helps.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

2657b4ea7c9f6bcc3a15c80cf0a052c77b61d11ba454c7f7311393c4b8627fae drdteam-archive-keyring.gpg
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEDY+QCrd7tQTyxp56OSIDq6+IVAsFAmG76JQACgkQOSIDq6+I
VAtxxAf/XJ+LWUMseqzGNW+NKftktAu5LxYVOXTpQ4vfhvJTDiHVSFd6k9/YODxE
nGWGHgWAm5MngjF7sjE4JgmfqVARYwnCBsLj27y8569rGltRfurlK4SF70lAZEn4
ArbibUjlnRZaRdvRXniEcryOFRZeUZxIBX9ZgT+cmOhb2L4IgaVN70SxcvTGCgEL
Bv0KNnYu9r5DtBEjf64I1/Q4F+ns8EFla5lp/T9aenN2OPhT+XJvDH0HBUjLmdIM
f6zl/g1ot0YUvT94hN9LorN3YE/wetpzBG+w/y2x3CJ9mydP3TjnNc/sgeN9M7Ei
pyodl+jQDFHTeFLBXQK8AEFH3s9Dog==
=PpJ7
-----END PGP SIGNATURE-----
User avatar (0021914)
WubTheCaptain (reporter)
2021-12-17 01:40
edited on: 2021-12-17 01:43

Quote from WubTheCaptain
There's also the policy that configuration files must remain on the user's system until the package is purged. If the keyring package is removed but a configuration file is preserved at APT $SOURCEPARTS/drdteam.sources, APT will most likely complain the keyring is missing and the system seems broken. So back to square one, let's enable/disable APT data sources with maintscript symlinks, or forcefully overwrite the user's configuration to "Enabled: no"? With prior, dpkg is unaware of these symlinks (created by maintscripts) and will not prevent other packages from overwriting them. With the latter, it's probably a Debian policy violation.

And here's how overwriting breaks the user's expectations:
  1. User installs the .deb.
  2. The user chooses "yes" to enable data sources, or it's enabled by default by the package.
  3. User removes (not purges) the package. By Debian policy to keep configuration files, we keep the APT source list; APT will complain about a missing keyring. Not good.
  4. Workaround: postrm maintscript overwrites the user's configuration to disable APT sources, to make the system not feel broken.
  5. User installs the .deb again.
  6. Maintscripts, if written as expected with debconf hacks, will use "grep" to see the user's choice was "no" for APT data sources (and updates debconf answers). The user has now an issue of not being able to use apt to install DRD Team packages, and needs to reconfigure it manually.

I think it needs to be symlinks, damn it.

User avatar (0021915)
WubTheCaptain (reporter)
2021-12-17 04:53

Quote from Blzut3
Anyway, in regards to your package. I'm happy to create a repo on my personal Bitbucket if that helps.

While building, I was reminded I can't have my 3.0 native package revisioned like a 3.0 quilt package.
$ head -n 1 debian/changelog
drdteam-archive-keyring (2012.05.08-0) UNRELEASED; urgency=low
$ debuild -us -uc
# ...
 dpkg-source -i -I -b .
dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have 
a revision
dpkg-buildpackage: error: dpkg-source -i -I -b . subprocess returned exit status 25
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -I failed

I'm currently working around this with a 3.0 native version number 2012.05.08+0 for my internal testing, but I don't see this fit for release as such. 3.0 quilt should have 2012.05.08-1 for the first release, then 2012.05.08-2 for the next drdteam-archive-keyring Debian package patch, yyyy.mm.dd-1 for the next key release, etc.
So, please create a personal Git repo with at least SHA256SUMS.txt.asc and drdteam.asc. 🙂 Currently, I also have no good Debian-ish way to point in the 3.0 native package where the SHA256SUMS.txt.asc came from; easier if I can point to a Git repository for it.
Current package status: The package builds and installs the keyring & configuration for APT. APT is managed with symlinks to package configs and dpkg-reconfigure (debconf) is there. Still working on making sure the APT data sources are enabled by default only for i386 and amd64 (status quo) and I'm not sure right now what it does with architectures, because I removed some debconf scripts early on. I've also improved the APT symlinking to be more idiot-proof, so APT system configuration should never be overwritten if the configuration didn't come from this package. I'll post a git-request-pull or something when I have something usable to share (hoping to use the 3.0 quilt format).
User avatar (0021916)
WubTheCaptain (reporter)
2021-12-17 04:56
edited on: 2021-12-17 04:59

Quote from WubTheCaptain
So, please create a personal Git repo with at least SHA256SUMS.txt.asc and drdteam.asc. 🙂 Currently, I also have no good Debian-ish way to point in the 3.0 native package where the SHA256SUMS.txt.asc came from; easier if I can point to a Git repository for it.

Consider also including a .gitignore file for the following:
drdteam-archive-keyring.gpg
*.gpg~


User avatar (0021951)
Blzut3 (administrator)
2021-12-20 04:28

Is the .gitignore suggestion because the key is currently called drdteam.gpg and you need to rename it temporarily? I have no opposition to renaming the key on my end, it's only named as it is because I didn't know Debian had a guideline.

FYI, I did receive your email.
User avatar (0021952)
WubTheCaptain (reporter)
2021-12-20 06:25

Quote from Blzut3
Is the .gitignore suggestion because the key is currently called drdteam.gpg and you need to rename it temporarily?

It's because I'm building the keyring from an armored key (a human-readable "source", drdteam.asc) and outputting the output as drdteam-archive-keyring.gpg (a temporary file). I've currently configured it as follows (shortened for clarity):
Quote from debian/rules
KEYRING = drdteam-archive-keyring.gpg

"$(KEYRING)": drdteam.asc
        $(GPG_BIN) $(GPG_OPTS) --import-options import-export --import $< > $@

Quote from debian/drdteam-archive-keyring.install
drdteam-archive-keyring.gpg usr/share/keyrings

I also didn't know if you will, or would, upload the file named drdteam.gpg from the web directory to a repository, so I can just ignore it and use the name I expect to see in /usr/share/keyrings. Makes it easier for debian/drdteam-archive-keyring.install syntax too (see dh_install(1)).
User avatar (0021954)
WubTheCaptain (reporter)
2021-12-20 06:49
edited on: 2021-12-20 06:51

I could theoretically have multiple keys like wubthecaptain.asc, blzut3.gpg and so on, but in the end (assuming they were all active keys and not e.g. emeritus keys for another keyring), all those individual keys would be concat'd into one keyring named drdteam-archive-keyring.gpg.
I don't know if Debian has a guideline per se, but there are a few names other projects use:
  • debian-archive-bullseye-automatic.gpg
  • debian-archive-bullseye-security-automatic.gpg
  • debian-archive-bullseye-stable.gpg
  • debian-archive-buster-automatic.gpg
  • debian-archive-buster-security-automatic.gpg
  • debian-archive-buster-stable.gpg
  • debian-archive-keyring.gpg
  • debian-archive-removed-keys.gpg
  • debian-archive-stretch-automatic.gpg
  • debian-archive-stretch-security-automatic.gpg
  • debian-archive-stretch-stable.gpg
  • debian-keyring.gpg
  • debian-maintainers.gpg
  • debian-nonupload.gpg
  • debian-role-keys.gpg
  • ubuntu-archive-keyring.gpg
  • ubuntu-master-keyring.gpg

etc. For the purpose of this key, I chose what seemed the most sensible name: drdteam-archive-keyring.gpg. I've also seen ${projectname}-release-key{,-2020}.{asc,gpg}, but I've ended up renaming that one on my system (they have no keyring package, so I installed it manually).

User avatar (0021955)
WubTheCaptain (reporter)
2021-12-20 07:14

Instead of worrying about .gitignore, if I feel like it will be better, I may add debian/.gitignore and dump the temp files into debian/tmp/ instead.
User avatar (0021962)
Blzut3 (administrator)
2021-12-21 08:49

I figured name-archive-keyring.gpg was the standard since this page references that it should be available with that name:'https://wiki.debian.org/DebianRepository/UseThirdParty [^]'

I like the idea of using a tmp directory and ignoring that. That feels more like an out of tree solution (even if it isn't).
User avatar (0022077)
WubTheCaptain (reporter)
2022-01-16 00:45

I've stalled on this, no progress made since December 17, 2021. I'm uploading the source package to this issue tracker (which Zalewa and Blzut3 had early access to, via email) so it doesn't get lost.
User avatar (0022538)
WubTheCaptain (reporter)
2022-12-19 17:56
edited on: 2022-12-19 17:59

0003601:0021894:
Quote from WubTheCaptain
Quote from APT-KEY(8)
apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.

A reminder that Ubuntu 22.10 was released on 20 October 2022. Hinted by 0004062. The documented instructions on DRDTeam APT repository page may have become dated and not work on Ubuntu 22.10, if the above was done by distro/APT packagers as announced.
I've found the apt-key manual page online for Ubuntu 22.10, with no immediately noticeable changes from 22.04.

User avatar (0022559)
Blzut3 (administrator)
2022-12-23 03:08

Noting here that the Doomseeker website has lacked the gpg key addition command this whole time.
User avatar (0022562)
Blzut3 (administrator)
2022-12-23 20:30

Updated instructions to wget into /etc/apt/trusted.gpg.d. This isn't the ideal solution since it's better to use a repo specific keychain but apt-add-repository doesn't support the extended syntax and don't want to add more friction. But it's no more extra work to the user and doesn't produce warnings.

If the keychain/list package materializes I'd be happier to provide longer manual instructions since users who don't care to know the details could just be directed to install that package.

Unless I'm forgetting how to access things, I don't believe I have access to the zandronum.com site at this time so can't change that.
User avatar (0022570)
WubTheCaptain (reporter)
2022-12-30 11:35
edited on: 2022-12-30 11:44

0003601:0022562:
Quote from Blzut3
If the keychain/list package materializes I'd be happier to provide longer manual instructions since users who don't care to know the details could just be directed to install that package.

It is available as source tarball here, and it is usable (as a proof of concept). It doesn't checksum or test the key in the package during source build, however. You can build it (preferably bump the version number first with a Debian changelog note) and distribute the resulting package to users, if you think it does what you want.
Ideally, the keyring package source would live in a Git repository somewhere.

User avatar (0022571)
WubTheCaptain (reporter)
2022-12-30 11:37
edited on: 2022-12-30 11:38

I will also point out the existence of another (unrelated) keyring package for Debian-like distributions, volian-archive from Blake Lee (of the "Volian Linux" distribution), who decided to create such keyring package from scratch (based on my input).

User avatar (0022846)
Blzut3 (administrator)
2023-05-17 00:59
edited on: 2023-05-17 01:01

Looks like starting with Ubuntu 22.04 there is a single file way to add a repo, which Ubuntu is going to start using for PPAs:'https://discourse.ubuntu.com/t/improvements-to-ppa-management-in-23-10/35783 [^]'

Apparently the change to support embedded keys in the list file in Apt missed the bus for Debian 11 but should be in the upcoming Debian 12.

Edit: Mixed up Debian code names.


Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2019-02-07 13:40 WubTheCaptain New Issue
2019-02-07 13:44 WubTheCaptain Note Added: 0020339
2019-02-07 13:45 WubTheCaptain Note Edited: 0020339 View Revisions
2019-02-07 15:25 WubTheCaptain Note Added: 0020344
2019-02-07 16:43 WubTheCaptain Note Edited: 0020344 View Revisions
2019-02-07 16:59 WubTheCaptain Note Added: 0020350
2019-02-10 07:39 Blzut3 Note Added: 0020357
2019-02-10 07:39 Blzut3 Assigned To => Blzut3
2019-02-10 07:39 Blzut3 Status new => feedback
2019-02-11 14:26 WubTheCaptain Note Added: 0020361
2019-02-11 14:26 WubTheCaptain Status feedback => assigned
2019-02-11 22:45 WubTheCaptain Note Added: 0020383
2019-02-12 00:05 WubTheCaptain Note Added: 0020384
2019-02-12 13:47 WubTheCaptain Note Added: 0020385
2021-12-13 21:43 WubTheCaptain Note Added: 0021894
2021-12-14 06:08 Blzut3 Note Added: 0021895
2021-12-16 03:16 WubTheCaptain Note Added: 0021901
2021-12-16 03:19 WubTheCaptain Note Added: 0021902
2021-12-16 03:24 WubTheCaptain Note Added: 0021903
2021-12-16 03:25 WubTheCaptain Note Edited: 0021903 View Revisions
2021-12-16 03:43 WubTheCaptain Note Added: 0021904
2021-12-16 04:05 WubTheCaptain Note Edited: 0021901 View Revisions
2021-12-16 04:14 Blzut3 Note Added: 0021905
2021-12-16 04:31 WubTheCaptain Note Added: 0021906
2021-12-16 21:07 WubTheCaptain Note Added: 0021908
2021-12-16 22:18 WubTheCaptain Note Added: 0021910
2021-12-16 22:18 WubTheCaptain Note Edited: 0021910 View Revisions
2021-12-16 22:18 WubTheCaptain Note Edited: 0021910 View Revisions
2021-12-16 22:21 WubTheCaptain Note Edited: 0021910 View Revisions
2021-12-16 22:47 WubTheCaptain Note Added: 0021911
2021-12-16 23:03 WubTheCaptain Note Edited: 0021901 View Revisions
2021-12-17 01:16 WubTheCaptain Note Added: 0021912
2021-12-17 01:21 WubTheCaptain Note Edited: 0021912 View Revisions
2021-12-17 01:35 Blzut3 Note Added: 0021913
2021-12-17 01:40 WubTheCaptain Note Added: 0021914
2021-12-17 01:43 WubTheCaptain Note Edited: 0021914 View Revisions
2021-12-17 04:53 WubTheCaptain Note Added: 0021915
2021-12-17 04:56 WubTheCaptain Note Added: 0021916
2021-12-17 04:59 WubTheCaptain Note Edited: 0021916 View Revisions
2021-12-20 04:28 Blzut3 Note Added: 0021951
2021-12-20 06:25 WubTheCaptain Note Added: 0021952
2021-12-20 06:49 WubTheCaptain Note Added: 0021954
2021-12-20 06:51 WubTheCaptain Note Edited: 0021954 View Revisions
2021-12-20 06:51 WubTheCaptain Note Edited: 0021954 View Revisions
2021-12-20 07:14 WubTheCaptain Note Added: 0021955
2021-12-21 08:49 Blzut3 Note Added: 0021962
2022-01-16 00:44 WubTheCaptain File Added: drdteam-archive-keyring_2012.05.08+0.tar.xz
2022-01-16 00:45 WubTheCaptain Note Added: 0022077
2022-12-19 17:56 WubTheCaptain Note Added: 0022538
2022-12-19 17:58 WubTheCaptain Note Edited: 0022538 View Revisions
2022-12-19 17:58 WubTheCaptain Note Edited: 0022538 View Revisions
2022-12-19 17:59 WubTheCaptain Note Edited: 0022538 View Revisions
2022-12-19 17:59 WubTheCaptain Note Edited: 0022538 View Revisions
2022-12-23 03:08 Blzut3 Note Added: 0022559
2022-12-23 20:30 Blzut3 Note Added: 0022562
2022-12-30 11:35 WubTheCaptain Note Added: 0022570
2022-12-30 11:37 WubTheCaptain Note Added: 0022571
2022-12-30 11:38 WubTheCaptain Note Edited: 0022571 View Revisions
2022-12-30 11:41 WubTheCaptain Note Edited: 0022570 View Revisions
2022-12-30 11:44 WubTheCaptain Note Edited: 0022570 View Revisions
2023-05-17 00:59 Blzut3 Note Added: 0022846
2023-05-17 01:01 Blzut3 Note Edited: 0022846 View Revisions






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker