From: "Shannon Sterz" <s.sterz@proxmox.com>
To: <pve-devel@lists.proxmox.com>
Subject: [pve-devel] Fwd: Re: [PATCH docs] package-repos: update key file path and hashes
Date: Fri, 18 Jul 2025 10:43:37 +0200 [thread overview]
Message-ID: <DBF1NTXL2KC4.22UTE95WDZL3H@proxmox.com> (raw)
sorry the list got dropped again :/
Forwarded message from Shannon Sterz on Fri Jul 18, 2025 at 10:39 AM:
On Thu Jul 17, 2025 at 7:27 PM CEST, Thomas Lamprecht wrote:
> Am 17.07.25 um 15:32 schrieb Shannon Sterz:
>> On Thu Jul 17, 2025 at 1:55 PM CEST, Thomas Lamprecht wrote:
>>> Am 17.07.25 um 12:33 schrieb Shannon Sterz:
>>>>>> 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:
>>>
>>> Cleaner than providing the combined release key with a name like
>>> "proxmox-archive-keyring-trixie.gpg" for downloading? As that
>>> would be in essence the same thing, but the user would always have the
>>> correct file there.
>>
>> works for me, though it does make much difference imo, just means more
>> changes on our end? id still put a note in the docs that the hash of
>> this file may change once `proxmox-archive-keyring` is installed.
>
> Saving different keys under different names seems just not great, and
> changing hash sums are not ideal either, you stated yourself that doing
> this feels wrong. And the work of uploading a new keyring roughly every
> two years seems just to little to think to much about it, as while
> definitively agree with you that most of the time it won't matter much,
> if it can reduce confusion potential even just a tiny bit it's still
> a good investment.
> For me it was mostly important that there is no bigger downside (besides
> having to upload this) I missed, so I uploaded it now, it's available as
>
> https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg
>
>>
>>> Yet another option would be pointing to the actual keyring package in
>>> a specific version + respective hashes and recommend to install that
>>> directly – that might be even more convenient.
>>
>> yes, the only downside is see there is that it might harder to verify
>> for a user whether a .deb package only ships keys and nothing else.
>> though, in the end, they'll have to trust us with that anyway. so works
>> for me too.
>
> Exactly, trust must be there or else adding our keys is always problematic.
> And FWIW, `dpkg -c FILE` and `dpkg -x FILE TARGET` are a thing, so
> packages can be rather easily inspected by anybody before installation.
>
>>
>>>> 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`.
>>>
>>> Could be OK, but uploading an extra key or the package wouldn't be much
>>> work. So if you do not see any issue there I'd prefer that route, and
>>> would be open to feedback for what option might be better in the end.
>>
>> fine by me, i can send another patch once the keyring for trixie has
>> been published.
>
> Thanks! See above and
>
> https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg
alright, send a patch incorporating this. will updated the pbs docs too
in a minute.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
reply other threads:[~2025-07-18 8:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DBF1NTXL2KC4.22UTE95WDZL3H@proxmox.com \
--to=s.sterz@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.