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 0FDA71FF13C for ; Thu, 28 May 2026 11:54:51 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 17F8611CB2; Thu, 28 May 2026 11:54:50 +0200 (CEST) Message-ID: Date: Thu, 28 May 2026 11:54:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous To: Shannon Sterz , pdm-devel@lists.proxmox.com References: <20260528092618.111906-1-s.sterz@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20260528092618.111906-1-s.sterz@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: 1779962029787 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.005 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 Message-ID-Hash: SZ65LBACM4EACLERISMD2PSBPVEJLZ4R X-Message-ID-Hash: SZ65LBACM4EACLERISMD2PSBPVEJLZ4R X-MailFrom: t.lamprecht@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 Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thx for the patch and the quick apply. FWIW this is missing commit message body and none added on applying, a short sentence here would be appreciated. Am 28.05.26 um 11:25 schrieb Shannon Sterz: > Signed-off-by: Shannon Sterz > --- > ui/src/remotes/auto_installer/token_panel.rs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/ui/src/remotes/auto_installer/token_panel.rs b/ui/src/remotes/auto_installer/token_panel.rs > index 3732ffe..0ee5afc 100644 > --- a/ui/src/remotes/auto_installer/token_panel.rs > +++ b/ui/src/remotes/auto_installer/token_panel.rs > @@ -218,6 +218,7 @@ impl LoadableComponent for AuthTokenPanelComponent { > All existing ISOs with this token will lose access!" > )) > .disabled(self.selection.is_empty()) > + .dangerous(true) > .on_activate(link.callback(|_| Message::RegenerateSecret)), > ) > .with_flex_spacer() IMO a bit borderline, as this is not like a classic API token where this causes active service disruption. OTOH. setting that flag hasn't that big of an impact and doesn't really hurt either, so fine. I'd just avoid using it for everything that can be framed as destructive, as most things with a confirmation prompts might be, as then it looses the punch a bit (or could again just be the default). But when implementing these yesterday I also could not come up with a definitive rule that always holds, so certainly not a clear cut - just wanted to avoid that we use this to liberally now - as said, here it was OK to do (except the short missing rationale).