00:44 <tarcieri> lol

00:44 <tarcieri> everyone's got opinions

06:34 <theartisan> "All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others." -- Douglas Adams

07:00 <kseifried> towel life 4eva!

08:56 <yorickpeterse> morning crypto weeaboos

19:49 <raggi> any of the TUF guys still here?

19:53 <dstufft> don't see any names I recognize

19:53 <dstufft> I saw they posted on rubygems mailing list tho

21:18 <raggi> tarcieri: so, TUF can have multiple root keys, and then do quorum

21:19 <tarcieri> raggi: cool

21:19 <raggi> tarcieri: so we don't necessarily even need to store it in a split vault, we can just issue a list of root keys to key stakeholders, and use that instead

21:20 <raggi> it's more crap to distribute in the client, but much safer overall

21:20 <tarcieri> raggi: what I was describing was for the actual root key, which would be used to manage that "list"

21:20 <raggi> oh, there isn't one

21:20 <raggi> because the roles are split

21:21 <raggi> or at least ,there doesn't have to be

21:21 <raggi> and in fact, we could make one, countersign the group of root keys

21:21 <raggi> and then destroy it completely

21:21 <raggi> without really compromising anything

21:22 <tarcieri> raggi: no danger in keeping it around, especially in split key form

21:22 <tarcieri> raggi: basically that's a key that never comes out except for Extreme Circumstances

21:23 <tarcieri> heh

21:23 <raggi> i guess so

21:23 <raggi> like quorum all being at a conference together

21:23 <raggi> getting held at gunpoint and their root keys forced otu of them

21:23 <raggi> which still relies on them carrying those

21:23 <raggi> which would be... unwise

21:24 <tarcieri> yeah heh

21:57 <raggi> so, do we think that many people / projects would be willing to use dual author signing?

22:14 <geal> raggi: sorry to interrupt, but dual author signing? What is it? How is it implemented?

22:14 <raggi> geal: so a system like tuf has the ability to have many signatures at different roles/levels

22:15 <geal> oh, nice

22:15 <geal> and useful too

22:15 <raggi> geal: and it would essneitally possible for a project to say "all releases for this must have at least 2 of 5 signatures from the following keys in order to be valid"

22:15 <raggi> even before the distribution platform would accept an upload

22:15 <raggi> but i don't know if people would really use that

22:16 <geal> there is a key distribution problem, but if deployed correctly, that makes a very resilient system

22:17 <raggi> no need to distribute, they'd be authorized by higher level metadata

22:18 <geal> ok

22:27 <dstufft> raggi: RubyGems still thinking of using TUF then?

22:28 <raggi> dstufft: i'm still looking into it

22:28 <raggi> it's the most complete thing to go past so far

23:45 <raggi> dstufft: ssl and irrevocable signing essentially change nothing about the incident response practices from where they are today, by contrast, most incident response in a tuf design is largely automated, and that's acutally a real improvement

23:46 <raggi> i'm also quite interested in the idea of publisher selectable levels of end to end trust (the signature threshold for releases)

23:47 <raggi> the system is larger, and will require a lot more to write, but, it's also a significant step forward from most other deployed solutions today