[Bug 2073126] Re: More nuanced public key algorithm revocation
Julian Andres Klode
2073126 at bugs.launchpad.net
Fri Apr 25 14:02:32 UTC 2025
I first upgraded apt, libapt-pkg6.0t64 to 2.8.3.
Validation for RSA1024 remaining weak:
root at noble:~# gpg --quick-gen-key jak at debian.org rsa1024
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: directory '/root/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/86F909B8AA125825E11A72DE25BB51DD6ADA3043.rev'
public and secret key created and signed.
Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.
pub rsa1024 2025-04-25 [SC] [expires: 2028-04-24]
86F909B8AA125825E11A72DE25BB51DD6ADA3043
uid jak at debian.org
root at noble:~# gpg --export > /etc/apt/trusted.gpg.d/test-key.gpg
root at noble:~# apt download apt
root at noble:~# apt-ftparchive packages . > Packages
root at noble:~# apt-ftparchive release . > Release
root at noble:~# gpg --clearsign < Release > InRelease
root at noble:~# apt update
Get:1 file:/root ./ InRelease [1178 B]
Get:1 file:/root ./ InRelease [1178 B]
Hit:2 http://security.ubuntu.com/ubuntu xenial-security InRelease
Get:3 file:/root ./ Packages [1908 B]
Hit:4 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:5 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:6 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Hit:7 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Hit:8 http://archive.ubuntu.com/ubuntu noble-proposed InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
11 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Download is performed unsandboxed as root as file '/root/./InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
W: file:/root/./InRelease: Signature by key 86F909B8AA125825E11A72DE25BB51DD6ADA3043 uses weak algorithm (rsa1024)
-> Warning is there.
For NIST-P256 becoming "OK" I start with the old version assert the warning is there, and then upgrade and see the warning is gone.
root at noble:~# rm -r .gnupg
root at noble:~# gpg --quick-gen-key jak at debian.org nistp256
[...]
root at noble:~# gpg --clearsign < Release > InRelease
root at noble:~# gpg --export > /etc/apt/trusted.gpg.d/test-key.gpg
root at noble:~# apt update
Get:1 file:/root ./ InRelease [1093 B]
Get:1 file:/root ./ InRelease [1093 B]
Hit:2 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:3 http://security.ubuntu.com/ubuntu xenial-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Hit:5 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:6 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Hit:7 http://archive.ubuntu.com/ubuntu noble-proposed InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Download is performed unsandboxed as root as file '/root/./InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
W: file:/root/./InRelease: Signature by key D93578FC4117B29A26244AF8D0CD6995D6A102A4 uses weak algorithm (nistp256)
root at noble:~# apt install apt/noble
Selected version '2.8.3' (localhost, Ubuntu:24.04/noble-proposed [amd64]) for 'apt'
Selected version '2.8.3' (Ubuntu:24.04/noble-proposed [amd64]) for 'libapt-pkg6.0t64' because of 'apt'
root at noble:~# apt update
Get:1 file:/root ./ InRelease [1093 B]
Get:1 file:/root ./ InRelease [1093 B]
Hit:2 http://security.ubuntu.com/ubuntu xenial-security InRelease
Hit:3 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:5 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Hit:6 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Hit:7 http://archive.ubuntu.com/ubuntu noble-proposed InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
11 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Download is performed unsandboxed as root as file '/root/./InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
** Tags removed: verification-needed verification-needed-noble
** Tags added: verification-done verification-done-noble
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2073126
Title:
More nuanced public key algorithm revocation
Status in apt package in Ubuntu:
Fix Released
Status in apt source package in Noble:
Fix Committed
Status in apt source package in Oracular:
Fix Released
Bug description:
(Please see https://wiki.ubuntu.com/AptUpdates for the versioning)
[Impact]
We have received feedback from users that use NIST-P256 keys for their repositories that are upset about receiving a warning. We also revoked additional ECC curves, which may still be considered trusted, so we should not bump them to errors.
Also existing users may have third-party repositories that use
1024-bit RSA keys and we have not adequately informed them yet
perhaps. We tried to revoke them in the 2.8.0, 2.8.1, and 2.8.2
updates (see bug 2060721). This has been deferred to a later update
than 2.8.3 such that we can solve the warnings and other bugs.
[Solution]
Hence we will restore all elliptic curve keys of 256 or more bit to trusted:
">=rsa1024,ed25519,ed448,nistp256,nistp384,nistp512,brainpoolP256r1,brainpoolP320r1,brainpoolP384r1,brainpoolP512r1,secp256k1";
Note that we still keep rsa1024 as allowed.
At the same time we will also introduce a more nuanced approach to
revocations by introducing a 'next' level that issues a warning if the
key is not allowed in it and a 'future' level that will issue an audit
message with the --audit option.
For the next level, we will set it to:
">=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512"
This means we restrict warnings to Brainpool curves and the secp256k1
key, which we have not received any feedback about them being used
yet.
For the future level, we will take a strong approach to best practices
as it is only seen when explictly running with --audit and the
intention is to highlight best practices. It will be set to
">=rsa3072,ed25519,ed448";
Which corresponds to the NIST recommendations for 2031 (and as little
curves as possible). This level is unused in the 24.04 upload as the
corresponding "audit" log level has not been backported to it.
[Test plan]
Tests are included in the library unit tests for parsing the specification strings; we have also included a test for the gpgv method to ensure that it produces the correct outcome for both 'next' and 'future' revoked keys.
Some smoke tests:
- Observe one a system with a 1024R signed repository that it keeps working and produces a warning (ensures a key listed in "next" but not in "current" warns)
- Sign a repository with a NIST P-256 key and ensure it does not produce warnings (ensures that a key listed in "current" and "next" does not warn)
[Where problems could occur]
There could of course be bugs in the implementation of the new feature; this could result in verification of files failing. This also happens if you specify an invalid `next` or `future` string.
There cannot be any false positives: The new levels are only
*additional* checks, anything not in the `Assert-Pubkey-Algo` list is
still revoked.
The change in behavior of APT::Key::Assert-Pubkey-Algo _may_ cause a
regression if you purposefully override `APT::Key::Assert-Pubkey-Algo`
to *NOT* include algorithms that you actually use; which seems highly
unlikely given that you'd be introducing warnings to your system. If
you don't have a custom value set (or no warnings with your custom
value), you have no regression there.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2073126/+subscriptions
More information about the foundations-bugs
mailing list