apt repo signature warning

[gouenji-shuuya]

After upgrading apt to v3 (which is in Debian testing, soon to become stable), when running apt update we see the following warning:

Warning: https://download.sublimetext.com/apt/stable/InRelease: Policy will reject signature within a year, see --audit for details

Running apt update --audit yields the following additional output:

Audit: https://download.sublimetext.com/apt/stable/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
   Signing key on 1EDDE2CDFC025D17F6DA9EC0ADAE6AD28A8F901A is not bound:
              primary key
     because: No binding signature at time 2025-05-07T04:20:25Z
     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

[Drizzt321]

I'm getting this as well, please update your Debian key to use something newer than sha1 before it stops working.

[paolocalosso]

same here

[michaelblyons]

Is it clear whether all three of the becauses are going to be [independently] fatal, or just the SHA1 fingerprint?

[gouenji-shuuya]

SHA1 fingerprint causes the error (yes it's going to be fatal).

[Drizzt321]

@michaelblyons it will eventually turn into a fatal "apt won't pull from that repo anymore". It's an apt warning, saying they've (Debian project) deprecated sha1 as a valid key/has for apt repo key purposes

[michaelblyons]

I think both of you have misunderstood my question in the same way, which suggests I did not phrase it well.

I understand that Debian will no longer trust the signing key because of the fingerprint algorithm. I am asking whether it is also complaining about other problems with the key and how impactful those are.

Is it like this:

Hey you have three problems!

• No binding signature
• Key doesn't expire
• We don't like SHA1

Or like this:

Hey you have a problem! Here's a stack trace:

• No binding signature, because
  • The key doesn't expire, which would be okay, except that
    • We don't like SHA1

Or even something else?

Sublime probably doesn't want to mess with keys, discover that they're still broken in a different way, and have to update again.

[gouenji-shuuya]

It's a stack trace, that's why I said SHA1 causes the error.

Sublime probably doesn't want to mess with keys

This was bad to assume to begin with - as their supposed convenience will cause warnings everywhere.

And anyways, even if it were 3 different errors, doing nothing solves nothing.

It's just that the maintainers didn't see the error yet, not some weird "they don't want to mess" stuff.

[michaelblyons]

This was bad to assume to begin with - as their supposed convenience will cause warnings everywhere.

And anyways, even if it were 3 different errors, doing nothing solves nothing.

It's just that the maintainers didn't see the error yet, not some weird "they don't want to mess" stuff.

I never implied that they don't want to fix the upcoming problem. I said that they don't want to fix one problem and then discover that there are two more problems that require more work and then every user has to re-key again.

It's a stack trace, that's why I said SHA1 causes the error.

Thank you for answering my question.

[Drizzt321]

That's not a stacktrace, not the way I interpret it. It's a "these validation issues exist". Stacktrace is "unexpected error bubbled up", validation error is "performed checks, here are the problems".

These are pro-active checks, apt warning saying, sooner than later, it will stop working with this repo with this key. So I'm pretty sure the GPG signing key just needs to be updated to use sha-2/sha-256 or the like. So until 2026, it'll continue to get to fetch/update from the existing repo, but sometime in 2026 looks like they'll turn off allowing SHA-1 as a signature key. Might as well start the process now, and plan and schedule the work done and tested in the next several months, rather than wait until it just stops working.

Changelog: https://launchpad.net/debian/+source/apt/2.9.19

  * Replace GnuPG with Sequoia on supported Debian platforms
    - methods: Add new sqv method
    - debian: Add default policy to allow SHA-1 self-signatures until 2026
    - debian: Plug sqv into the package build

SHA-1 on Debian
https://wiki.debian.org/SHA-1
https://wiki.debian.org/Teams/Apt/Sha1Removal

[znre]

I'm getting this as well, please update your Debian key to use something newer than sha1 before it stops working.

Hi, would you happen to have any references with instructions on how to update the Debian key?

[gouenji-shuuya]

@znre the repo owner first needs to provide / use a newer compatible key.

Hence the issue.

[er0k]

Hi, would you happen to have any references with instructions on how to update the Debian key?

As mentioned by @gouenji-shuuya, the maintainer needs to re-sign the key using stronger algorithms. Here is a blog post with instructions, but some users have reported it contains errors, but it's the best reference I could find. Alternatively, you could try sq-keyring-linter --fix) (superseded by sq cert lint --fix) as mentioned in this thread.

For end users, you could manually change the the expiration date(s) in /usr/share/apt/default-sequoia.config to temporarily get rid of the warning, but that is just kicking the can down the road.

Hope this helps.

[jniggemann]

Underlying cause

Internally, apt uses "Sequoia PGP" to verify signatures - hence the message that /usr/bin/sqv returnes an error code in your example above. By default, sqv is configured to accept the (old and broken) SHA1 hash algorithm only until Feb 1st 2026.

How to resolve this issue

There's nothing you can do besides raising awareness for this issue.
This issue can only be resolved by the project team, who need to change their repo signing key to one that does not use SHA1.

How to temporarily suppress this warning until this repo uses another key

To reconfigure sqv, copy /usr/share/apt/default-sequoia.config to /etc/crypto-policies/back-ends/apt-sequoia.config, and change the date in the last line from 2026-02-01 to ex. 2027-02-01. (more)

Please think about possible implications and do not forget to revert this, once the project team has switched to another key.

[gouenji-shuuya]

We know that, read the issue discussion. There was no point in posting output from chatgpt, which also suggests a useless workaround kicking the can down the road.