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].
Attachment:
signature.asc
Description: PGP signature