On Jo, 24 iun 21, 16:42:34, Marco Möller wrote:
> On 21.06.21 07:58, Andrei POPESCU wrote:
> > On Du, 20 iun 21, 10:20:42, Andrei POPESCU wrote:
> > > Package: release-notes
> > > X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org
> > >
> > > On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> > > >
> > > > Command apt-key and its man page say that apt-key is deprecated, but do not
> > > > suggest an instead recommended tool. It is only mentioned that keys would
> > > > now be organized in /etc/apt/trusted.gpg.d/ . But how should I manage the
> > > > keys saved there, for instance how to update them, or what tool of the
> > > > Debian distribution is managing them there for the apt functionality of the
> > > > Debian OS?
> > >
> > > As far as I understand it's as simple as dropping the keys in there.
> > >
> > > When a key changes/expires/etc. replace it with the new one (if provided
> > > by the respective repository).
> > >
> > > > Guiding me to a properly up-to-date documentation about this topic would be
> > > > welcome!
> > >
> > > Indeed the documentation on this is a bit scarce, probably worth a
> > > mention in the Release Notes.
> >
> > Which already exists, under "Deprecated components for bullseye".
> >
> > Kind regards,
> > Andrei
> >
>
> Andrei, thanks for having picked up my problem and having cared for the
> release notes to comment on it, and also for supposedly having motivated
> Julian Andres Klose to publish a very helpful blog post on the related
> subject. Brad Rogers here in the thread linked to it in his answer to me,
> thanks also for this.
> Darac Marjal in his answer made me understood, that my problem was NOT about
> knowing how to copy a key file to a directory, but about being convinced
> that it is allowed to simply copy files to the /etc/apt/trusted.gpg.d/
> sub-directory without having to manage this by a special tool like gpg. For
> convincing me, maybe the man page of apt-key was simply missing a word like
> "manually" for expressing to "manually place files in this sub-director". As
> a beginner being confronted with security relevant procedures, specially
> when it is about things like PGP keys based on a Web Of Trust concept, you
> easily suspect that a special security tool would exist for ensuring that
> handling the important package signature key infrastructure is done
> correctly. Obviously not. Simply copying a key there appears is really
> enough to get access to a repository.
Well, it makes perfect sense if you remember that "everything is a
file", even if there are exceptions (e.g. network devices).
Documentation for actions requiring specialized tools is rather of the
form "use foo to add an entry to baz", e.g. in the context of GnuPG it
would be "use gpg to add this public key to <keyring>" (which is also a
file, but must be manipulated with specialized tools).
> Here my words, hoping they are describing the situation correctly:
>
> --> " The gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are
> managed by apt after simply having placed manually the files there, each
> file containing a binary formatted key.
To me managing implies that apt is somehow able to add, remove and
possibly refresh them, which is exactly the issue you stumbled upon. In
my opinion a better wording would be:
The keys in the /etc/apt/trusted.gpg.d/ sub-directory are managed by
the system administrator, by copying the corresponding public key of
each repository in the directory as a separate file, either in gpg
binary format or ASCII armored format.
> These keys are automatically trusted
> by apt and hence the "trusted.gpg.d" label for that sub-directory.
Ok, with a minor nitpick: in my opinion it's better to use uppercase APT
when talking about the Advanced Package Tool and lowercase `apt` when
talking about the (not so new anymore) command-line tool.
Can't find a good reference for this at the moment.
> Keys at
> this location are not related to the openPGP key management which as a user
> is usually done with the explicit use of the gpg command. Because of apt
> internally managing these keys and these keys not intended to become
> manipulated manually with the gpg command by the system administrating user,
> the gpg command --refresh-keys cannot be used as a replacement for the
> deprecated "apt-key update" command. " <--
Do you still think this is needed after my rewording above?
> It then might be recommended to also add something like the following to it:
> " Although not needed for technical functionality, it is highly recommended
> to confirm that a key indeed belongs to the package provider before adding
> the binary key containing file to this sub-directory. Further reading on the
> best practice of how to confirm this is provided in .... " here needs to
> come a good link suggestion, which I do not have right now.
Yes, something like this would be a good idea in my opinion. Most
third-party repositories out there just provide some commands to be
executed with root privileges.
The steps are likely to involve using gpg to inspect the key and
signatures on it without actually importing it to the user's keyring.
Which incidentally could also be part of installing that key, if the
last step involves some version of 'gpg --export | sudo tee'.
However, this implies the key is actually published on GPG servers,
which might not always be the case. There is nothing stopping a
repository maintainer to generate a key, place it on some website for
others to download and use "to make APT happy", but never bother to get
signatures for it and publish the signed key on GPG servers.
> I could imagine, that the link could point to Chapter 7.5 "Package signing
> in Debian" of the "Securing Debian Manual" (
> https://www.debian.org/doc/user-manuals#securing ) - after this chapter
> would have been updated to the current situation, apt-key is obviously
> deprecated, and adding maybe there a small advise on how to check a key file
> for its signatures acting as the Web Of Trust.
Feel free to suggest patches for it through bugs against the harden-doc
package, or merge requests in Salsa if the Maintainer is accepting them.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature