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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 1D48B656DF for ; Thu, 23 Jul 2020 12:35:09 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0C0C728233 for ; Thu, 23 Jul 2020 12:34:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 id 4337928228 for ; Thu, 23 Jul 2020 12:34:38 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 10B794332B for ; Thu, 23 Jul 2020 12:34:38 +0200 (CEST) Date: Thu, 23 Jul 2020 12:34:30 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion , Stefan Reiter References: <20200723092136.2527542-1-f.gruenbichler@proxmox.com> <4e2552b4-8ea8-6252-f58e-f22e08d55ec4@proxmox.com> In-Reply-To: <4e2552b4-8ea8-6252-f58e-f22e08d55ec4@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1595499980.xeb6wkgs4y.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.061 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH proxmox-backup-qemu] fix #2866: invalidate bitmap on crypt_mode change X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 10:35:09 -0000 On July 23, 2020 12:07 pm, Stefan Reiter wrote: > idea looks ok, comments inline >=20 > On 7/23/20 11:21 AM, Fabian Gr=C3=BCnbichler wrote: >> signed and plain backups share chunks, so bitmap reusal is okay for >> those combinations. switching from encrypted to not encrypted or >> vice-versa could have pretty fatal consequences - either referencing >> plain-text chunks in 'encrypted' backups, or referencing encrypted >> chunks in 'unencrypted' backups without still having the corresponding >> keys.. >>=20 >> Signed-off-by: Fabian Gr=C3=BCnbichler >> --- >>=20 >> Notes: >> requires recent proxmox-backup with public lookup_file_info >>=20 >> src/backup.rs | 3 ++- >> src/commands.rs | 35 +++++++++++++++++++++++++++++++++-- >> 2 files changed, 35 insertions(+), 3 deletions(-) >>=20 >> diff --git a/src/backup.rs b/src/backup.rs >> index 717e099..b8108ef 100644 >> --- a/src/backup.rs >> +++ b/src/backup.rs >> @@ -202,7 +202,8 @@ impl BackupTask { >> device_name: String, >> size: u64, >> ) -> bool { >> - check_last_incremental_csum(self.last_manifest(), device_name, = size) >> + check_last_incremental_csum(self.last_manifest(), &device_name,= size) >> + && check_last_encryption_mode(self.last_manifest(), &device= _name, self.crypt_mode) >> } >> =20 >> pub async fn register_image( >> diff --git a/src/commands.rs b/src/commands.rs >> index 6f26324..8d8f2a7 100644 >> --- a/src/commands.rs >> +++ b/src/commands.rs >> @@ -80,7 +80,7 @@ pub(crate) async fn add_config( >> =20 >> pub(crate) fn check_last_incremental_csum( >> manifest: Option>, >> - device_name: String, >> + device_name: &str, >> device_size: u64, >> ) -> bool { >> =20 >> @@ -91,12 +91,43 @@ pub(crate) fn check_last_incremental_csum( >> =20 >> let archive_name =3D format!("{}.img.fidx", device_name); >> =20 >> - match PREVIOUS_CSUMS.lock().unwrap().get(&device_name) { >> + match PREVIOUS_CSUMS.lock().unwrap().get(device_name) { >> Some(csum) =3D> manifest.verify_file(&archive_name, &csum, dev= ice_size).is_ok(), >> None =3D> false, >> } >> } >> =20 >> +pub(crate) fn check_last_encryption_mode( >> + manifest: Option>, >> + device_name: &str, >> + crypt_mode: CryptMode, >> +) -> bool { >> + >> + let manifest =3D match manifest { >> + Some(ref manifest) =3D> manifest, >> + None =3D> return false, >> + }; >=20 > this... >=20 >> + >> + let archive_name =3D format!("{}.img.fidx", device_name); >=20 > ...and this could probably be moved to check_incremental to avoid=20 > duplication. probably device to archive name could also be refactored into a helper?=20 with this patch we have three identical format! calls.. >=20 >> + match manifest.lookup_file_info(&archive_name) { >> + Ok(file) =3D> { >> + eprintln!("device {} last mode: {:?} current mode {:?}", de= vice_name, file.crypt_mode, crypt_mode); >=20 > left over debug print or intentional? this would be hidden atm, as we=20 > don't track QEMU output anywhere. both :-P I figured with all the issues we had with encrypted backups,=20 telling users to start in the foreground and watch the output might be=20 helpful. but I'm fine with dropping it. >=20 >> + match file.crypt_mode { >> + CryptMode::Encrypt =3D> match crypt_mode { >> + CryptMode::Encrypt =3D> true, >> + _ =3D> false, >> + }, >> + CryptMode::SignOnly | CryptMode::None =3D> match crypt_= mode { >=20 > you can use the _ match here too, same as in the inner match call. intentional, if we add a new CryptMode in proxmox-backup this forces us=20 to match it here unless I misunderstood how match on enums works in=20 Rust. >=20 >> + CryptMode::Encrypt =3D> false, >> + _ =3D> true, >> + }, >> + } >> + }, >> + _ =3D> false, >> + } >> +} >> + >> + >> pub(crate) async fn register_image( >> client: Arc, >> crypt_config: Option>, >>=20 >=20 =