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 4605B1FF396 for ; Thu, 23 May 2024 14:09:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9BA711EEA9; Thu, 23 May 2024 14:10:13 +0200 (CEST) Date: Thu, 23 May 2024 14:10:08 +0200 From: Gabriel Goller To: Thomas Lamprecht Message-ID: <20240523121008.c6p4eixaatbzwhzl@luna.proxmox.com> References: <20240522131950.247728-1-g.goller@proxmox.com> <1b388e0c-1239-4f91-9273-c329180ff4ec@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.069 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 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" On 23.05.2024 11:24, Thomas Lamprecht wrote: >Am 23/05/2024 um 09:51 schrieb Dominik Csapak: >> On 5/22/24 17:31, Thomas Lamprecht wrote: >>> This is currently still missing any actual barrier as it's all frontend, >>> shouldn't there be a cookie that is checked on the backend side if a >>> consent.txt exist? If this specific consent type (RMF AC-8 for US gov) >>> doesn't need that, it might be worth to replace the generic text box >>> with a type selection for that, we could always add a "custom" type >>> that takes a generic text and extent that with an option about how >>> strict it should be checked, if we get this now. >> >> when checking https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-8/ >> (not the "official" document, but very close , the original can be downloaded >> in docx form here: >> https://csrc.nist.rip/projects/risk-management/about-rmf/assess-step/assessment-cases-download-page) >> it does not seem to be necessary for any cookie handling >> since it just wants the disclaimer to be displayed before login > >ack, thanks for the links. > >> >>> >>> And how should API calls made using API tokens get handled, should they >>> have a header signalling consent or not? If, should there be a set of >>> standard consents that one can explicitly consent too? As a blanket >>> consent to an unknown text would not be of much use. >> >> >> also it says that this is only for human interaction, so any api >> access etc. is exempt IIUC > > >So pretty much a worthless "keep out" sign [0], can one be even >enterprise ready without those? ;-) > >[0]: https://i.imgur.com/mSHi8.jpeg > >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 textfield where the user can edit the consent file, otherwise he would have to escape all the newlines manually in the node.cfg file (which is a PITA). I am also kind of opposed to a ui element because this is quite a niche feature and would only clog the interface. 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. 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. If we want to add other visual configs such as optional buttons (e.g.: "I Accept", "I Decline") I think we should add the in the txt file like such (or something similar): multi-line text I Agree|I Disagree|Ignore _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel