Packages are signed with RSA 1024 which is considered insecure #1429
Comments
|
Yes, that's all true, but this is something controlled by Launchpad, see these bugs:
There's nothing I can do unless I move all the PPAs into a new Launchpad "team" which would disturb a lot of installations. |
|
Does the possible disruption really outweigh the NIST has disallowed this for nearly a decade now. https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/announcements/2013-announcements Would it not be a (albeit convoluted, thanks Canonical) solution(at least for this repo) to maintain two teams and instruct users who happen to bump into the old one to use the new one, and kill the old one after a few months? |
|
Maybe, I'll think about it. I'll also poke the Canonical to fix this. |
|
So, the question is whether it would be ok to make the repository change automatically by running appropriate commands from the maintainer scripts? |
|
Looks like I picked a great time to poke into this, as 2 days ago a Canonical employee said your keys will be rotated, as they literally won't work on new Ubuntu anymore. |
|
Finally! That's great news, thanks for sharing that. |
|
Very evident now in 24.04 this message is displayed always: Also: https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854 |
|
🤷 There is still nothing I can do on my side… |
From the link you posted… I guess the security wasn’t priority for Canonical… |
|
There is now a way to fix this since Launchpad now has 2 keys. Please view the latest answer on the following link for the solution: https://answers.launchpad.net/launchpad/+question/812470 To resume the situation, they are adding a second 4096-bit RSA signing key to every PPA repository but it will most likely take some time. The second key has been added to the Ondrej PHP repository but not the nginx-mainline one. "it is possible for the PPA owner to mark the whole PPA or at least the 'noble' suite dirty for the PPA to get republished and dual-signed" |
|
The Ondrej PHP PPA is already double-signed! Here you can see it: That means that now, you have the option to manually replace the old signature with the new one if you want to fix this issue. |
The Ondrej PHP PPA is indeed already double-signed, however, the nginx-mainline one still isn't and it might take time. But there's a way to force it: "it is possible for the PPA owner to mark the whole PPA or at least the 'noble' suite dirty for the PPA to get republished and dual-signed" |
|
There’s no such option for the PPA as far as I can see. I can probably do something very artificial and make a dummy upload of something to every repository. |
|
Because it's impossible to see the double signing or the new key in the UI, here it is, thanks @QROkes! New: |
|
Just wanted to let you know that the second key has also been added to the nginx-mainline. So now both of your PPAs have the second 4096 bits key :) |
|
Please, ELI5. I understand it has been signed with both keys, and I see the new key has been quoted above. But I don't understand what I'm supposed to do with it? Is there a command for us to switch the old key for the new one. Or a command to remove and add the repository with the new key? I'm using Ubuntu 24.04 LTS and the PPA for Apache2. My signed-by parameter, has multiple lines containing a "PGP PUBLIC KEY BLOCK" I tried changing that to: (which is part of the debsuryorg-archive-keyring deb package) But then I get an error instead of a warning: I really don't know what I'm supposed to do with this. I perceive from what's posted so far, that others have a complete fix? |
|
Grab the key - gpgKey='B8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6'
gpgKeyPath='/etc/apt/keyrings/ondrej-ubuntu-php.asc' # or `.gpg` for binary keys instead of ASCII
gpgURL="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x${gpgKey}"
wget -O ${gpgKeyPath} "${gpgURL}"Create .sources file: # /etc/apt/sources.list.d/ondrej-ubuntu-php.sources
X-Repolib-Name: Ondrej PHP
Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/ondrej-ubuntu-php.ascAnd finally Removing whatever you used to have, replace values as needed. |
|
@C0rn3j 's fix didn't quite work for me without some extra steps. If storing in a file the gpg key needs to be stored in a binary format. This works for me... Edit And finally |
No, the extension needs to match the contents.
|
|
You are of course correct. I just wanted to help others in my response. No criticism from me :-) |
|
@C0rn3j Maybe you can correct comment #1429 (comment) to use the correct extension? |
Ahhh, I didn't get it at first. I copied that from a script and didn't notice it was doing a dearmor later. |
|
You shouldn't use |
|
I think Canonical should have provided a way to graceful upgrade the PPA, but alas we are here now. My guess is that removing the repository and then adding it again with |
|
I did add it with add-apt-repository yesterday morning and I did run into this very issue, so it appears not, does not seem to be the "one shot" solution. However, manually adjusting after works:
then |
|
And was that a clean updated system? |
|
Indeed yes (apart from the fact that I used the inverse command). Fresh mint ubuntu noble pulled and updated just the moment before I did the Then I saw at some point it complained the key is weak, which I ignored at first, and now came here since I was actually researching "what happens when orednj is no more" 😦 and came across this one... I have to run the whole thing again anyway so I will feedback here if it happens again. God knows I did "something wrong" somewhere. |
Tested with Docker and latest official image |
That looks sane to me. |
|
That is the weak signature - which I understand to the discussed issue here? |
Right. I'm on mobile device and it's Sunday morning ;). You should probably bug Canonical to fix this. I can't do anything about this except creating new repository and deleting this one which would break so many installations. |
|
According to this link: APT will start enforcing Signed-By for all sources, and trusted.gpg.d becomes obsolete. So my fix was simply to fetch the new key using curl: And then edit the ".sources" file removing the old key for the new key, inside the signed-by section. NOTE that the spacing is important. The block section is prefixed with a space. Especially the space on the line that goes between the headers of the key and the blob. This is because an empty line is how you separate various apt sources inside a single sources file. And it would cut the key block in half. |
|
Got here after receiving the same warning for this and the git PPA; their description pointed me to https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2065932, which seems to suggest fresh installs currently don't work because, even though all packages are now properly dual signed, This once again means there's nothing that really can be done by PPA owners (except for listing the issue and pinning manual workarounds) and we have to wait for upstream fixes by Canonical. |
|
For me removing and then re-adding the repository worked to get rid of the weak rsa1024 signature warning: sudo add-apt-repository --remove ppa:ondrej/php
sudo add-apt-repository ppa:ondrej/php
sudo apt updateLooking at the comments above, some people had different experiences, so your mileage may vary 😉 |
Running
add-apt-repository ppa:ondrej/phpcurrently imports an 1024 bit RSA key into the apt keyring:This is especially problematic because the ppa is added with an http mirror (without https, which has much higher standards for cryptographic primitives than gpg does), but also because this key is valid for all apt repositories on the system until explicitly removed.
According to the NIST document linked below, RSA 1024 is considered to have a security strength of <= 80 bits (5.6.1.1, page 67), they also state (5.6.1, page 65):
Debian itself prefers 4096 bits for RSA keys, or 2048 bits if constrained by smart card limitations. Please consider updating the key accordingly.
Thanks!
[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
[2]: https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf
[3]: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile
[4]: https://www.ietf.org/rfc/rfc3766.txt
The text was updated successfully, but these errors were encountered: