<gchristensen>
anybody could destroy, say, debian's pcakage signing key without a moments warning
<MichaelRaskin>
Where destroying means «if you use Synchronised Key Servers, importing the key overloads your GPG installation»
<gchristensen>
SKS is an existential threat against any key of any value
tokudan has joined #nixos-security
<qyliss>
What do we think about keys.openpgp.org
<gchristensen>
is it SKS?
<gchristensen>
if it is SKS, it is broken
<MichaelRaskin>
No, it is the new version that puts some limits
<qyliss>
no
<qyliss>
It mentions it in that article
<gchristensen>
good :)
<qyliss>
keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack.
<gchristensen>
if we're talking about switching to it for everybody, we should coordinate with them beforehand
<gchristensen>
they might not be ready for a distro to switch over
<qyliss>
They're in #hagrid apparently
<qyliss>
Maybe a couple of us should join and talk to them.
<gchristensen>
I just joined, but am leaving for a few hours in about 30min
<gchristensen>
FYI I'm going to try PMing with somebody there, somewhat unrelated.
<gchristensen>
thank you for leading the discussion, qyliss!
<qyliss>
my pleasure :)
spacekookie has joined #nixos-security
<qyliss>
We don't use GPG for anything in Nix, like verifying packages, right?
<gchristensen>
we don't
<qyliss>
cool
<gchristensen>
yes :)
<MichaelRaskin>
Well using GPG with preseeded public key list wouldn't be a problem
<qyliss>
Provided nobody ever ran refresh-keys
<MichaelRaskin>
I assume in-Nix use wouldn't even provide such an option
<qyliss>
Wonder if we should do anything about the sks NixOS module
<qyliss>
I guess there's not a lot we could do... if somebody's chosen to run a server that's their issue I suppose
<MichaelRaskin>
The server itself doesn't even suffer that much…
<pie_>
we do use it for the installer script thought
<pie_>
*though
<ekleog>
samueldr: there already is check-meta.nix, which does ad-hoc type checking for meta, in addition to the (iirc, made by profpatsch) type refactor that's pending somewhere
<samueldr>
(that probably should have been moved to another channel since yesterday)
<{^_^}>
https://github.com/NixOS/nixpkgs/pull/63909 (by risicle, 1 day ago, open): [r19.03] libvirt: add patches for CVE-2019-10132, CVE-2019-10161, CVE-2019-10166, CVE-2019-10167 & CVE-2019-10168
<qyliss>
Just merged the keyserver change.
<gchristensen>
it looked like there was still uncertainty that thepatch was complete, was that resolved?
<qyliss>
gchristensen: I think so!
<gchristensen>
cool
<gchristensen>
maybe double-check before backporting? :)
<qyliss>
Double check with dkg, you mean?
<gchristensen>
yea
<gchristensen>
actually I take it back
<gchristensen>
if you think it is good, I trust you
<gchristensen>
I don't need to meddle
<qyliss>
ris: merged
<qyliss>
I'm pretty sure it's good, but your concern is noted.
<qyliss>
It worked even without the GnuPG patch. Just made a related bug in GnuPG a bit more apparent.
<ekleog>
I'm not sure we should backport this
<ekleog>
It is a quite big retrocompatibility hazard
<MichaelRaskin>
The problem is that _each_ possible action or inaction is a retrocompatibility hazard
<ekleog>
IMO changing the default keyserver should deserve release notes
<gchristensen>
they're holding a hand grenade right now
<MichaelRaskin>
But maybe seeing how it develops might help
<ekleog>
no, I mean it is non-retrocompatible
<ekleog>
like, definitely is
<ekleog>
uids are no longer fetched, uid revocations no longer exist
<ekleog>
TPSes are not getting fetched either
<ekleog>
the question is how bad is the retrocompatibility breakage vs. how bad is the security flaw
<MichaelRaskin>
They have held the hand grenade for a long time…
<MichaelRaskin>
Now someone has stolen the pin
<ekleog>
and IMO the security flaw is not bad, that issue has been known for literally years
<ekleog>
the only thing is it's been exploited against 3 people
<gchristensen>
I can appreciate that perspective
<MichaelRaskin>
It's the question whether this comes into fashion
<ekleog>
not worth doing something that might be equivalent to bumping the default rust edition to 2018 for everyone, IMO
<ekleog>
(definitely worth a nix security advisory, OTOH, with instructions for how to easily switch to a patched gnupg)
<ekleog>
s/definitely/might be/
<MichaelRaskin>
Well, if you issue an advisory, editing GnuPG config seems a more natural mitigation than patching
<MichaelRaskin>
Yes, there are cases where semi-manual patching is preferrable
<qyliss>
You don't even need to switch to a patched gnupg
<qyliss>
You just add 'keyserver hkps://whatever-the-default-used-to-be' to your config.
<ekleog>
The issue is, I guess, for systems where there is one admin for several users, and the admin is not supposed to go into the users' home dirs
<qyliss>
I'm strongly in favour of backporting, though. If we don't, people can end up with bricked GnuPG installations. If we do, they lose a small amount of functionality.
<ekleog>
the issue is not functionality human users lose, it's scripts that get broken
<MichaelRaskin>
Well, bricked is a strong word
<ekleog>
(also, it's possible to unbrick the issue, eg. by `rm ~/.gnupg/pubring.kbx` for the most violent easy solution)
<qyliss>
Well sure, but then you lose data
<MichaelRaskin>
That's information loss; but people say just nuking three keys from CLI works
<ekleog>
right, that's why I stated “most violent”, there are more complex solutions that get things to work :)
<qyliss>
I'd rather things didn't break in the first place, although I appreciate that fixing this introduces its own breakage
<ekleog>
also, some people said adding `keyserver-options import-clean` might be a solution for the “bricking” issue
<ekleog>
though it does make refresh-keys awfully slow when refreshing an attacked key
<MichaelRaskin>
On the other hand, BGP is broken for its entire history, and the breakage has caused damage for decades, and still…
<qyliss>
I guess, if it's a choice between providing a known-unsafe feature, and not providing that feature, I'd prefer the latter.
<MichaelRaskin>
I wonder if there will be the second stage where import-clean stops being enough
<qyliss>
It shouldn't be possible (by default) for people to shoot themselves in the foot.
<ekleog>
well, it's not like it's an RCE in gnupg
<qyliss>
Sure
<ekleog>
it's a DoS, and the fix is just another kind of DoS
<ekleog>
keeping the already-existing DoS for stable sounds like the less bad option
<ekleog>
(and/or add the import-clean keyserver option for stable, as it's a much smaller issue than switching to keys.openpgp.org)
<qyliss>
What does import-clean do?
<ekleog>
it ignores TPSes that are not from keys in the keyring
<ekleog>
third-party signatures*
<ekleog>
takes ~half an hour to import attacked keys, though
<qyliss>
I don't know that that's an effective mitigation
<qyliss>
What if somebody has auto-key-retrieve? (As I did, before today)
<ekleog>
also see Message-ID: <20190630185603.GA17531@fripost.org> To: gnupg-users@gnupg.org Date: Sun, 30 Jun 2019 20:56:03 +0200 Subject: Re: SKS Keyserver Network Under Attack
<qyliss>
Yeah, I think that's a distraction. We can't rely on users to curate their keyrings, when prior to now there's been no reason to do so.
<ekleog>
what I mean is that setting that as a default works as a mitigation
<qyliss>
in some cases
<ekleog>
less efficient than switching to keys.openpgp.org, but also much less destructive
<ekleog>
in which cases does it not work?
<qyliss>
When you have auto-key-retrieve and import the attacker's key
<ekleog>
it wouldn't fail
<qyliss>
No, but it would import the poisoned key along with all signatures
<ekleog>
auto-key-retrieve doesn't (afaik) recursively pull all the signers
<qyliss>
no, but it's not difficult to get somebody with auto-key-retrieve to import your key
<ekleog>
attacker would need to get you to import like 150k keys
<qyliss>
if you do that first, then get them to refresh their keyring, you've poisoned them
<ekleog>
I mean, at that point you have bigger issues than the gnupg dos
<qyliss>
Why couldn't they spam somebody's key with 150k signatures from the same key?
<qyliss>
they don't have to be different.
<ekleog>
hmm right
<qyliss>
I don't think that's right.
<ekleog>
so yup it's a mitigation that can be bypassed
<qyliss>
If I make a git repo with a commit signed by me on top of a commit signed by dkg, and you clone that repo and run 'git log --show-signatures', if you have auto-key-retrieve set you're owned, with or without import-clea
<ekleog>
that said it's still a mitigation I (personally) would feel OK backporting, while switching to keys.openpgp.org definitely is not :) (not that my opinion is that decisive, though)
<ekleog>
like, to me the keys.openpgp.net doesn't meet the safety gain vs. retrocompatibility breakage barrier
<qyliss>
I think I might ask the release managers to make the call.
<ekleog>
but the question should be for release managers to decide anywa
<qyliss>
Yeah.
<ekleog>
haha
<qyliss>
For right now, I'm at least going to backport upgrading gnupg to the latest patch release in 19.03
<qyliss>
2.2.13 -> 2.2.16
<qyliss>
because that should have happened by now anyway
<qyliss>
(And is a prereq for the patch we have in unstable now)
<qyliss>
Then I'll put up a PR and ask the release managers to make the call.
<ekleog>
cc sphalerite samueldr for that question
<qyliss>
You can comment on the PR with your objections.
<ekleog>
oh well doing that discussion on the PR works too I guess
<ekleog>
if you can ping me on the PR I'll comment over there :)
<ekleog>
(btw, thank you for handling all the patching!)
<qyliss>
You are very welcome :)
<qyliss>
Very impressed with upstream on this one.
<qyliss>
(both on the side of gnupg and keys.openpgp.org)
<samueldr>
I'm not sure I understand the repercussions enough to judge
<qyliss>
samueldr: I've tried to summarise it in the PR I just opened (#63964)
<samueldr>
this only changes the default keyserver to one that will not trasmit the DoS, AFAIUI, right?
<samueldr>
transmit*
<samueldr>
and well, one that has fewer features
<samueldr>
I believe we need a new section to release notes, to publish incompatible/notable changes made post-release
<samueldr>
not sure Errata fits the bill though
<samueldr>
(for a name)
<gchristensen>
we have no good mechanism (human-mechanism, policy-mechanism, code-mechanism) for such post-release notices
<samueldr>
that's right
<qyliss>
I agree we need something like that.
<qyliss>
IIRC home manager has something like it? (I don't use it myself but think I've seen that.)
<qyliss>
samueldr: your understanding is correct.
<qyliss>
It also includes a proposed upstream patch to prevent a CA bundled with GnuPG being able to sign for that server.
<samueldr>
the missing features, are they features that would be used by people not already fixing up their config?
<qyliss>
ekleog: ^
<ekleog>
Well, the first big missing feature is that keys.openpgp.org has like 2k keys, while the old keyservers have like a few hundred thousands at least
<qyliss>
It's difficult to say, I think.
<ekleog>
everyone who hasn't already re-uploaded their key to keys.openpgp.org and done the email challenge isn't going to have their key on it
<samueldr>
ah, so not only missing features, but a different content base
<ekleog>
so it likely breaks every tutorial about GnuPG that includes a `--recv-key`
<samueldr>
now *that* is more of an issue
<samueldr>
I assumed it was the same content, but from a different server software
<ekleog>
There's also no fetching keys by anything else than fingerprint or verified email, so you can't just look for “Leo Gaspard” and fetch whatever comes up
<qyliss>
(not that you should ever have been doing that anyway)
<ekleog>
(I'm not sure whether short UIDs work either, for eg. `gpg --recv-key 0x12345678` -- it's all things that are known-unsafe but done in practice)
<ekleog>
well I've been doing that and then validating via WoT for friends
<qyliss>
oh hmm that's true
<ekleog>
It doesn't provide third-party signatures, meaning WoT validation becomes impossible
<qyliss>
yet another way to get my malicious key into a keychain ;)
<ekleog>
heh, there are a thousand ways of doing that for one malicious key
<ekleog>
actually sks-keyservers have 6 *million* keys
<ekleog>
including ~500k added in the last 6 months
<ekleog>
Actually nvm the public key material has been imported from sks-keyservers at some point (cc samueldr)
<ekleog>
just not the latest ones and not fetchable except by fingerprint for most
<qyliss>
So if you've already imported a key, it should refresh fine, I assume?
<ekleog>
yup
<ekleog>
oh btw for “inserting a malicious key in your keyring”, a malicious keyserver can just return two keys when requested one and gnupg will happily import both (and at some time it also imported private keys, which could have… fun consequences)
<qyliss>
wow
<andi->
I am feeling sick.
<MichaelRaskin>
You were supposed to become sick when you learned what keysigning parties are!
<ekleog>
no it's the same, kristian hasn't been mentioned at lots of places
<qyliss>
Sure, but no reason for future attacks to
<qyliss>
Ah
<ekleog>
well, I don't know which packets exactly take gnupg time to process, so maybe it's actually a requirement of the attack, idk
<ekleog>
(like, supposedly gnupg would check only the latest signature anyway)
<ekleog>
still, a targeted attack would likely be able to run around import-clean, but I think it'd likely also be able to run around the keyserver change (eg. using WKD as a way to submit poisoned keys)