repo.steampowered.com "Policy will reject signature within a year"

steamclosed Distro Family: DebianValve-provided steam package

ValveSoftware/steam-for-linux#12050 · opened 2025-05-26 by lgrn · updated 2025-10-04 · 9 comments · github

Llgrn 2025-05-26 github

Your system information

Steam client version (build number or date): steam-launcher 1:1.0.0.82 amd64
Distribution (e.g. Ubuntu): Debian
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: N/A
GPU: N/A

Please describe your issue in as much detail as possible:

cat /etc/apt/sources.list.d/steam.sources

Types: deb
URIs: http://repo.steampowered.com/steam/
Suites: stable
Components: steam
Signed-By: /usr/share/keyrings/steam.gpg

sudo apt update

(...)
Warning: http://repo.steampowered.com/steam/dists/stable/InRelease: Policy will reject signature within a year, see --audit for details

sudo apt update --audit

(...)
Audit: http://repo.steampowered.com/steam/dists/stable/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
   Signing key on BA1816EF8E75005FCF5E27A1F24AEA9FB05498B7 is not bound:
              No binding signature at time 2025-04-24T10:32:13Z
     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

This warning will appear for any user of Debian Trixie and likely also later versions of Ubuntu, and the repo will probably stop working for these users in about 10 months.

Steps for reproducing this issue:

As above.

Ssmcv 2025-06-02 github

This seems like apt/sqv being unnecessarily pedantic about the signing key that is currently used. Its complaint is that the self-signature on the key's uid uses SHA1 (which is now considered weak) to sign statements like "the holder of this key claims to be Valve Corporation" (which is part of the "web of trust" model).

However, the reason for apt to trust this key is that it appears in /usr/share/keyrings/steam.gpg, and the /etc/apt/sources.list.d/ snippet has told apt to validate against any signing key found in that file. The SHA1-based signature and the web-of-trust model aren't really load-bearing for this particular use of PGP keys.

We should address this at some point in the next few months by either renewing the self-signature with SHA256, or starting to sign with a new key and moving away from the current one (or, ideally, both).

Llgrn 2025-06-02 github

Disclaimer: I don't work in security and my understanding of APT repository signing is quite basic.

My understanding is that SHA-1 is vulnerable to collisions, so if someone managed to generate a key with the same SHA-1 hash as the Valve key, they could then impersonate the Valve signature and make it appear that the package index is indeed signed by the key the user already has on disk.

To actually exploit this, I assume some social engineering and imagination would be required to get end-users attracted to for some reason adding the new malicious repo, but if you manage this, the packages would appear to the user to be cryptographically verified to have been signed by the same key as the one used in the official Valve repo.

Regardless, it's nice to see that you're looking into fixing this, even disregarding the technical stuff I think it's probably worth it for all the confusion it will create as users migrate to newer versions of Debian and Ubuntu.

Ssmcv 2025-06-02 github

My understanding is that SHA-1 is vulnerable to collisions

