Packages are signed with RSA 1024 which is considered insecure

[kpcyrd]

Running add-apt-repository ppa:ondrej/php currently imports an 1024 bit RSA key into the apt keyring:

# apt-key list
/etc/apt/trusted.gpg.d/ondrej_ubuntu_php.gpg
--------------------------------------------
pub   rsa1024 2009-01-26 [SC]
      14AA 40EC 0831 7567 56D7  F66C 4F4E A0AA E526 7A6C
uid           [ unknown] Launchpad PPA for Ondřej Surý

/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg
------------------------------------------------------
pub   rsa4096 2012-05-11 [SC]
      790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2012) <ftpmaster@ubuntu.com>

/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
------------------------------------------------------
pub   rsa4096 2012-05-11 [SC]
      8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid           [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>

/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
------------------------------------------------------
pub   rsa4096 2018-09-17 [SC]
      F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>

# 

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):

Note that a security strength of 80 bits is no longer considered adequate.

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

[oerdnj]

Yes, that's all true, but this is something controlled by Launchpad, see these bugs:

• https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
• https://bugs.launchpad.net/launchpad/+bug/1331914

There's nothing I can do unless I move all the PPAs into a new Launchpad "team" which would disturb a lot of installations.

[C0rn3j]

Does the possible disruption really outweigh the massive security risk this is currently causing?

NIST has disallowed this for nearly a decade now.

https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/announcements/2013-announcements …modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013…

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?

[oerdnj]

Maybe, I'll think about it. I'll also poke the Canonical to fix this.

[oerdnj]

So, the question is whether it would be ok to make the repository change automatically by running appropriate commands from the maintainer scripts?

[C0rn3j]

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.

https://bugs.launchpad.net/launchpad/+bug/2053281

[oerdnj]

Finally! That's great news, thanks for sharing that.

[QROkes]

Very evident now in 24.04 this message is displayed always:

W: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/InRelease: Signature by key 14AA40EC0831756756D7F66C4F4EA0AAE5267A6C uses weak algorithm (rsa1024)

Also: https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854

[oerdnj]

🤷 There is still nothing I can do on my side…

[oerdnj]

PPAs are currently in the process of being upgraded to a 4096-bit RSA key and we expect that upgrade to be complete by release time. No action is needed (or possible) from PPA owners.

From the link you posted…

I guess the security wasn’t priority for Canonical…

[CryptoSiD]

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"

[QROkes]

The Ondrej PHP PPA is already double-signed!

Here you can see it: curl 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/InRelease' | gpg

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.

[CryptoSiD]

The Ondrej PHP PPA is already double-signed!

Here you can see it: curl 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/InRelease' | gpg

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"

[oerdnj]

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.

[C0rn3j]

Because it's impossible to see the double signing or the new key in the UI, here it is, thanks @QROkes!

New: B8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6 Old: 14AA40EC0831756756D7F66C4F4EA0AAE5267A6C

[CryptoSiD]

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 :)

[josestefan]

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: Signed-By: /usr/share/keyrings/deb.sury.org-apache2.gpg

(which is part of the debsuryorg-archive-keyring deb package)

But then I get an error instead of a warning:

  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4F4EA0AAE5267A6C

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?

[C0rn3j]

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.asc

And finally apt update && apt upgrade -y.

Removing whatever you used to have, replace values as needed.

[dogsbody]

@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...

gpgKey='B8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6'
gpgKeyPath='/etc/apt/keyrings/ondrej-ubuntu-php.gpg'
gpgURL="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x${gpgKey}"
sudo curl "${gpgURL}" | gpg --dearmor | sudo tee ${gpgKeyPath} >/dev/null
gpg --dry-run --quiet --import --import-options import-show ${gpgKeyPath}
# The output should contain the full fingerprint B8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6

Edit /etc/apt/sources.list.d/ondrej-ubuntu-php.sources to read...

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/ondrej-ubuntu-php.gpg

And finally sudo apt update

[C0rn3j]

If storing in a file the gpg key needs to be stored in a binary format.

No, the extension needs to match the contents.

asc for ASCII, gpg for gpg binary

[dogsbody]

You are of course correct. I just wanted to help others in my response. No criticism from me :-)

[c-schmitz]

