gchristensen changed the topic of #nixos-security to: Vulnerability Roundup Issues: https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+Vulnerability+roundup + https://broken.sh
hmpffff has quit [Quit: nchrrrr…]
<gchristensen> this SKS stuff is bad
gchristensen has quit [Ping timeout: 252 seconds]
<andi-> Yeah :/ such broken infrastructure
gchristensen has joined #nixos-security
<pie_> sks?
<pie_> ah....
<pie_> i never did figure out how you avoid spam in a distributed system
<pie_> the fundamental problem i would guess is that there isnt really anything inherently different from spam and content?
<pie_> on a technical level. (otherwise we wouldnt have spam problems)
<pie_> so it becomes a question of gracefully handling massive data and manually weeding out abuse?
<pie_> and or some sort of rate limiting...
<pie_> well i guess i should just read the purported solutions for pgp
ris has quit [Ping timeout: 260 seconds]
hmpffff has joined #nixos-security
<gchristensen> I think andi- is right, btw, about the on-topic-ness of this channel is worth considering
<gchristensen> I wonder if we should tak out the default keyservers in our packages
<andi-> That basically boils down to: should we give up on keyservers? Is that a community wide consensus (most/all distro)?
<gchristensen> I think we literally have to
<qyliss> what's the context here?
<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…
<qyliss> yeah
<andi-> Didn't eelco sign nix tarball releases?
<MichaelRaskin> Probably
<{^_^}> #63952 (by alyssais, 43 seconds ago, open): gnupg: change default keyserver to non-SKS
hmpffff has quit [Quit: Bye…]
<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)
<ekleog> gchristensen andi- : FWIW, https://keys.openpgp.org/about/news#2019-06-12-launch went out semi-recently
<ekleog> oh it's what q.liss mentionned, sorry
ris has joined #nixos-security
<ris> #63909 still open
<{^_^}> 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
<ekleog> (not sure it's already on archives)
<qyliss> I'm not on the list.
<ekleog> hmm lemme look for archives and hope
<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)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/63964 (by alyssais, 39 seconds ago, open): [19.03] gnupg: change default keyserver to non-SKS
<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!
<qyliss> Irssi CVE btw #63965
<{^_^}> https://github.com/NixOS/nixpkgs/pull/63965 (by alyssais, 36 seconds ago, open): irssi: 1.2.0 -> 1.2.1
<andi-> qyliss: thanks for looking at irssi
<qyliss> Subscribing to oss-security was one of my better decisions
<gchristensen> thank you for doing that, qyliss
<andi-> Yep
<qyliss> Surprised I haven’t seen any GnuPG discussion there, tbh
<andi-> I lack motivation these days :'( remember evenings where I looked at 30 different issues with a good feeling..
<gchristensen> qyliss: ^ be careful. oss-security can be burnoutey
<qyliss> Noted.
<ekleog> (also, don't subscribe to other MLs about security, they bring little more than noise)
<gchristensen> you cannot do everything. not everything will be done. be easy on yourself
<qyliss> oh sure
<gchristensen> it isn't _that_ easy to actually do, I found ... :)
<qyliss> I work best in cycles, I notice. In a week or two I’ll probably go silent on nixpkgs for a bit, and then come back a couple of weeks later.
<qyliss> Trying to design my work life around that too :)
<andi-> I want to have daily and weekly routines around that stuff. Just don't manage to have two similar days..
<ekleog> qyliss samueldr : I have commented with what I think are all the backwards-incompatibilities and trade-offs for the various options on https://github.com/NixOS/nixpkgs/pull/63964#issuecomment-507075222
<qyliss> Thanks ekleog
<qyliss> Three affected now — that another one since earlier?
<ekleog> qyliss: also, fwiw if I look at the graph at https://sks-keyservers.net/status/key_development.php , I think the attack used one key per packet
<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)
<ekleog> (oh also https://sks-keyservers.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367 is another use of the same attack dating back to 2016 though it's only got ~5k signatures, and is IIRC the one I'm refering to in the post)
<ekleog> (scroll a bit and look at the signers to understand)
<qyliss> Heading to sleep. Thanks everyone for your work on this.
<ekleog> 'night :)