Hi Roberto, Thanks for your detailed reply. On Mon, Jan 17, 2022 at 4:21 PM Roberto Sassu <roberto.sassu@xxxxxxxxxx> wrote: > 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. Hm, yea, I see your dilemma. On the one hand, you recognize the problems with what currently exists. On the other hand, you[r organization] hasn't made the transition to something better. So, rather than putting in what might be a lot of work to transition to something better (which includes actually evaluating *what* the better thing would be), you'd prefer to put in a smaller amount of work to make the current thing satisfy some of your needs, even though you recognize its flaws. It seems like this is one of those "short term" vs "long term" investment tradeoffs. I don't have a whole lot _technical_ to say about long term vs short term thinking, but it does strike me that PGP is one of these cases where people have known about the flaws for decades, but the ecosystem keeps being extended because people continue to go with the short term solutions, one by one, and now they've wound up here, at the doorstep of the kernel. Maybe if at some point somebody puts down the foot and says, "the road of short term intentions stops here," there might gradually be impetus toward looking into long term solutions, e.g. viable PGP replacements? Just a thought. > If in the future the transition from PGP to another scheme > occurs, support for PGP keys and signatures can be still > deprecated. Things in the kernel rarely disappear. At best, they become subtly neglected, and then somebody gets bit by some security bug. At worst, we're stuck maintaining a PGP implementation until the end of eternity. On the technical front, though, I had sort of the same thought as Maciej: is there some way that you can unwrap the PGP data in userspace, and re-encode it in ASN.1, and somehow magically account for the various metadata included in the signatures? The devil here might be in the details, and I'm not sure whether it's feasible. But if it is, this would seem to be a much nicer solution. I'm not the hugest fan of having an ASN.1 parser in the kernel either, but it's _already_ there, and if you could somehow piggyback on top of it, that means we'd be able to avoid importing this PGP implementation. Concretely, it looks like the hardest part of this is the fact that pgp_digest_signature seems to hash in some PGP-specific metadata, not just the raw data. Am I reading that right, and that's the case? If so, that might spell trouble. You also mentioned in that other thread the possibility of using a new/custom PGP packet type for this? Is the idea there that you'd come up with something that could be unwrapped into an ASN.1-verifable blob, as a custom extension of PGP that distros could then distribute? Jason
