From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 2C52F1FF142 for ; Tue, 07 Apr 2026 18:17:39 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0662B1FBB3; Tue, 7 Apr 2026 18:18:14 +0200 (CEST) Message-ID: <9d922ec1-8fa4-4a51-9469-8113f94722f3@proxmox.com> Date: Tue, 7 Apr 2026 18:17:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH proxmox{,-backup} 00/20] fix #7251: implement server side encryption support for push sync jobs To: Manuel Federanko , pbs-devel@lists.proxmox.com References: <20260401075521.176354-1-c.ebner@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775578590791 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.068 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: ECRMM7PW5YARKXFZZXSCQXS2RDQRTIOA X-Message-ID-Hash: ECRMM7PW5YARKXFZZXSCQXS2RDQRTIOA X-MailFrom: c.ebner@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 4/7/26 5:11 PM, Manuel Federanko wrote: > On 2026-04-01 9:55 AM, Christian Ebner wrote: >> 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. This allows to perform full server side >> encryption/decryption when syncing with a less trusted remote PBS. >> >> In order to encrypt/decrypt snapshots, a new encryption key entity >> is introduced, to be created as global instance on the PBS, placed and >> managed by it's own dedicated config. Keys with secret are stored >> in dedicated files so they only need to be loaded when accessing the >> key, not for listing of configuration. >> >> The sync jobs in push and pull direction are extended to receive an >> additional encryption key parameter, allowing the given key to be >> used for encryption/decription of snapshots, depending on the sync >> direction. In order to encrypt/decrypt the contents, chunks, index >> files, blobs and manifest are additionally processed, rewritten when >> required. >> >> Link to the bugtracker issue: >> https://bugzilla.proxmox.com/show_bug.cgi?id=7251 >> > > I just had a go at this, looks good overall, a couple of issues: Thanks for testing! > > it's not possible to not specify a encryption key during sync job > creation, the dialog fails with an error: >> "encryption-key: value must be at least 3 characters long" > it still works via the cli > > creating a sync job with a unknown encryption key silently succeeds, > leaving the key unset (via the cli) Will double check these and the length checks below, thanks for reporting! > > nit: the encryption key name length check is inconsistent, I can only > create keys where the name is 4 characters or longer, the check > for a sync job is 3 characters > > when removing a encryption key a "unknown error" is displayed to > the user Thanks, this has been reported by Dominik and is fixed already for the upcoming version of the patches. > > adding a key which is password protected works, which we could > already check against, to prevent later failures in sync jobs. Yes, reported also by Thomas and will be checked and not be possible in v2. > > a pull sync which had a correct key set will decrypt a backup > switching a key from that pull job (or starting another pull > job with a different key) will mark the backup as corrupt and > re-sync it, replacing the decrypted backup with a encrypted one. >> re-sync snapshot host/tali/2026-04-07T14:35:30Z >> detected changed file "/mnt/datastore/zfs0/host/tali/2026-04-07T14:35:30Z/config.pxar.didx" - wrong checksum for file 'config.pxar.didx' > I'm not sure we even want to allow that since that setup is > inherently at odds. Thanks for reporting, decryption during pull is the intended behavior, it will be made clearer by switching the labels (and add the still missing docs). It should however not lead to resync as corrupted backup, that is indeed unwanted. Will have a closer look, thanks! > > > apologies if some of these issues are already touched upon by the > others. > > Other than that it lgtm and works as expected. > > > >