> From: Jason A. Donenfeld [mailto:Jason@xxxxxxxxx] > Sent: Monday, January 17, 2022 3:35 PM > Hi, > > While it looks like you put a lot of work into this patchset, I think > the general idea of adding PGP *to the kernel* is a pretty daunting > proposition. The general consensus in the crypto engineering world is > that PGP ought to be on its way out. We definitely don't want to > perpetuate this project-on-life-support into the permanence of kernel > code. Some quick Google searches will reveal a litany of blog posts to > the tune of, "why oh why are people still using this?" Here's one from > 2019: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I > think these are arguments to take seriously. And even if you disagree > with some parts, you may want to consider whether the remaining parts > warrant a bit of pause before adding this to the kernel and perpetuating > PGP's design further. Hi Jason thanks a lot for the additional information. They could make people more aware of the risks so that they transition to more secure schemes. The problem is that I don't see that transition coming soon. Transition from PGP to another scheme would require Linux distribution vendors to do an huge amount of work. It could probably take years before that transition occurs. More specifically, the first task would be to modify how RPMs are signed (and thus how they are verified). The second task would be to have a different way to certify the public key. Lastly, Linux distribution vendors would have to change their building infrastructure to use the new certified key, a new version of the rpm package manager which takes as input the new key, produces a different type of signature and embeds it in the RPM header. In this discussion: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/ people were concerned about the lifecycle of the secondary key used for fsverity signatures. Likely, completely replacing the key infrastructure would raise even bigger concerns. The aim of this patch set is to make some security features available in a short time, by significantly reducing the burden of Linux distribution vendors for managing those security features. I mentioned fsverity, but my primary use case would be for DIGLIM (extract reference values for file digests from RPM headers and use them for IMA measurement or appraisal). The main advantage of this patch set, at least for DIGLIM, is that it completely removes the need of changing the building infrastructure. To show the DIGLIM benefits, I retrofitted two already released Linux distributions (Fedora 34 and openSUSE Leap 15.3) with DIGLIM and the necessary changes in IMA, so that they prevent the execution of binaries and shared libraries which were not released by the distribution (the mechanism is completely configurable by the user to trust his binaries, if he wishes to). If you are interested, here is the link of the demo I developed: https://lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@xxxxxxxxxx/ If in the future the transition from PGP to another scheme occurs, support for PGP keys and signatures can be still deprecated. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > If you're looking for a simple signature mechanism to replace the use of > X.509 and all of that infrastructure, may I suggest just coming up with > something simple using ed25519, similar to signify or minisign? Very > minimal code in the kernel, in userspace, and very few moving parts to > break. > > Jason
