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 D737E1FF38E for ; Tue, 28 May 2024 10:18:34 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8428210AC0; Tue, 28 May 2024 10:18:57 +0200 (CEST) Date: Tue, 28 May 2024 10:18:22 +0200 From: Gabriel Goller To: Thomas Lamprecht Message-ID: <20240528081822.db7hgamhdpbcb7k6@luna.proxmox.com> References: <20240522131950.247728-1-g.goller@proxmox.com> <1b388e0c-1239-4f91-9273-c329180ff4ec@proxmox.com> <20240523121008.c6p4eixaatbzwhzl@luna.proxmox.com> <4851498c-3d5d-4b14-8f3b-07190bda83b4@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4851498c-3d5d-4b14-8f3b-07190bda83b4@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.064 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 - Subject: Re: [pbs-devel] [PATCH backup/proxmox-backup 0/4] fix #5463: add optional consent banner before login 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: , Reply-To: Proxmox Backup Server development discussion Cc: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" Ok, you convinced me :) On 23.05.2024 14:42, Thomas Lamprecht wrote: >Am 23/05/2024 um 14:10 schrieb Gabriel Goller: >> On 23.05.2024 11:24, Thomas Lamprecht wrote: >>> Anyhow, fine by me, but I then still would prefer having this saved >>> as structured data with an explicit type so that we can easily extend >>> this with an option for actually enforcing such a consent, if ever >>> requested. >>> >>> Maybe we can even add it as encoded text to an existing config, for PVE >>> the datacenter one would be a good fit, for PMG with also have a cluster >>> wide one IIRC and for PBS we could just add it to the node.cfg (and cache >>> inside the http daemon). >> >> I don't think we will gain much from adding the text in a config file >> here. The config files don't support multi-line values and thus we have to >> escape all the newlines. If we do this, we would have to introduce a ui > >Yes, that's why I wrote "as encoded text" ;-) > >> textfield where the user can edit the consent file, otherwise he would > >Yes, re-using an existing config would allow more easily to expose it on >the UI as we wouldn't have to add new API endpoints managing it, i.e., a >feature. I Agree. >> have to escape all the newlines manually in the node.cfg file (which is >> a PITA). > >For setting it via CLI it would probably best handled as manager CLI >command. We can do that. >> I am also kind of opposed to a ui element because this is quite a niche >> feature and would only clog the interface. > >I do not think the node configuration would get clogged, e.g., on the PBS >UI the Configuration -> Other -> General panel has three rows, and the >rest of that tab panel isn't packed either. Same for PVE's Node -> Options >panel. Either that, or somewhere in Access Control? >Note that in the long run we want to bring every option to the UI sooner >or later. How soon that is depends on mostly from the potential negative >impact, not necessarily how niche that is. > >And sure, looking out for the UI not getting to crowded is a good thing, >but the solution there should be to rework the UI to better lay out all >the options and form fields without overwhelming the users, e.g. by using >a different layout, advanced sections, ... > >> >> I don't think an option to strictly enforcing the consent won't come any >> time soon, as it's quite complicated to implement and is mostly used as >> a legal requirement anyway. > >My thinking is a bit different here, I would not have thought about adding >this before seeing the feature request including its references to >legislature of one of the biggest countries in the world, so as there >are hundreds of countries, lots of them with their own niche case, I'd >rather make this as extensible as possible from the beginning to avoid >having re-doing it later on for every other countries/agency/... niche >use case. > >> >> Another plus would be that VMWare does the same, so a user would just >> have to come the .txt file /etc/proxmox-backup (+ rename it) and would >> be ready to go. > >A reference to how VMWare does would be nice, besides that: >1. copying the message to a text area in the UI or using a CLI tool > to set that is hardly more work. Agree. >2. More importantly, I'd be surprised if these messages are written > on the spot by an admin on the VMWare host directly, i.e., having > no other copy. Normally, those things get drafted by a legal > department, or external counsel, and thus are available from a > better source of truth than some hypervisor hosts config. Yes, you are probably right, this wouldn't mindlessly get copied from a vmware machine to a proxmox one. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel