[pve-devel] [PATCH docs] package-repos: update key file path and hashes

[Shannon Sterz]

On Thu Jul 17, 2025 at 11:38 AM CEST, Thomas Lamprecht wrote:
> (Cc'ing the pve-devel list again)

sorry about that

>>>>  ----
>>>> -# sha512sum /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
>>>> -7da6fe34168adc6e479327ba517796d4702fa2f8b4f0a9833f5ea6e6b48f6507a6da403a274fe201595edc86a84463d50383d07f64bdde2e3658108db7d6dc87
>>>> -/etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
>>>> +# sha512sum /usr/share/keyrings/proxmox-archive-keyring.gpg
>>>> + 8678f2327c49276615288d7ca11e7d296bc8a2b96946fe565a9c81e533f9b15a5dbbad210a0ad5cd46d361ff1d3c4bac55844bc296beefa4f88b86e44e69fa51
>>>> +/usr/share/keyrings/proxmox-archive-keyring.gpg
>>>
>>> But that will change with the next key ring change, e.g. once a new key for a
>>> future release gets added or an oldoldstable release key is dropped.
>>
>> yes once the `proxmox-archive-keyring` package is install, that file
>> will get overwriten. but since the `wget` install above always fetches
>> just the trixie key, the hashes here should be stable.
>>
>> i'll admit thought that putting just the trixie key in place of the
>> archive key feels wrong, if only for the initial install. however, the
>> archive key isn't available through enterprise.proxmox.com it seems [1].
>
> Yeah, you got me there, I thought about that but was not really sure
> what the upgrade process should look like if it's just presented as
> proxmox-archive-keyring.gpg there.
>
> That said, we could either include the release distribution in the name
> or just document that the available keyring is only guaranteed to cover
> a single past release and the next one. The former would be probably a bit
> more future-proof – what do you think?
>

to be honest, it might be cleanest to tell people to install the keyring
as above with the key matching the release. then verify that it matches
known good hashes. after everything checks out, telling them
that installing the `proxmox-archive-keyring` packages overwrites the
key. so this would work out to basically adding a note like this:

NOTE: The `wget` command above adds the release key for a single {pve}
release as the archive keyring. Once the `proxmox-archive-keyring`
package is installed, it will manage this file. The hashes will change
as keys for other {pve} releases will be added and removed. This means
the hashes below are only valid for the initial install on top of an
existing Debian system.
.
**Modifying this file is discouraged once `proxmox-archive-keyring` is
installed.**

this way the Signed-By lines are correct and don't need to be adjusted
by users and they should not be confused if the hashes change after
installing `proxmox-archive-keyring`.

>>
>> [1]: https://enterprise.proxmox.com/debian/
>>
>>>
>>> Switching to /user still makes sense, in the long run /etc might even
>>> get fully deprecated.
>>>
>>> We either could stay using the per-release key files, which are also available
>>> in /usr, or, for a slightly bigger change, switch to the `sq keyring list`
>>> output–or some other fitting command of it.
>>>
>>> As some sq tools are now used by core debian packaging tools like apt, it'
>>> be relatively safe to use here IMO.
>>>
>>> For example:
>>>
>>> # sq keyring list /usr/share/keyrings/proxmox-archive-keyring.gpg
>>> 0. F4E136C67CDCE41AE6DE6FC81140AF8F639E0C39 Proxmox Bookworm Release Key <proxmox-release at proxmox.com>
>>> 1. 24B30F06ECC1836A4E5EFECBA7BCD1420BFE778E Proxmox Trixie Release Key <proxmox-release at proxmox.com>
>>
>> hm that does not seem to work for me on a clean pve 9 install, but we
>
> Ah, apt depends on sqv for signature verification, which is a different
> package. That said, a plain Debian netinst would probably be the better
> test here, as a PVE installation hasn't the exact same dependencies
> involved as Debian does and the plain Debian install is where this is
> needed in the first place.

isn't part of clean debian container here either. that being said, i'm
not particularly fond of the below solution either. hence why simply
sticking to hashes might be nicer.

will send a patch with my proposed changes in a minute.

>> could do the following with plain gpg:
>>
>> # gpg --list-packets < /usr/share/keyrings/proxmox-archive-keyring.gpg
>>
>> the output is rather long, so maybe we want to add a grep after?
>> something like this
>>
>> # gpg --list-packets < /usr/share/keyrings/proxmox-archive-keyring.gpg |
>>  grep -A 5 "Proxmox Trixie Release Key"
>>  :user ID packet: "Proxmox Trixie Release Key <proxmox-release at proxmox.com>"
>>  # off=2960 ctb=c2 tag=2 hlen=3 plen=596 new-ctb
>>  :signature packet: algo 1, keyid A7BCD1420BFE778E
>>         version 4, created 1731244488, md5len 0, sigclass 0x13
>>         digest algo 10, begin of digest 10 59
>>         hashed subpkt 33 len 21 (issuer fpr v4 24B30F06ECC1836A4E5EFECBA7BCD1420BFE778E)
>>
>> would that be acceptable?
>
> Could be, but not really that nice IMO...
>