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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7A584937FD for ; Tue, 6 Feb 2024 09:07:38 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 614EF30A05 for ; Tue, 6 Feb 2024 09:07:38 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 6 Feb 2024 09:07:37 +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 1C31F444BC; Tue, 6 Feb 2024 09:07:37 +0100 (CET) Message-ID: <9823b24b-1447-4a91-9bb4-8e0810658dda@proxmox.com> Date: Tue, 6 Feb 2024 09:07:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20240131134233.86370-1-d.csapak@proxmox.com> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.020 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 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [drive.rs, mod.rs] Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup] tape: fix regression in restoring key from medium 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, 06 Feb 2024 08:07:38 -0000 On 2/2/24 17:07, Thomas Lamprecht wrote: > Am 31/01/2024 um 14:42 schrieb Dominik Csapak: >> when trying to restore a key from a tape, we automatically try to load >> the key into the drive after reading the media-set label. >> >> Since the key restore is only useful when the key is not already on >> disk, this fails of course. >> >> To fix it but leave the automatism in place, introduce a function >> 'read_label_without_loading_key' that does the heavy lifting of reading >> the labels but does not load the encryption key. Then in read_label, >> call that function and explictely load the key (when one exists). >> >> Then, we only have to use this new function in the 'restore-key' api >> call for the restore to work as intended. >> >> Fixes: 1343dcaf ("tape: move 'set_encryption' calls to the TapeDriver (and implementation)") >> Signed-off-by: Dominik Csapak >> --- >> should be cherry-pickable for stable-2 if necessary >> >> src/api2/tape/drive.rs | 2 +- >> src/tape/drive/mod.rs | 42 ++++++++++++++++++++++++++++++------------ >> 2 files changed, 31 insertions(+), 13 deletions(-) >> >> > > applied, with a reword commit message, thanks! > > But I'm wondering, why exactly caused the key load issues if we are > in the mixed mode anyway? the error was from our side, since we did not find the key in a disaster recovery case (when you want to restore the key from tape) > > A reference to the forum post, bugzilla with the report of the user > running into this would have been nice too.. it was a customer in the enterprise support, so there's nothing public to link to > > But yeah, as this should not hurt and we got other fixes to roll out > I'm keeping continuing to roll this out nonetheless for now. thanks!