From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 5E8EF1FF13C for ; Thu, 28 May 2026 12:26:52 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5A85A1292C; Thu, 28 May 2026 12:26:51 +0200 (CEST) Message-ID: Date: Thu, 28 May 2026 12:26:47 +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: Lukas Wagner , 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1779963980062 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: UZZRF4VXG6H7RH5D3NCG6LXH6BHH7FFF X-Message-ID-Hash: UZZRF4VXG6H7RH5D3NCG6LXH6BHH7FFF 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: Am 28.05.26 um 12:01 schrieb Lukas Wagner: > On Thu May 28, 2026 at 11:54 AM CEST, Thomas Lamprecht wrote: >> IMO a bit borderline, as this is not like a classic API token where this >> causes active service disruption. > ack, FWIW, I checked what we do for classic API tokens, and while it's > of course not the exact same thing, it seemed similar enough to use the > same semantics here. Actually I went back and forth a bit on exactly those yesterday, less because of impact but more as each such sets basically a precedent ^^ But ultimately decided that it's probably fine to err on the side of caution, especially on removals and also with the not so big UI/UX impact here; that's why it's also fine here. So all good, just wanted to give slightly more context of my thoughts here. And btw. my trigger for changing the confirm prompt in the first place was the flashy red error icon that sprung into me when opening the "apply pending" subscription prompt the first time after getting some distance from testing it and me then thinking "wait, did I press a delete button".