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

[Thomas Lamprecht]

(Cc'ing the pve-devel list again)

Am 17.07.25 um 11:16 schrieb Shannon Sterz:
> On Thu Jul 17, 2025 at 10:47 AM CEST, Thomas Lamprecht wrote:
>> Am 17.07.25 um 10:00 schrieb Shannon Sterz:
>>> so they better match the repository defintions above
>>
>> tiny typo: definitions
> 
> thanks
> 
> -->8 snip 8<--
> 
>>>  ----
>>> -# 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?

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

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

> 
>> Could be combined with the per-release hash sums, and if we change this I'd
>> be a tiny bit in favor of switching sha512sum to sha256sum, as I don't think
>> we or users gain much security, longer strings aren't easier to compare and
>> sha256sum is still very much state of the art and deemed as unfeasible to break,
>> IIRC.
> 
> yes, sha512sum is a bit much, i just wanted to stay consistent with what
> was already here. sha512sum would only provide better security against
> length extension attacks in practice. however, that attack should not
> really be a problem here, as extending the keyring will still change the
> hash. it simply isn't the kind of cryptographic construction where this
> matter.

True, but I also think that it's not relevant, should be noticeable if the
keyring download pulls in a few GiB of data ^^ Besides, that was actually
one of the reasons to keep md5sum in here, as it works so differently than
sha2, so it should be much harder to attack both at the same time than the
(currently) already basically impossible case for attacking just sha2.

> let me know what you prefer and i'll prepare a patch asap

Thanks!

Btw. in the mid-term we might look into adding our keyring package to Debian's
repos directly, and that would then make it much more convenient to install
on top of Debian, but that is Debian 14 Forky material.