@C0rn3j Maybe you can correct comment https://github.com/oerdnj/deb.sury.org/issues/1429#issuecomment-2171688822 to use the correct extension?

[C0rn3j]

@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.
Fixed.

[smileBeda]

You shouldn't use /etc/apt/keyrings/ on ubuntu noble. You should use /usr/share/keyrings/

[oerdnj]

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 add-apt-repository should work.

[smileBeda]

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:

• curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xB8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6" | gpg --dearmor | sudo tee /usr/share/keyrings/ondrej-ubuntu-php.gpg >/dev/null
• nano /etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources
• change signed by: to be Signed-By: /usr/share/keyrings/ondrej-ubuntu-php.gpg

then apt update. No more warnings, plus this follows the latest deprecation of /etc/apt/keyrings/ in favor of /usr/share/keyrings/ No big deal, but of course an extra hoop.

[oerdnj]

And was that a clean updated system?

[smileBeda]

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 apt-add-repository ppa:ondrej/php -y:

apt update; apt upgrade -y;
...
apt-add-repository ppa:ondrej/php -y

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.

[todeveni]

And was that a clean updated system?

Tested with Docker and latest official image

$ docker run -it ubuntu:24.04 /bin/bash
# apt update && apt upgrade -y
[...]
# apt install -y software-properties-common
[...]
# apt-add-repository -y ppa:ondrej/php
[...]
W: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/InRelease: Signature by key 14AA40EC0831756756D7F66C4F4EA0AAE5267A6C uses weak algorithm (rsa1024)
# cat /etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources
Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/
Suites: noble
Components: main
Signed-By:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 .
 mI0ESX35nAEEALKDCUDVXvmW9n+T/+3G1DnTpoWh9/1xNaz/RrUH6fQKhHr568F8
 hfnZP/2CGYVYkW9hxP9LVW9IDvzcmnhgIwK+ddeaPZqh3T/FM4OTA7Q78HSvR81m
 Jpf2iMLm/Zvh89ZsmP2sIgZuARiaHo8lxoTSLtmKXsM3FsJVlusyewHfABEBAAG0
 H0xhdW5jaHBhZCBQUEEgZm9yIE9uZMWZZWogU3Vyw72ItgQTAQIAIAUCSX35nAIb
 AwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEE9OoKrlJnpsQjYD/jW1NlIFAlT6
 EvF2xfVbkhERii9MapjaUsSso4XLCEmZdEGX54GQ01svXnrivwnd/kmhKvyxCqiN
 LDY/dOaK8MK//bDI6mqdKmG8XbP2vsdsxhifNC+GH/OwaDPvn1TyYB653kwyruCG
 FjEnCreZTcRUu2oBQyolORDl+BmF4DjLiQEzBBABCgAdFiEECvaBvTqO/UqmWMI/
 thEcm0xImQEFAmXTV0AACgkQthEcm0xImQGTTggAhuMHGeBZlRUAsZE7jJM7Mf06
 /WIhcgUfBfSFnJFlFH+xdEe/GFYyVk9kingDsPh90Ecnt4n8DJHTlsuUV1+SPBIO
 JfbQTUjx1n/+Ck+TVKzRByvrpRXtiZQ214m3zbhZpme2eBBMItZByjG7g925NUIq
 rL+R5ZoEcZvVlYscfsA0Sr8yJTsGJPefuLYI6eJkNDa1QkzBkSSW4XaCfNIxNBRs
 zN/qGe3xy0bibOaC4T2TcbZPSAVP855ahNbLAdqkyfAutiEWcKZmQpR9qNh4482k
 0pXVlQJ8UB860gVFHjwjFm/MsCeX8yfeAi38ZyInWL2OSG2pDx5ZzNESwnCPIg==
 =N1rh
 -----END PGP PUBLIC KEY BLOCK-----

[oerdnj]

Tested with Docker and latest official image

That looks sane to me.

[smileBeda]

That is the weak signature - which I understand to the discussed issue here?

[oerdnj]

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.

[josestefan]

According to this link: https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333

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: curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xB8DC7E53946656EFBCE4C1DD71DAEAAB4AD4CAB6"

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.

[jnoordsij]

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, add-apt-repository seems to choose the old weak key by default.

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.