[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1065982: marked as done (Would it not be possible to fix deprecated apt-key calls with a script?)

Your message dated Mon, 11 Mar 2024 13:57:00 +0100
with message-id <5sbxrddoen467e4a2oojvddxkaemhsfp2ocv5g63l2qpswcvsc@fogls3o7x3lc>
and subject line Re: Would it not be possible to fix deprecated apt-key calls with a script?
has caused the Debian Bug report #1065982,
regarding Would it not be possible to fix deprecated apt-key calls with a script?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1065982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065982
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- Package: apt, (apt 2.4.11 (amd64) on a system using Xubuntu 22.04.3 LTS)


Would it be possible to fix deprecated apt-key calls with a script?

  1. download a package,
  2. download its associated key,
  3. open a browser to show me from where the key is downloaded, in order to find the fingerprint of the key,
  4. extract the fingerprint from the downloaded key, such that I check the published fingerprint against it and decide, if it is ok. If not: exit.
  5. generate a name with ending *.gpg for the key under which it shall be stored, which reflects the package for which it is valid,
  6. use the file command and grep for "Public Key (old)" and decide whether the provided key has to be --dearmored or not when it is stored in /etc/apt/keyrings (the directory which was advised when I read the article),
  7. creates a proper file with a name ending in .list to /etc/apt/sources.list.d. The file name should be similar to the corresponding *.gpg file. The script should write the proper content to this file. If I got it right, the line deb [signed-by=<.gpg file in /etc/apt/keyrings>] https://<URL from where package has been downloaded> stable main plays the key role in the solution.
  8. Delete the old insecure key which was added by apt-key.

Or would this be insufficient? Keys in the key ring /etc/apt/trusted.gpg show an uid [ unknown ]. Does this prevent establishing the right realtion between keys and packages?


--- End Message ---
--- Begin Message --- 
On Sun, Mar 10, 2024 at 10:58:34PM +0100, Adalbert Hanßen wrote:
> Would it be possible to fix deprecated apt-key calls with a script?
> 
> 1. download a package,
> 2. download its associated key,

A package has no associated key. I suppose you mean a repository (that
contains one or more packages). How that works is detailed to some
extend in apt-secure(8) if you are interested.


> 3. open a browser to show me from where the key is downloaded, in order
>    to find the fingerprint of the key,

Well, you can (hopefully) download the key from the same place you can
access the repository from. Given we talk about old repositories using
old instructions those are usually available only via http, which is
a no-go.

Depending on your amount of paranoia even an http to https redirect
doesn't help as that initial redirect is not verifiable and even if we
are opportunistically redirect to https without asking for http first,
who said that the https-server we reach is actually controlled by the
same person as the http-server was?


> 4. extract the fingerprint from the downloaded key, such that I check
>    the published fingerprint against it and decide, if it is ok. If
>    not: exit.

apt can't "extract". It just doesn't have the code. Doing this would
require us to depend and use gpg, which is exactly what we don't want.
A key is just a blob of binary/text, a fingerprint or whatever "just"
an implementation detail we don't concern ourselves with.


> 8. Delete the old insecure key which was added by|apt-key|.

Nobody said the old key is insecure. Perhaps it is, maybe not. Heck,
nobody said it is an old key. Storing key(s) in /etc/apt/trusted.gpg
is "just" considered bad style regardless of how strong or weak that key
may be. It just happens to be that the keys which are in there are
usually not up to any semi-recent security standard as its quiet some
years since we tell people not to store keys in there…



Anyway, what you are trying to describe is somewhat of a possibility for
some cases. In other cases it wont work. In many cases it will be much
better if the user takes the opportunity to reevaluate if the repository
is actually still needed as that is what mostly happened for those keys:
People added and later removed repositories, but never removed the keys,
which linger endlessly trusted, but unused until perhaps many years later
an attacker can make use of that key to attack you.


If adding repositories more easily is your concern, you may look into
manager like extrepo or look for repositories which tell you to use
a sources file in deb822 format – which can have the key embedded
(neatly resolving your 7. point the other way around).



> Keys in the key ring /etc/apt/trusted.gpg
> show an uid [ unknown ]. Does this prevent establishing the right
> realtion between keys and packages?

No. This is connected to the trust levels in gnupg which APT isn't
using as you neither can "partially" trust a repository to not ship
packages from an evil entity nor can three partially trusted
repositories speak up for a fourth unknown key to not be from an
imposter. See "web of trust" for details.



Anyway, this more like a question than an actually bug report and as
such not actionable… and so better of being closed. Questions and ideas
are better of discussed on e.g. IRC or mailinglists – only if its clear
that we can [and should] do something in apt [compared to somewhere else
entirely as apt is pretty low level] we can move to bug reports.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: