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 E04631FF142 for ; Tue, 07 Apr 2026 17:11:56 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B120F1F063; Tue, 7 Apr 2026 17:12:31 +0200 (CEST) Message-ID: Date: Tue, 7 Apr 2026 17:12:27 +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: pbs-devel@lists.proxmox.com References: <20260401075521.176354-1-c.ebner@proxmox.com> Content-Language: en-US From: Manuel Federanko In-Reply-To: <20260401075521.176354-1-c.ebner@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775574681443 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.938 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: GQIPHY6X256Q7HY6TLIOXOO3MAQAX2PA X-Message-ID-Hash: GQIPHY6X256Q7HY6TLIOXOO3MAQAX2PA X-MailFrom: m.federanko@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 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: 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) 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 adding a key which is password protected works, which we could already check against, to prevent later failures in sync jobs. 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. apologies if some of these issues are already touched upon by the others. Other than that it lgtm and works as expected.