> From: Kevin Fenzi [mailto:kevin@xxxxxxxxx] > Sent: Tuesday, January 25, 2022 7:30 PM > On Fri, Jan 21, 2022 at 04:08:04PM +0000, Roberto Sassu via devel wrote: > > Hi everyone > > > > (note for the infrastructure mailing list: please check if the changes > > I'm proposing could be tested in the Fedora infrastructure, like Copr) > > copr uses a different signing setup... so probibly won't work there. > > We could perhaps work with you to try and get it in our staging env to > test, but I am not sure how involved that might be. I guess the first > step would be filing a infratructure ticket and explain what you would > need to change/test. Thanks, Kevin. Will do. > So, question for the change owners: > > This is not enabled by default, I assume you wish to enable it for > something, can you expand on what you will use it for and what that > helps you with? > > Also, is there any plan to enable it by default? Is there some way this > could be useful to all our users? or more of our users? > > This change and the DIGLIM change both feel to me like we are spending > time and effort enabling something that only helps a tiny fraction of > our users. Is there some way this could be more generally useful to our > users? I guess not many would use the remote attestation capability offered by DIGLIM (sealing a TPM key to the software running in the machine). The two scenarios in which that could be used are: - web servers or other kind of servers where you, as client, would like the guarantee that your data is processed only if the software running in the server is not compromised - closed networks where you, as network administrator, would like the guarantee that your clients can access those networks only if their software is not compromised Probably, the secure boot functionality at application level is much more appealing, and less invasive. It should have almost zero impact if the users use their system for web browsing or writing. Although it is unlikely to happen, this feature prevents arbitrary execution of software, even by root. The trust anchor will be the kernel, and one would not have to rely on the correct execution of the package manager (and on its verification of the package signature). If the users often make changes on their system, but confined to their environment, DIGLIM could still be helpful, as the damage of running arbitrary software will be limited to the users environment (no arbitrary software execution as root). If the users often make changes on their system, with high privileges, I agree that DIGLIM would simply cause too much overhead for the configuration (every time the users make a change, they have to whitelist their software). Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
