From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 90C1D1FF13B for ; Wed, 08 Apr 2026 09:49:51 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0AE5C2779; Wed, 8 Apr 2026 09:50:27 +0200 (CEST) Date: Wed, 08 Apr 2026 09:50:19 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= Subject: Re: [PATCH proxmox{,-backup} 00/20] fix #7251: implement server side encryption support for push sync jobs To: Christian Ebner , pbs-devel@lists.proxmox.com, Thomas Lamprecht References: <20260401075521.176354-1-c.ebner@proxmox.com> <185f5e2a-4c73-4e43-8089-f6383d5198cc@proxmox.com> In-Reply-To: <185f5e2a-4c73-4e43-8089-f6383d5198cc@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1775634036.o4lx1mdxmb.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775634555840 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.053 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 7XBWFLE4AVXKCW7FFZDMZTFOBVNYUXKH X-Message-ID-Hash: 7XBWFLE4AVXKCW7FFZDMZTFOBVNYUXKH X-MailFrom: f.gruenbichler@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On April 2, 2026 9:37 am, Christian Ebner wrote: > On 4/2/26 2:24 AM, Thomas Lamprecht wrote: >> Am 01.04.26 um 09:55 schrieb Christian Ebner: >>> This patch series implements support for encrypting backup snapshots >>> when pushing from a source PBS instance to an untrusted remote target >>> PBS instance. Further, it adds support to decrypt snapshots being >>> encrypted on the remote source PBS when pulling the contents to the >>> local target PBS instance. >>=20 [..] >=20 >> When a server-side key is configured on push, all snapshots with any >> encrypted content are silently skipped. That includes fully client-side >> encrypted ones that could just be synced as-is - they are already encryp= ted >> after all. Might be better to push those unchanged and only skip genuine= ly >> partially-encrypted snapshots? Or if unsure, allow to user to chose what >> they want. Wrapping encryption is probably never a good idea though, >> maybe just any parts that are not yet encrypted? >=20 > Pushing fully encrypted ones as is makes sense, only log and skip=20 > partially encrypted snapshots. pushing fully encrypted snapshots *if they use the same key*, or all fully encrypted snapshots? I think the former is okay, the latter might be confusing/unexpected and lead to "I have all my backups on the remote but can't decrypt them because of the wrong key"? e.g.: client A uses key A to backup to PBS X client B uses plaintext to backup to PBS X PBS X uses key B to sync to PBS Y user thinks key B is enough to restore backups from Y (after all, it's the encryption key used for syncing), and destroys clients A and B and PBS X (all in the same location maybe?). now they can't recover client A.. I know this is technically on the user (they didn't pay attention to their key management), but seems like a potential foot gun. if we skip the groups of client A because of a key mismatch (and warn about that?) then it is at least obvious that those backups *are not on Y*. we could have a flag for allowing key mismatches to support such scenarios opt-in? >> Nit: The same `encryption_key` field means "encrypt" for push and >> "decrypt" for pull. Maybe be literal here and name it decryption_key for >> the later. Or something generic that works for both. >=20 > Yes, that make sense... Was primed by the fact that the entities=20 > themself are referred to as encryption keys, but renaming this to=20 > decryption_key for the pull makes more sense for making the code better=20 > readable. Will adapt that. >=20 >> A few key lifecycle things: >>=20 >> Deleting a key does not check whether sync jobs reference it; the next r= un >> just fails. Might want to refuse deletion while references exist, or at >> least warn. >=20 > Yes, also realized this just now, will add a check for this in the api=20 > handler and not allow to remove it in that case. key rotation/lifecycle management would be a question in any case - we could have one "active" key per sync job, and a list of archived ones that are only used for decryption? a key rotation would obviously break deduplication chains.. such a scheme would also allow re-encryption on the fly of client-encrypted backups, if a matching key is provided - though the use case for that seems limited to me (why encrypt in the first place if you trust this PBS with the plaintext data?). or alternatively it would need to be documented that for rotating a key, you want to create a new key and target namespace, then switch the sync job over (syncing everything from scratch), and delete the old copies encrypted with the previous key once the re-sync is done?