Yes, that's why it's being phased out as a general industry-wide thing. There are various subtleties regarding the exact things that have known or suspected attacks, so the collisions might or might not actually be viable as an attack on secure apt - because the thing that gets signed in secure apt has syntax and internal structure, requiring an attacker to find a collision that is still syntactically valid, which is a harder problem than finding any collision at all - but the safe approach is to stop using it as part of a security boundary. (And rotating the key will certainly be easier than doing the reasoning to figure out whether it's really necessary!)

so if someone managed to generate a key with the same SHA-1 hash as the Valve key, they could then impersonate the Valve signature

In this particular case, no, I don't think so. The signature that is load-bearing for secure apt is the one made by the apt repository maintenance software (dists/stable/Release.gpg is a signature over dists/stable/Release, and dists/stable/InRelease is a combination of both the signature and the signed content), and that's generated with a modern version of GnuPG, using digest algo 10 (that's SHA-512). gpg --list-packets Release.gpg shows the technical details. If apt was willing to trust a SHA-1 signature here, then yes, a SHA-1 collision could let a sufficiently well-funded attacker impersonate Valve's apt repo; but apt already rejects SHA-1 signatures in this context since 1.4~beta1 (2016), so we're safe.

When apt validates that signature, it iterates through steam.gpg (because we tell it to use steam.gpg via the signed-by option, see also #12045), and for each public key listed in that file, it asks: does InRelease or the pair {Release,Release.gpg} have a valid signature from this public key? and if yes, it accepts the content of that Release file as authentic. It doesn't actually matter for the purposes of this trust decision whether there is a suitable self-signature on the key itself: the root of trust is whether the public key is present in steam.gpg or not. If it isn't present, then apt wouldn't be able to verify the signature anyway, and if it is present, then it's considered to be trusted.

If an attacker wanted to impersonate Valve and send you malicious software, finding a SHA-1 collision wouldn't be enough: they would also have to get their colliding key into steam.gpg on your computer (either via getting it into the .deb package, or by compromising your computer some other way). But, if the attacker is able to do that, then they could do whatever bad things they want to do more directly, without needing a SHA-1 collision.

The places where this key is still using SHA-1 are within the public key itself (digest algo 2 in gpg --list-packets steam.gpg), to:

bind the user ID to the certification/signing key: as described above I don't think this is significant for secure apt, because the trust root for secure apt is whether the public key is present in steam.gpg or not
bind the encryption subkey to the certification/signing key: this would be security-sensitive if you were using that encryption subkey to send encrypted email to Valve (or something), but secure apt is all about signing rather than encryption, so the encryption subkey isn't used in secure apt

Kkillerkalamari 2025-08-10 github

Is there an asc file I can download manually? Debian 13 (Trixie) is now the stable version, and this warning shows up by default on an apt update.

EDIT: Realized I was a bit uninformed on this topic. An asc file just means it is ASCII-armored, that's it. I was able to generate an asc file with gpg --keyring /usr/share/keyrings/steam.gpg --no-default-keyring --homedir /dev/null --export -a >steam.asc but it didn't do me any good, of course. It was still the same SHA1 signature, just in a different format.

Microsoft recently fixed this for their repos, and the old signature file still worked (with the warning) along with the new one, so that tells me there's some way to add the new signing key alongside the old one, which is nice for not breaking things during the transition.

Ssmcv 2025-08-11 github

Third parties cannot fix this or work around it, only the holder of the corresponding private key (Valve) can do that.

As I mentioned above, this is a known issue and being looked at:

We should address this at some point in the next few months by either renewing the self-signature with SHA256, or starting to sign with a new key and moving away from the current one (or, ideally, both).

But that procedure needs to be done carefully (to avoid broken upgrades). The deadline for this is that apt might start rejecting these signatures next February, so a key with a renewed self-signature needs to be in place by then. Until that time, it's only a warning.

If I'm understanding the crypto correctly, this particular signature is not actually load-bearing for the specific use-case of apt repository signing (longer justification in https://github.com/ValveSoftware/steam-for-linux/issues/12050#issuecomment-2932185605). An additional layer of defence is that steam.list uses https: to contact repo.steampowered.com, so you are protected by the GPG key (secure apt) and the https authentication (web PKI): if an attacker tried to distribute a malicious steam-launcher they would have to defeat each of those layers, separately.

Microsoft recently fixed this for their repos, and the old signature file still worked (with the warning) along with the new one

Yes, what I'm hoping to achieve is one step better than that: fix the warning for the old key by renewing its self-signature, and start a graceful transition to a new, stronger key (after which the old key can eventually be phased out).

Ssmcv 2025-08-11 github

An asc file just means it is ASCII-armored, that's it. I was able to generate an asc file with gpg --keyring /usr/share/keyrings/steam.gpg --no-default-keyring --homedir /dev/null --export -a >steam.asc but it didn't do me any good, of course. It was still the same SHA1 signature, just in a different format.

Yes, this. steam-launcher does in fact contain a .asc version of the same key, but it's the same key in a different format, which will not help you. The apt maintainers recommend using the binary format (like steam.gpg) rather than ASCII-armoured (.asc), because they're smaller files and old versions of apt only supported the binary format, but the meaningful content is the same either way.

When an updated signing key becomes available, it will be distributed as a new version of steam.gpg, and upgrading steam-launcher will automatically install the new version.

Ssmcv 2025-08-19 github

Microsoft recently fixed this for their repos, and the old signature file still worked (with the warning) along with the new one

what I'm hoping to achieve is one step better than that: fix the warning for the old key by renewing its self-signature, and start a graceful transition to a new, stronger key (after which the old key can eventually be phased out)

This is implemented in beta 1.0.0.84, which will be promoted to stable after it has been tested for a while. There is a commented-out apt source for the beta in /etc/apt/sources.list.d/steam-beta.list, which you can uncomment if you would like to try it sooner.

You will still see the deprecation warnings during apt update while you are upgrading to the new version (we can't avoid that, it's just how this works). After installing 1.0.0.84 or later, /usr/share/keyrings/steam.gpg will be a new version that does not produce these deprecation warnings.

Technical details

The current/previous signing key …B05498B7 has been re-exported with a stronger self-signature, so that newer apt will not complain about it. This is a 2048-bit RSA key, which is still OK for the next few years (NIST says we should consider keys of this strength to be deprecated after 2030).
There is a new signing key …879D59CB which will be used from now on. This is a 4096-bit RSA key, the same as Ubuntu uses to sign their archive.
The apt repository is now signed with both keys (we've started doing this immediately, even if you aren't using the beta). Systems with 1.0.0.83 or older will validate and trust the old signature, and ignore the new one (they can't validate it, because it comes from a key they don't know about). Systems with 1.0.0.84 or newer will validate both signatures.
At some point (anywhere between the next release and 2030) we'll stop checking against the old key …B05498B7, and require a signature from …879D59CB specifically.
The repository will continue to be signed by both keys to give users a migration path, until we're confident that all users have had time to upgrade.

The keyring at https://repo.steampowered.com/steam/archive/stable/steam.gpg has been updated with both keys. After upgrading to 1.0.0.84 or later, /usr/share/keyrings/steam.gpg will have the same content.

Ssmcv 2025-08-27 github

1.0.0.84 has been promoted to stable, and carries out the key rollover as described in my previous comment. (You might still see 1.0.0.83 as the current version for a few minutes if it's still in the CDN cache.)

New installations with 1.0.0.84 or later will not show the warnings described in this issue report.

Existing installations will show those warnings while updating to 1.0.0.84, but the warnings should stop after 1.0.0.84 has been installed.

For reference, here are the current signing keys:

signing keys

Reference copy: https://repo.steampowered.com/steam/archive/stable/steam.gpg

pub   rsa2048 2012-12-07 [SC]
      BA1816EF8E75005FCF5E27A1F24AEA9FB05498B7
uid                      Valve Corporation <[email protected]>
sub   rsa2048 2012-12-07 [E]

pub   rsa4096 2025-08-18 [SC]
      DB23C56BF0F377FD02970A2A84706F31879D59CB
uid                      Valve steam-launcher repository signing key (2025)

Or paste this into gpg --import:

Kkisak-valve maintainer 2025-10-04 github

Closing per the last comment.

Upstream links

ValveSoftware/steam-for-linux/issues/12050x1 2025-08