public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Jeremy Davis <jeremy@turnkeylinux.org>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Alon Swartz <alon@turnkeylinux.org>
Subject: Re: [pve-devel] [TurnKey Linux] Looking to update our signing key... Advice?
Date: Thu, 23 Nov 2023 13:04:00 +1100	[thread overview]
Message-ID: <5202454b-f7d0-4ccc-b21a-1155d074f7c5@turnkeylinux.org> (raw)
In-Reply-To: <b07d491d-adb3-42c2-b4e2-a8c875e34721@proxmox.com>


[-- Attachment #1.1: Type: text/plain, Size: 4317 bytes --]

Thanks for your quick and comprehensive response! You guys rock! :)

On 22/11/23 19:19, Thomas Lamprecht wrote:
> It's fine here, thanks for reaching out.
> 

:)

>> As a housekeeping matter, we're looking to update our GPG signing key -
>> that we sign the index file we provide for downloading our LXC templates
>> via the PVE UI (which includes hashes of our templates).
> 
> That would be indeed great, we switched to generating a new key for
> every new major release quite a bit ago.
> 

Ok great, thanks.

>> The current key recently expired (caught us a bit unawares). We updated
>> the expiry to keep it alive. And it doesn't seem to have caused any
>> issues (at least not in my local PVE servers).
>>
>> However, the key is quite old and doesn't have current best practice
>> size (RSA-4098 AFAIK?). So I'd like to rotate it.
> 
> Yes, our release keys use RSA 4096 (not 6 not 8 at the end):

Oops. That's what I meant... ;)

> 
> Currently the public keys we use are tracked in the pve-manager repo,
> inside the aplinfo directory:
> 
> https://git.proxmox.com/?p=pve-manager.git;a=tree;f=aplinfo;h=9dbe1f31f712bb537168bf11e052d5117c62e1f6;hb=ad1278fae8e6e678219a702eea960c746551c635
> 
> The build-system then concatenates all the trusted keys, i.e., our ans
> your current (old) one to a joined keyring that we use on checking the
> appliance index.
> 
> So, you would just need to send us your new public key in a secure
> manner and we'd add that key to the keyring.  Secure manner here would
> be to have it available on a TLS secured domain of your via HTTP and
> send it to us via email with a signature from the old (current) key.
> 

Ok, brilliant

> The one question is how you plan the upgrade, i.e., it might be nice to
> not have a hard switch between index signed with old to index signed
> with new key.
> 
> For example, since doing a new GPG key per-release we also use a index
> that can be associated with the release, e.g. see:
> 
> http://download.proxmox.com/images/
> 
> For example, the plain & compressed indexes, and the signature of the
> plain one, used for the Proxmox VE 8 series are:
> 
> aplinfo-pve-8.dat
> aplinfo-pve-8.dat.asc
> aplinfo-pve-8.dat.gz
> 

Thanks for sharing that info. That's really useful.

> 
> It could be also good for TurnKey to provide the new templates under a
> new index so that older installation can still use them.
> Even if you want to consciously break support for systems using the old
> key, it might be more pleasant to do a phased switch  even then.
> Especially as one could test the new index URL and signature without
> impacting production systems, you could still drop the signature with
> the ancient key in a few weeks or so.

That makes tons of sense.

> 
> Any how, I'm asking the latter because that might need some extra
> adaption in our code, but not much, and if you give us the new URL to
> the new index we could integrate that too. But if you want to sent
> patches, then we'd also be happy about that, most of the code is also in
> pve-manager, in the PVE::APLInfo module (PVE/APLInfo.pm file).
> 
> For how to contribute patches to our project see:
> https://pve.proxmox.com/wiki/Developer_Documentation

I'll digest all this a little more and confer with my colleague Alon and 
we'll decide exactly how we approach this.

> 
>> Also if there are any specific PVE recommendations/requirements re the
>> new GPG keypair to generate, that would also be great.
> 
> Nothing technical,  RSA 4096-bit key with a identity (mail email) that
> matches your org would be the baseline. Having a expiry of about 10y
> could be nice too, but not to hard-feelings there.

That sound fair to me.

Thanks again for your comprehensive guidance and advice.

Considering that we're already a bit overwhelmed with a backlog a mile 
long and xmas/new year just around the corner, I'm not sure we'll get 
this done this year or not. But hopefully sooner rather than later.

Regardless, I'll be back at some point with patches and/or further 
questions and/or ... once we have some progress on our end.

Please don't hesitate to reach out if you're wondering where we're up to...

Take care and thanks again.

Cheers,
Jeremy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

      reply	other threads:[~2023-11-23  2:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22  4:50 Jeremy Davis
2023-11-22  8:19 ` Thomas Lamprecht
2023-11-23  2:04   ` Jeremy Davis [this message]

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=5202454b-f7d0-4ccc-b21a-1155d074f7c5@turnkeylinux.org \
    --to=jeremy@turnkeylinux.org \
    --cc=alon@turnkeylinux.org \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal