From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 540EA95661 for ; Tue, 27 Feb 2024 10:12:12 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 354951A21C for ; Tue, 27 Feb 2024 10:12:12 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 27 Feb 2024 10:12:11 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id EB500476A3; Tue, 27 Feb 2024 10:12:10 +0100 (CET) Content-Type: text/plain; charset=UTF-8 Date: Tue, 27 Feb 2024 10:12:10 +0100 Message-Id: From: "Stefan Sterz" To: "Esi Y" , Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.17.0-62-gff77c7a52d78 References: <20240215152001.269490-1-s.sterz@proxmox.com> <20240215152001.269490-2-s.sterz@proxmox.com> In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.078 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox 01/12] auth-api: move signing into the private key X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2024 09:12:12 -0000 On Mon Feb 26, 2024 at 9:22 PM CET, Esi Y wrote: > This might be a bit nitpicky, but wouldn't this exactly be an > opportunity to properly introduce traits, so that in the future on the > same kind of swapout, it is more streamlined and less regression prone > going forward? Just wondering ... if there was a reason not to, on > such a rewrite. i am a bit uncertain as to what you mean here, as this series more or less uses such wrapper traits around the openssl api. `PrivateKey` and `PublicKey` wrap a `PKey` and `PKey` respectivelly. `HMACKey` wraps a `PKey` that is treated as an hmac key. this means that users of the auht-api crate don't have to use openssl to generate keys or handle them. it also means that the implementation of these traits is entirely private in the auth-api, so users don't need to adapt if we extend them with support for more cryptographic schemes (note that removing such schemes is always a breaking change). in the future, if you needed to switch out a key you have the keyring in the authcontext that can handle roll over (for the most part, but i am working on the missing links here). new keys would be added as the signing key (hence my introduction of the `SigningKey` and `VerificationKey` enums in patch 3) the old keys would stay as verification keys and be evicted after a given number of key rotations. using enums here was just simple, and unless a third type of crypto beside symmetric and asymmetric arises, this should be sufficient and not overcomplicate the code. what kind of traits would you propose to make such transitions even easier? ps: hard wrapping your emails would be nice :) -- >8 snip 8< --