Re: [pbs-devel] applied: [PATCH proxmox-backup] tape: fix regression in restoring key from medium

[Dominik Csapak <d.csapak@proxmox.com>]

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 <d.csapak@proxmox.com>
>> ---
>> 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!