0

Most third-party repositories configured in /etc/apt/sources.list.d have a signing key configured like this for example: deb [signed-by=/etc/apt/keyrings/lutris.gpg] https://.

However, some like the one for postgresql do not have this configured. Is that a problem? If that can be a problem but isn't necessarily one how to check if it is? In specific, the postgresql repo has a repository signing key but why doesn't it need to be specified there?

In addition, when running these steps at that Linux download page for the database when running

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - it already says Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

and when running sudo apt-get update the output includes:

W: https://apt.postgresql.org/pub/repos/apt/dists/bookworm-pgdg/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details. N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://apt.postgresql.org/pub/repos/apt bookworm-pgdg InRelease' doesn't support architecture 'i386'

  • The latter problem can be solved by editing the file kwrite /etc/apt/sources.list.d/pgdg.list to make it say deb [arch=amd64] https:... but that shouldn't be required (the setup should work as is).
  • That only leaves the legacy trusted.gpg keyring problem which can be solved with the long for ... command from here (which certainly shouldn't be required! it should auto-import the keys by default or after prompting the user and at the least the guide on the download page should not be outdated).
  • Having done all this, the question left is whether it isn't a problem that the signing key isn't specified in the pgdg.list file. Also the download page needs to get updated.
Improve this question

1 Answer 1

Reset to default
1

There are four points to consider.

  1. Regarding signed-by (documented in man 5 sources.list, its purpose is to ensure that packages shipped by a given repository are signed by a key in a specific keyring, or even a specific key. Repositories without such an entry won’t trigger an error if they are compromised and start shipping packages signed by another key in your APT keyring.

    I don’t think this makes a significant difference from a security perspective. If a repository signing key is compromised, in all likelihood the repository it was intended to sign could be used to ship compromised packages; adding the ability for a compromised key to sign packages in another repository doesn’t significantly increase the attack surface in my opinion. The main exception to that is for keys added to the APT keyring and forgotten about; but the answer to that is to stop using the APT keyring.

    To me the main utility of signed-by is as documentation: it documents which keys are used where. This should help administrators remove keys when they remove the associated repository.

    The main weakness of APT repositories is that they share the same namespace. Thus a compromised APT repository could ship a compromised libc6 package with a newer version than that in Debian, and systems using that APT repository would upgrade to that package. The best defence against that, for system administrators, is to limit the use of third-parties and third-party keys. Improving the situation for everyone would require quite a lot of work on the Debian side of things (even a “simple” solution such as remembering where a package came from, and warning if it changes repository, quickly runs into usability problems since Debian itself relies on at least two different repositories, and potentially up to four for any given release, and there isn’t currently a way to prevent a third-party repository from pretending to be Debian, other than the keys used). See also How is the authenticity of Debian packages guaranteed?

  2. Regarding the deprecation of apt-key, the “DEPRECATION” section of man 8 apt-key explains exactly how to transform the wget command-line to work without relying on apt-key.

  3. Regarding the i386 notice (which is perfectly benign), yes, ideally the PostgreSQL repository instructions should be updated (along with the changes described in the points above).

  4. The above aren’t specific to PostgreSQL; but specifically regarding PostgreSQL, why are you using the third-party repository? Debian 12 includes PostgreSQL 15.6, which is the same as the latest version available from the upstream PostgreSQL repository. (Are you required to use an older version?)

Improve this answer
4
  • 1. Wouldn't that mean that if one signing key in the keyring is compromised, all repositories without signed-by set could ship problematic packages? If it is set, there is the protection that if the repo is compromised nothing bad happens unless they specific key is compromised as well. 1.2 a warning if it changes repository seems very useful and needed; I don't see how that would cause big usability problems that can't be readily mitigated; is there an apt issue for that? 2. That isn't for the user looking to convert the existing keys 4. I think an earlier Deb only had outdated versions Commented Apr 9, 2024 at 18:46
  • 1. Yes, but if one signing key is compromised, the attacker can probably modify packages shipped in the corresponding repository — that’s much more likely than compromising a key and using that to replace packages in an unrelated repository. signed-by avoids the latter scenario, but doesn’t do anything for the former. 1.2. Consider what you’re trying to do: you had udev installed from the main Debian repository, and you wanted to replace it with the version from the backports repository. A warning in that scenario might not be too much of a problem, since the installation request … Commented Apr 9, 2024 at 23:22
  • … includes a repository specifier; but installing security updates also involves changing repositories, and a warning would be unwanted there (imagine most users’ reaction to a supposedly security-related upgrade triggering a warning from the package management system). 2. It avoids having to convert the keyring in the first place. 4. Re-evaluating the usefulness of third-party repositories should be part of any upgrade from one Debian release to the next. I understand that the PostgreSQL repository was useful to you in the past, but removing it now that it no longer is would simplify this. Commented Apr 9, 2024 at 23:27
  • 1. Yes, it's more likely but compromising packages in other unrelated repositories without signed-by set could be more useful..for example because they contain running packages used by some servers; the issue is that they could compromise packages of the repo and packages of other repos where the keys could not get compromised; so I think one should always limit the amount of intrusion/damage that can be done when one signing key is compromised especially because that may be all that attackers could originally compromise 1.2 readily mitigable by excluding backports; a warning could be useful Commented Apr 10, 2024 at 10:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.