Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of Signed-by in debian.sources #158

Closed
ecki opened this issue Aug 10, 2023 · 2 comments
Closed

Use of Signed-by in debian.sources #158

ecki opened this issue Aug 10, 2023 · 2 comments

Comments

@ecki
Copy link

ecki commented Aug 10, 2023

The created /etc/apt/sources.d/debian.sources contain 2 entries for the current distribution, prepared by the debuerreotype scripts. The entry adds a Signed-By clause, which means apt will not use the keys in /etc/apt/trusted-pgp.d/.

I noticed this because I wanted to delete older distribution trusted keys from the directory, but it had no effect. The reason why I want to remove those older keys is to defend against downgrade attacks.

The problem is now, that the file uses /usr/share/keyrings/debian-archive-keyring.gpg aggregate, which contains all of the keys.

I see three ways to fix it:

a) remove Signed-By lines and rely on trusted.d
b) create a per-codename aggregate keyring file /usr/share/keyrings/debian-archive-bookworm.gpg and replace the two Signed-By with it.
c) specify the actual fine grained keys. This requires 3 seperate entries, like so:

Types: deb
URIs: http://deb.debian.org/debian
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/debian-archive-bookworm-stable.gpg

Types: deb
URIs: http://deb.debian.org/debian
Suites: stable-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-bookworm-automatic.gpg

Types: deb
URIs: http://deb.debian.org/debian-security
Suites: stable-security
Components: main
Signed-By: /usr/share/keyrings/debian-archive-bookworm-security-automatic.gpg

Not sure if the semantic of those files is well defined and if bookworm-stable.gpg is the actual key that will be used for the main release’ future minor updates?

@tianon
Copy link
Collaborator

tianon commented Aug 14, 2023

For a), we won't do this because Signed-By is definitely APT maintainers consensus (as seen in the N: Missing Signed-By in the sources.list(5) entry for ... notices you'll get from APT if you remove the Signed-By lines). 🙈

For b), we'd need the support of the debian-archive-keyring maintainers (I'm not comfortable having debuerreotype be the tool responsible for creating those things). 😅

For c), this is complicated because I don't know how well-defined those paths are, especially over time, and I don't think I can reliably commit to maintain the variance if they do happen to change. I think https://salsa.debian.org/apt-team/apt/-/merge_requests/33 is probably also really relevant here (both David and Julian there are APT maintainers). 👀

In the short term, I think the best solution to your specific problem is going to be creating your own debian.sources replacement that maps these in the way you suggest (since you're targeting a specific stable release as opposed to all suites including unstable, it's likely going to be easier for you to maintain in this specific case than in the general case).

@ecki
Copy link
Author

ecki commented Aug 14, 2023

For a), we won't do this because Signed-By is definitely APT maintainers consensus

That consensus needs to be documented in apt-secure man page.

(as seen in the N: Missing Signed-By in the sources.list(5) entry for ... notices you'll get from APT if you remove the Signed-By lines). 🙈

Imho that notice does not make much sense, as can be seen here a signed-by line can be as unspecific as the trusted-pgp.d directory (in fact the config dir would be easier to prune). But agreed, the APT team needs to sort that out.

For b), we'd need the support of the debian-archive-keyring maintainers (I'm not comfortable having debuerreotype be the tool responsible for creating those things). 😅

yes that would certainly be the best option.

@ecki ecki closed this as completed Aug 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants