On Thu, Feb 06, 2020 at 08:00:26PM +0100, Johannes Schauer wrote: > Quoting David Kalnischkies (2020-02-06 16:43:22) > > On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote: > > > "I have a keyring I know that I want to use (like > > > /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material > > > from > > > that keyring fully included in the keys trusted by apt?" > > > > That is a question though you should ideally ask apt instead of trying > > to peak inside its trusted keyrings and figure it out by yourself. > > Who knows what might change in the keyring setup in the future. [0] > > > > So if you can outline an interface I guess we can add it to apt-key to > > decouple mmdebstrap from this > > I thought using apt-key was discouraged?
Yes and no. Most public uses currently are uses which we do not want to continue like "add" or "del" which require gnupg to be installed (which isn't guaranteed by apt) and "just" do something you can do by placing a file in a directory¹. Or things like abusing "adv" to receive or refresh keys from keyservers unchecked… It has many undocumented² uses though as it acts as our stateless gpg(v) command-line interface. There are also sensible questions a user might have like "list" and those aren't far away from your question. So yes, nearly everything apt-key does at the moment (in the public eye) will be gone at some point, but we will always need some tool which can be used to query the trusted set (as long as we have such a set). After all, I can reasonable define that /etc/apt/trusted.gpg.d/ will be supported in the following years to places files in as gpg/asc, but saying that this is the ONLY place and the ONLY file types you will ever encounter therein is a much larger interface I am not comfortable with. (As that prevents /usr/lib/apt/trusted.gpg.d/ as well as keybox support as we would need to coordinate such features with everyone then – both not planned ATM, but ruling out that we could have them (or others) at some point is painting us too much into a corner I think). ¹ We could provide wrapping commands for that, but a) the obvious names are already taken b) it will be ignored for at least two Debian releases as repo admins want something which works on every release – so I opted for the "compatibility" solutions as the only solution. Stuff like !33 and Signed-By change this anyhow hopefully obsoleting the global trust store in the long run… Oh and c) no maintainer script needed in a keyring package which is always a good thing. ² Providing a stable API on top of gpg is hard if not impossible, so we keep that to ourselves. Sometimes it feels different to me, but apt just wants to be a package manager, not a general propose gpg wrapper… > > (I didn't mention your bootstrap specifically as I thought you were one of > > the lucky ones by delegate all these problems to apt). > > Far from it. Today you already discovered how bloated mmdebstrap is. One > reason (For the avoidance of doubt by casual onlookers: That "discovery" was a joke on IRC based on another joke – not based on real facts.) > is, that lots of stuff that could be in dpkg/apt actually is not. Dpkg > recently Lets start with this one then as even something as simple as listing all fingerprints in all keyrings apt trusts has hidden gotchas with gpg (e.g. gpg used to hardcode [= haven't recheck recently] a limit of 40 --keyring parameters and some apt users have A LOT of PPAs … #733028). apt-key has code for that and many other things already, you probably don't [or mmdebstrap is indeed very bloated and we should think about adding dist-upgrade to it to replace apt instead ;)]. [And that is there this thread comes in: apt-key is more than 800 lines of shell madness to work around various things. And there are at least a thousand more lines in C++ – and the main think we are doing is checking if a file is correctly signed… how many lines should that really need…] Anyway, please open a (token) bugreport for this and mention if you want a "apt-key is-trusted" command and/or want me to give you a "apt-key adv" rune you can use with older apt versions. There are probably corner cases to consider (and optimizations like --readonly to be used), but something like the following could mostly work already. diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in @@ -781,6 +781,16 @@ case "$command" in warn_on_script_usage foreach_keyring_do 'list_keys_in_keyring' --fingerprint "$@" ;; + is-trusted) + merge_all_trusted_keyrings_into_pubring + if [ "$#" = '0' -o "$(aptkey_execute "$GPG_SH" --keyring "${GPGHOMEDIR}/pubring.gpg" --with-colons --list-keys "$@" 2>/dev/null | grep -c '^pub:')" != "$#" ]; then + exit 1 + fi + ;; + list-fingerprints) + setup_merged_keyring + aptkey_execute "$GPG" --with-colons --list-keys 2>/dev/null | grep '^fpr:' | cut -d':' -f 10 + ;; export|exportall) warn_on_script_usage merge_all_trusted_keyrings_into_pubring (I guess list-fingerprints would actually be enough, but I think I could use both in the testcases – BUT I shouldn't think about/work on security related things that close to bed, so lets keep it at that for now and continue outside of this thread) Best regards David Kalnischkies P.S.: Likely my last message for this week [carnival sessions to run].
signature.asc
Description: PGP signature