linux-kernel - Re: [PATCH 00/14] KEYS: Add support for PGP keys and signatures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9pMEJxGzmetDu0Bkf1=fqb+BHGQ3-6NB3hhtRjLWHm1cA@mail.gmail.com>
Date:   Tue, 18 Jan 2022 19:49:23 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     roberto.sassu@...wei.com
Cc:     "dhowells@...hat.com" <dhowells@...hat.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-fscrypt@...r.kernel.org" <linux-fscrypt@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Subject: Re: [PATCH 00/14] KEYS: Add support for PGP keys and signatures

Hi Roberto,

Thanks for your detailed reply.

On Mon, Jan 17, 2022 at 4:21 PM Roberto Sassu <roberto.sassu@...wei.com> 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