havenn has quit [Remote host closed the connection]
Hamled has quit [Ping timeout: 252 seconds]
craigmcnamara has joined #rubygems-trust
craigmcnamara has quit [Quit: craigmcnamara]
craigmcnamara has joined #rubygems-trust
<kseifried>
you can't really control how people store their keys unless you control their computers. Remember the Fedora SSH key change stuff? they forced people to change SSH keys to prevent exploitation of existing accounts in case keys had leaked. Problem was they made it worse for really secure people using things like cryptokeys (hardware token) to store their ssh keys since they now had to stop using a hardware secured ssh key and create a normal
<kseifried>
one on a workstation, so be careful with what you try to enforce/do
Perceptes has joined #rubygems-trust
<kseifried>
also if you're doing anything crypto related and even thinking of using DES/3DES/MD5/SHA1 you're doing it wrong :P
craigmcnamara has quit [Quit: craigmcnamara]
<raz>
rot13 is also said to be insecure, but we're applying it twice so i think we're fine
<dstufft>
kseifried: I'd like you to find the XSS on my static only site with no js ;)
<dstufft>
(I know what you mean though!)
<kseifried>
dstufft: do you use apache with modules/
<kseifried>
some have https response splitting maybe, bingo
<dstufft>
nah
<kseifried>
http rather
<dstufft>
Haven't used apache in awhile, tend to use nginx these days
<kseifried>
yeah it's had a few issues
<raz>
kseifried: yup that's what i use
<dstufft>
Although i was playing with apache for SSL termination as threaded work better than evented for SSL term
<raz>
the only time i touch apache these days is to try out some tool that provides a config snippet for it
<raz>
anything productions goes on nginx
* kseifried
is old. he used ncsa web server :P
<raz>
well, i've used fnord for a while
<raz>
but i guess that still makes you older than me ;)
<kseifried>
I just roll with it now. I still use ifconfig/route instead of "ip4" =)
<raz>
me too
<raz>
i find the syntax of those ip* commands terrible
<kseifried>
and much to the horror of samkottler I don't use gmail keybord shortcuts =)
<raz>
might be just intertia..
<raz>
-t
<kseifried>
well I have limited time to learn, and nearly infinite pile to learn
<kseifried>
I stopped buying books 4 months ago
<kseifried>
realized I have 100+ I bought and never read
<raz>
i don't read tech books at all
<raz>
imho it's an anachronism to read about the internet on a piece of paper ;)
<kseifried>
by definition they are kind of 2005, out of date before they even get written, let alone printed
<kseifried>
yah
<raz>
yea, i actually bought that DNS book a while ago, and sort of cross-read it (on the kindle)
<raz>
but it's kind of hard to find the interesting parts without easy scrolling and grep ;)
<kseifried>
yeah as references paper is about the worst
<raz>
i remember the only tech book i ever really read was "java servlets" from o'reilly :)
<raz>
well and taocp but that doesn't really count anyhow
<kseifried>
is there a list of the main ruby peoples and their twitter names?
<drbrain>
kseifried: I don't think so
* kseifried
is old, I need a phone book and a rotary phone!
<raz>
i think most of them still are in japan
<raz>
so you might also need a translator ;)
<kseifried>
nah, I will simply use the international language of interpretive dance
<raz>
lol
DonOtreply has quit [Quit: Computer has gone to sleep.]
<kseifried>
I think I simply need to embrace anonymous mechanical turks and start out sourcing parts of my life
<kseifried>
when did google add the option to email/sms you about suspicious login attempts? interesting
<raggi>
quite a while ago i think
<raggi>
there's a lot of 2fa support too
<kseifried>
yah been using that for ages
<raz>
google keeps nagging me about my phone number
<raggi>
which reminds me, i need to order some more yubi's
<raz>
they're not getting it
<raggi>
raz: lol
<raz>
they're a royal pain in the ass, i wish they'd just shrink back to being a search engine
<raz>
but that's..um.. a discussion for a different channel ;)
<kseifried>
I want my self driving car so I cn spend more time on google
<raggi>
the products are opt-in
<kseifried>
I suspect that is the long term plan, automate life so more time for google
sn0wb1rd has quit [Quit: I will be right back]
<raggi>
you can use search without an account
<kseifried>
raggi, : not always, I have to sign in to view a doc and suddenly I'm being tracked/etc
<raggi>
kseifried: for some quite well defined and well documented notion of tracked
<kseifried>
same for youtube, you must sign in to view this video which has a swear word in it, etc
<raggi>
kseifried: you can blame lawyers for the latter
* kseifried
notes the only good content anymore has warnings on it :P
<kseifried>
I was watching tv years ago, some rerun of a show I watched when I was like 6 and it had the whole "viewer discretion is advised" thing
<raz>
yea.. except they annoy you with "plus" when someone wants you to join a hangout.. and in general using multiple accounts in parallel (i have >4 main ones) is just a royal pain
<kseifried>
raz: easy, multiple isntances of chrome using different dirs for storage/settings
<raggi>
yeah, chrome profiles ftw
<raz>
kseifried: yeh sort of.. i tend to use firefox/opera/chrome in parallel.. ;)
<raggi>
raz: try out chrome profiles
<raggi>
they're excellent
<raz>
yeh, might look into it
<raz>
oh and don't get me started on "groups" :P
<raggi>
i'm just grateful for so much free shit
<raz>
well, sort of. the problem is when people start using it because it's free and despite it being terrible.
<kseifried>
I'm just grateful for working search.
<raz>
kseifried++
<raz>
although they're constantly on the verge of ruining even that
<kseifried>
I find for super technical bits it works well
<kseifried>
for general shit I always end up on wikipedia anyways
<raz>
always have to disable their popover garbage every time i install a new browser (greasemonkey to the rescue)
<raz>
and their image search gets more ridiculous every time i use it
<raggi>
raz: again, lawyers have a lot to do with that
<raggi>
"you must present the images in context" blah blah
<raz>
raggi: erm.. i doubt lawyers demanded to use stupid javascript popout, sliding, whatever nonsense
<kseifried>
google has popups?
<raz>
well, you're never quite sure where the div is going to pop up ;)
<raggi>
er
<raggi>
wtf
<raggi>
new version of image search just deployed
* raggi
checks he's signed into right profile
<raggi>
yep
<raz>
same for me as last time
* raggi
double checks
<raz>
awesome sliding effect with buttons as far away from the cursor as possible
<raggi>
i must not leak confidential build
<kseifried>
how does google do it? "man with a guitar scuba diving" works.
<raggi>
kseifried: fucking magnets
<raz>
i'd like if google gave me a pref to "use stylsheet from 1998"
<raz>
then i wouldn't have to futz with userscripts every time i install a new browser :P
<raggi>
raz: see bottom of page
<raggi>
"switch to basic version"
<raz>
don't have that link here
<raggi>
on image search?
<raz>
that has no "bottom" for me
<raz>
it's infinite scroll...
<raz>
(don't.. get.. me.. started..)
<raggi>
it does, use the scrollbar
<raggi>
oh, i know
<raggi>
i hate infinite scroll
<raz>
well, that looks a bit better
<raz>
how do i make it remember it?
<raggi>
hmm, don't know
<raggi>
use the other link down there "leave feedback"
<raz>
lol
<raz>
i tried that a few times in the 90s
<raz>
nowadays i just talk to my fridge when i feel lonely
<raggi>
what, bitching about it here, i'm not goign to go speak to the product owner for you
<raggi>
haha
<raz>
it's not like anyone or anything ever responds
<whitequark>
raz: it's just wired to /dev/null
<whitequark>
you know, angry users demand feedback
<raz>
whitequark: yep, that seems most likely
<raggi>
i can tell you that is not wired to /dev/null
<whitequark>
</joke>
<kseifried>
they probably have some sort of mega cluster that handles /dev/null in a globally distributed fashion at like 3 terabits/second
<tarcieri>
raggi: it's kind of funny, the main piece of software I've been meaning to write is something that actually calculates predictions from a web of trust
<tarcieri>
raggi: people here want to lecture me on the topic, I'm just like: go read every fucking paper I link from the Cryptosphere on the viability of web-of-trust systems and get back to me
<kseifried>
tarcieri: the kids mean well
<tarcieri>
I'm sure they do
<kseifried>
that's all I think when I get frustrated
<raggi>
tarcieri: i'm thinking about buying some drums
<tarcieri>
nice
* tarcieri
needs a larger synthesizer than the microkorg
<tarcieri>
heh
<raggi>
so i can give them out
<raggi>
and tell people
<raggi>
"organize yourselves in a big circle"
<tarcieri>
lol
<raggi>
(that's intentially excessively mean)
<tarcieri>
I've been posting to p2p-hackers for like... 7 years
<tarcieri>
nobody there takes WoT seriously
<tarcieri>
the sybil problem, yes, start there
<tarcieri>
but no we can address that because practically anybody who's anybody comes to rubyconf/railsconf and we can totally have key-swapping parties there
<tarcieri>
and everything will work out great
<kseifried>
hahaha trust. people are wired up to blindly trust other people which, thankfully, usually works.
<raggi>
yep, usually
<raggi>
but equally, those same people are also the ones who were in teh channels telling us the world was ending, everything was pwnd, and that we had highly skilled professional level attackers
<raggi>
which if that was the case, WoT poisoning would be totally done
<kseifried>
I did hear one good idea for web of trust
<tarcieri>
here's my good idea for web of trust: use singular value decomposition to detect interaction patterns similar to your own
<kseifried>
a local teacher, clued in, pointed out that high school teachers were ideal, they get to know the kids, then at graduation do a key signing/etc, so everyone entering adult hood would have credentials
<tarcieri>
I don't think that applies to RubyGems
<raggi>
tarcieri: doens't your company teach new rubyists at a rate of 100s per year
<raggi>
:-P
<tarcieri>
haha, not quite that many, but yeah
<tarcieri>
I think there were like 50 people in Hungry Academy
<raggi>
yeah
<raggi>
we thought about doing that
<raggi>
but i couldn't find a teacher in a reasonable amount of time
<raggi>
then you guys did it, and i was like "this will get a bad repsonse now"
<tarcieri>
Jeff Casimir did a great job
<raggi>
i heard good things
<raggi>
and it's a very good way to overcome the competition problem
<raggi>
twitters strategy was pretty good too, but i think they fell into that, and they also had a loud voice
<raggi>
(that is, publicly moving to scala, and dragging a huge number of people with them, then hiring half of the survivors)
<tarcieri>
heh
<tarcieri>
we use Scala because the JVM is better than Ruby
<tarcieri>
o_O
<raggi>
confirm
<raggi>
hehe
<raggi>
i put "prefer jruby" in some style guides the other day
<tarcieri>
don't get me wrong, Scala seems... kind of cool?
<raggi>
and oh fucking boy did that get a loud response
<tarcieri>
I checked it out in 2007
<tarcieri>
and it was very bleeding edge
<raggi>
scala seems complicated
<tarcieri>
perhaps it's better now
<tarcieri>
and yeah, that's the main problem
<tarcieri>
Scala is a conceptual hodgepodge
<tarcieri>
which makes it... overcomplicated
<tarcieri>
C++ 2.0
<tarcieri>
heh
<raggi>
it's the same reason i don't want ot use ... exactly, c++
<raggi>
2.0?
<raggi>
dude
<raggi>
C++ started complicated
<tarcieri>
lulz
<raggi>
it was over in the beginning
<raggi>
well, then there's rust
<tarcieri>
I kind of want to check out Rust
<tarcieri>
but not really
<raggi>
dude
<raggi>
the tutorial
<raggi>
is the same size as the go spec
<tarcieri>
rofl
<raggi>
tutorial <-> spec
<raggi>
wot
<raggi>
i'd rather learn ocaml
<raggi>
or get good at haskell
<raggi>
just for the variety
<raggi>
if i'm gunna do something mildly hard
<tarcieri>
heh
<raggi>
jvm wise, clojure seems quite nice
<tarcieri>
yeah I liked Clojure, kind of
<raggi>
i haven't used it enough to really have a strong opinion
<raggi>
but i appreciate it being small and simple
<tarcieri>
I used it quite a bit at Strobe
<raggi>
i could actually read code that carl sent over
<tarcieri>
seemed cool but what can I say, I just don't like Lisp
<raggi>
i can understand that
<raggi>
there's always mirah
<raggi>
hehe
<tarcieri>
I like a lot of stuff about Mirah
<tarcieri>
trying to actually use it is o_O
<tarcieri>
it's one of those languages that shows you don't need lisp to have macros
<tarcieri>
you just need quote/unquote
<raggi>
so that tweet
<tarcieri>
which one?
<raggi>
"six degrees of separation doesn't work when people live alone in bunkers"
<tarcieri>
haha
<tarcieri>
nice
<tarcieri>
didn't see that
<kseifried>
how do you guys find time to read/tweet so much?
<tarcieri>
I dunno, I tweet when I'm commuting our out and about and bored
<raggi>
i tweet when i'm angry
<tarcieri>
raggi: oh there's the tweet
<tarcieri>
haha
<tarcieri>
raggi: that too
<raggi>
i don't know why people follow me
<tarcieri>
lol
<kseifried>
what's your twitter accounts?
<raggi>
raggi
<tarcieri>
@bascule
<raggi>
:)
<raggi>
oh, and @roflscaletips
<raggi>
lol
<tarcieri>
lulz
<whitequark>
raggi: oh that's who is behind that account
<raggi>
whitequark: who?
* tarcieri
too
<tarcieri>
lol
<whitequark>
i always wondered
<raggi>
whitequark: i didn't make it
<whitequark>
raggi: hm
<raggi>
tarcieri: did you see the markov thing applied to roflscaletips?
<whitequark>
you totally should've done that
<tarcieri>
raggi: lol no
<raggi>
it's fucking awesome
<raggi>
now i have to remember what that was called
<raggi>
what is my next tweet, or somethign
<raggi>
"Or just by null devices. use threads is roflscale, and Fibers and rewrite it roflscale?"
<raggi>
interesting idea for a vector though, actually
<kseifried>
but I still take the fork away from him
<raggi>
instead of adding vectors
<raggi>
just deliberately ignore them
<raggi>
tarcieri: please tell me you don't want me to open that code base
<tarcieri>
rofl
<tarcieri>
check the date bro
<raggi>
the only date i see is the plea for assistance
<tarcieri>
8/19/2008
<raggi>
oh, there it is
<raggi>
haha
<raggi>
wait, wut
<raggi>
lazy load pwn'd
<kseifried>
ok sleep time
havenn has quit [Remote host closed the connection]
jstr has joined #rubygems-trust
<jstr>
Wow, there are a lot of people in here now. Hi all :)
mattski has quit [Quit: This computer has gone to sleep]
jstr has quit [Quit: sleep]
mattski has joined #rubygems-trust
<theartisan>
kseifried: the use of short key id was based on not wanting huge filenames and that use collision might happen but statistically with 2-3 people are signing each gem its not going to be a problem
<theartisan>
alternative is just make it random
<theartisan>
there are now 4 seperate proposals on the github issues site, can we get some comments going in each of them
alexmreis has joined #rubygems-trust
alexmreis has quit [Read error: Connection reset by peer]
alexmreis_ has joined #rubygems-trust
workmad3 has joined #rubygems-trust
alexmreis has joined #rubygems-trust
alexmreis_ has quit [Ping timeout: 245 seconds]
workmad3 has quit [Ping timeout: 255 seconds]
workmad3 has joined #rubygems-trust
jfelchner has quit [Ping timeout: 264 seconds]
jfelchner has joined #rubygems-trust
workmad3 has quit [Ping timeout: 260 seconds]
mattski has quit [Quit: This computer has gone to sleep]
Perceptes has quit [Quit: Leaving.]
workmad3 has joined #rubygems-trust
workmad3 has quit [Ping timeout: 255 seconds]
havenn has joined #rubygems-trust
workmad3 has joined #rubygems-trust
havenn has quit [Remote host closed the connection]
havenn has joined #rubygems-trust
workmad3 has quit [Ping timeout: 244 seconds]
<kseifried>
theartisan, : 50,000 gems = lots of keys uploaded to the system potentially
<raz>
kseifried: i think collisions happen at quite a different order of magnitude ;)
<raz>
however, you are right, for actual validation we should obviously not rely on the fingerprint
<raz>
*should* rely at least on the fingerprint, not the key-id
<raz>
(i hate when i type the opposite of what i mean :/)
<raz>
one more time: you are right, we *should* use the fingerprint, *not* the keyid.
<kseifried>
not if a bad guy starts uploading keys with intent to cause problems
<kseifried>
raz: to many security systems assume people will play nicely ;P
<raz>
not sure which model we're discussing atm, but afaik a collision attack would require the attacker to generate a key with a specific fingerprint
<kseifried>
"we put an expensive lock on the door" "what if they kick it down?" "why would someone want to damage the door?" "nrrrghhh" =)
<dstufft>
lolz
<dstufft>
but I like my door undamaged D:
<raz>
kseifried: well, tbh, that's my thought about the proposals that explain how to do lots of complicated CA stuff - and then just trust the repo-key by default ;)
<kseifried>
yah
<raz>
that's a bit like, let's build this really expensive, bullet-proof iron door
<raz>
and then leave it open
<dstufft>
security is hard lets go shopping
<kseifried>
actually. yes.
* kseifried
needs some stuff.
* kseifried
has to go to IKEA though... hnnnnn... maybe next week
<dstufft>
yea I need to hit up an IKEA
<dstufft>
also I should be painting my daughters room
<dstufft>
right now
<dstufft>
but ugh
<dstufft>
:(
<raz>
can't the daughter do that herself? :P
* dstufft
would much rather play with using git as a datastore for package metadata
<raz>
emancipation!
<dstufft>
raz: heh, Normally i'd say yes but a 12 year old w/ asthama + paint fumes != a good time
<raz>
aw yes, true that
<dstufft>
suppose I'll go do that :/
<raz>
have fun :)
* raz
could imagine worse jobs, painting is fun
<havenn>
Anyone know if there are plans in motion yet for a CA?
<Antiarc>
I've proof-of-concepted it, but I'm waiting on feedback from the project teams before doing any real work on it.
<Antiarc>
No sense in pursuing it if they people who have to bless it don't like it.
<havenn>
Antiarc: nice
<Antiarc>
Given that all it would be is a tool that signs pubkeys with a privkey, it's not exactly complex :P
<raggi>
so in the goals under overview
<raggi>
has anyone tried to define "insecure download"
<raggi>
under bonus goals, we also need to define "gem owner"
<raggi>
and "gem"
<kseifried>
amen brother
<raz>
i think the latter two are fairly easy to define (almost self-evident)
<raz>
the first one seems worth writing a few paragraphs about :)
<raggi>
"gem owner" could mean a person, a project, a specific entity at a specific version or a specific time, or even a user account on rubygems.org or a user account on rubyforge or a user account on github
<raggi>
it is very far from well defined
<raggi>
it may or may not have a relationship with copyright, also
<raz>
hm. i would simply define it as "individual who created the gem-file"
<raz>
or "entity"
<raggi>
so when you say gem file
<raz>
it might be better to speak in terms of signing keys instead of people
<raggi>
you mean the specific version, and just that version
<Antiarc>
In my mental model, "gem owner" is [people authorized to sign the gem per the trust history] & [people authorized to distribute the gem on a given platform]
<raggi>
raz: signing keys are not part of the goals, they might be /a method/ to get there
<raz>
raggi: true, you are right
<raz>
Antiarc: that definition also seems to hinge on impl specifics
<raggi>
Antiarc: authorized is interesting to bring in
<raggi>
Antiarc: normally authorization requires two parties, what is the other entity?
<raz>
for me "gem owner" intuitively seems to carry the right connotation though. doesn't it pretty much imply "the guy who legitimately created this gem"?
<Antiarc>
raggi: The trust history and whatever the distribution platform's authorization mechanism is.
<raz>
where "guy" can mean a lot of things ;)
<Antiarc>
raz: No, because an attacker can legitimately create a gem.
<raggi>
Antiarc: ok, so a single distribution server/cluster
<raz>
Antiarc: hm, i wouldn't call an attacker "gem owner" i think.
<raz>
he can own *his* gems but not take ownership over others (well he might, but that doesn't make him the legit owner)
<Antiarc>
raz: But they would be if they're "the guy who legitimately created this gem", since creating a compromised gem is just a matter of modifying the gem, signing it, and uploadnig it.
<Antiarc>
Insofar as the system can tell, that is.
<raggi>
raz: "the guy who created the gem" is weak
<raggi>
raz: think of the json gem, or _why
<raz>
hm. "the guy who *first* created a gem of a particular name"?
<kseifried>
more correct: "the guy who first uploaded the gem" =)
<raggi>
maybe, maybe not
<Antiarc>
And now that _why isn't around, how can anyone continue his gems without his signature?
<raggi>
we have precedent for wanting to take over gems sometimes
<Antiarc>
There have to be mechanisms for transfer of ownership, and that very naturally maps to a trust chain, IMO.
<Antiarc>
It does rely on "first come, first serve", where the first guy to get his foot in the door establishes ownership
<raggi>
but do you transfer ownership of a gem?
<raggi>
i don't thikn you do
<raz>
i think defining the goals at a higher level first might help
<raggi>
if we're defining a gem as a single file
<Antiarc>
raggi: You can append or replace signing rights on a gem
* kseifried
hands raz a prize
<raggi>
you want to transfer ownership of a publishing namespace
<raz>
this whole ownership already implies a goal (authentication of people) that seems very hard
<raz>
ownership-debate*
<raggi>
ownership is probably misleading the whole conversation
<kseifried>
hahah raggi says the thing everyone missed/ignored =)
<raz>
imho one primary-goal should be: when rubygems.org is MITMed it still shouldn't be possible to sneak modified gems in undetected
<raggi>
because legally, ownership is copyright
<kseifried>
raz: that part is actually easy as shit
<raggi>
just use the ssl cert
<kseifried>
but there's a ton of other issues like handling ownership change/expiry of credentials/etc
<raz>
kseifried: i don't think it's that obvious
<raz>
with MITM i don't mean only at a network level (that's solved by SSL), but when the attacker owns the host - like he did this time
<kseifried>
no I mean it is that simple/ovious at one level
<kseifried>
but there are some subtle issues that need thinking about
<raz>
perhaps one could phrase it like as a scenario: What happens when a malicious party replaces rails.gem on rubygems.org? - which mechanism detects and alerts this
<raggi>
raz: that's not a mitm, that's credential theft
<kseifried>
raggi, : I think he means replace in the sense of DNS/bad CA/etc
<raz>
raggi: yup terminology aside, it might be easier to describe it in the form of example attacks
<raz>
raggi: "what happens if X"
<kseifried>
raggi, : we have established that not all CA's behave well :P
<raggi>
kseifried: we've also established that they react to issues because they are an entity
<raz>
it should be possible to enumerate the most likely attacks and then inspect what each model does to prevent them
<kseifried>
anyways these types of issues are known problem spaces, the trick for rubygems is we have less control over "upstream" and need to support features that RPM for example doesn't
<kseifried>
raz: already on it, don't worry
<raggi>
kseifried: (not always well, but that's a separate trust issue)
<raz>
kseifried: nice! :)
<raz>
kseifried: ideally put it online somewhere so we can refer to it
<kseifried>
ultimately like rpm it won't matter where you get your gems as long as you have the public half of the signing key, much like rpm, otherwise the whole point of this is moot =)
<raz>
kseifried: agreed
sferik has joined #rubygems-trust
<raggi>
so, "insecure download"
<havenn>
DNS spoofing, response rewriting, SSL stripping are the biggies?
<raz>
i don't think it's a good term
<raz>
havenn: that would be "network MITM" i'd say
<kseifried>
you guys are worrying about the wrong things =)
<raz>
and yes, real issue
<raz>
insofar as the scheme will have to prevent it
<Antiarc>
If you have a means to verify sigs, MITM or DNS spoofing isn't really a concern, since any replaced file would fail validation checks, no?
<kseifried>
better to rephrase the question "I want a rubygems signing system that allows me to download gems from KNOWN malicous sites safely so I don't have to care at all" =)
<raz>
Antiarc: correct.
<raz>
kseifried: correct :)
<kseifried>
and again, we've done this with rpm/etc, it's not to hard actually
<raz>
kseifried: well, the hard part (imho) is to keep it convenient
<Antiarc>
my proposal covers that, fwiw.
<kseifried>
no. that's actually.. easy in some ways
<kseifried>
Antiarc, : how does your proposal handle expiry of signing credentials? =)
<raz>
kseifried: well, i'll just wait for your proposal, it's hard to discuss in open space :)
<havenn>
Antiarc: Have a writeup or anything yet to link to?
<Antiarc>
kseifried: Haven't defined it, but I think that you'd simply not accept gems signed after a cert's expiry.
<kseifried>
Antiarc, : yeah the list you have basically misses 90% of the problem
<kseifried>
Check if the revocation list has changed since the last time it validated certificates for known gems.
<kseifried>
what do you do when that fails?
<kseifried>
especially when it fails and will never work because the attacker is Mitm's you
<kseifried>
etc
<raz>
kseifried: CRL is a hard problem imho. i've thought about that for a while, can't find a perfect solution.
<raz>
in the end the best you can do (i think) is deny validation when you can't obtain CRL
<kseifried>
ok. so you just broke my app
<raz>
and the CRL is by definition sort of centralized
<kseifried>
so I tell it to ignore that check
<Antiarc>
kseifried: Best I can think is to fail very loudly.
<Antiarc>
If you ignore loud obnoxious "something is wrong, you should go manually check stuff" warnings, I'm not sure what can be done.
<raz>
i would, again, propose to discuss that in the context of realistic attack scenarios
<kseifried>
raz: you were the one that brought up mitm =)
<raz>
i.e. "Attacker replaces rails.gem, rails-cert is revoked, how is that done and what happens?"
<kseifried>
Antiarc, : ahh, we can make it more robust/fail gracefully
<raz>
kseifried: yup, don't mean to stop the discussion, just think it'll be easier with concrete scenarios, step 1..2..3..
<kseifried>
no
<kseifried>
what we need first is requirements
<raz>
scenario = requirements
<kseifried>
you guys are putting the cart in front of a blank spot because we don't even know what resteraunt we want to go to yet =)
<raz>
there are some requirements listed in the wiki, but iirc they were rather blurry
<Malf>
Yeah they aren't clear enough to realistically get a bunch of people to agree on a solution. Most proposals are attacking a variety of problems, each solution overlapping somewhat with another.
<theartisan>
kseifried: yeah, the only reference in that proposal to using the short id was in the signed manifest filename, realistically there will be 1-3 signatures per gem, any actual checks should be made using full keys, if you can suggest some wording that might make that clearer i will change
<theartisan>
or i will change at some point, i have just been out for american food so my puny british stomach is about to explode.
<raz>
i really like my scenario idea :P
<raz>
we could rank the schemes by how many scenarios they solve convincingly
<Malf>
Hah I do like putting things in a concrete context. The only possible quibble with ranking is first identifying if those are the 3 scenarios we care about or not (maybe we care about a 4th, maybe we only care about 2 of them, etc.)
<Malf>
or perhaps #1 is of critical importance, #2 is nice to have, etc.
<Malf>
but yeah overall I like it (partly because I didn't want to find myself trying to monitor/maintain that same sort of list over the coming week)
<raz>
yes, ofcourse the scenarios need to make sense
<raz>
feel free to comment on them :)
<raz>
we can also prioritize them, some are less important than others
<theartisan>
MITM and dropping fake gems should be highest priority
<theartisan>
and are both potentially fixed by the same thing
<theartisan>
any kind of signing means we can check for that on install
<raz>
yup i agree. basically the scenario we have right now (rubygems.org compromised) covers a large portion of other scenarios as well.
<raz>
i think by looking at that one closely, people may realize why an automated CA (imho) doesn't help
<Malf>
Yeah scenario 1 is the must-have IMO. Arguably 2 is much less important because it targets an individual rather than everyone so I'd probably consider #3 the next highest priority issue.
<raz>
Malf: the good thing is, anything that solves #1 also solves #2 :)
<raz>
(i think)
<Malf>
yeah possibly
<Malf>
honestly if you scope down the unique parts of #2 then only allowing an HTTPS connection solves it
<raz>
rails-3.0.0.gem with confidence that
<raz>
it originated from 37signals
<raz>
woops
<raz>
Malf: not quite, note how the scenario says what i just pasted
<raggi>
it doesn't though
<Malf>
right I think the origination is really part of #1
<raz>
it doesn't say "originated from rubygems.org" :)
<raggi>
it originates from at&t right now
<raggi>
lol
<raggi>
so if you trust 37s you're already failign to install recent rails versions
<Malf>
maybe I'm saying I think #2 is two separate problems
<raz>
yup, all of them touch various intertwingled problems
<raz>
that's part of the point: it's easier to think about this when you can enumerate what happens or doesn't happen step by step
<Malf>
Sorry let me rephrase. I think it's easier to think about it if #2 became two scenarios. One where you want to be sure you are downloading from rubygems and one where you want to be sure the gem on disk came from 37s
<raz>
the wording probably still needs improvement to make everyting unambigious
<Malf>
but that's a nitpick on the scenarios at best
<raz>
Malf: does "be sure you're downloading from rubygems.org" really deserve its own scenario?
<Malf>
I don't know
<Malf>
I'm not sure the notion of the network is really relevant in #2 if it doesn't
<raz>
hm i see your point
<manveru>
i don't think rubygems.org should be a special case though... the signing is for the gems, if those signatures check out it doesn't matter if it's from another site?
<Malf>
I guess I'm asking what the core of the scenario is supposed to be in #2. Are you really asking how do you verify that it came from 37s?
<raz>
manveru: yes, that's my thinking as well
<Malf>
yeah agreed
<raz>
Malf: yes, that's what i'm asking :)
<Malf>
okay
<raz>
it may be debatable whether that's the right question to ask
<manveru>
what's really important are the trusted lists though, because 99% of people will use those for convenience
<raz>
but yes, i agree it's not a very good phrasing because it implies so much (what does "originate from 37signals" really mean)
<raggi>
that's not even something you can validate
<raggi>
you can only validate "was signed by a particular key" (if you're talking about signing)
<raz>
raggi: hence my quibble earlier about talking about "signing keys" instead of "people" or such..
<raz>
yes
<raz>
perhaps i should change that to "was signed with the 37signals key"
<raz>
which immediately leads to the question "which key is that" ;)
<raggi>
anyway, that's just a user education problem
<Malf>
yeah I can't come up with a clearer wording that doesn't significantly weaken the scenario so
<Malf>
I guess I'll stop pestering you on it
<manveru>
also "was signed with an unrevoked 37signals key" :)
* tarcieri
is writing down the "real" CA proposal
<raz>
Malf: no prob, your point makes sense
<tarcieri>
manveru: lulz, and revoked by whom, using what revocation system?
<manveru>
i thought we were gonna use pgp?
<raz>
i guess if the proposals really try to respond to the scenarios then it will at least be interesting to watch how they interpret them :)
<tarcieri>
I should start phrasing things the way some of you do
<tarcieri>
it's kinda hilarious
<tarcieri>
GPG is totally off the table
<tarcieri>
unworkable
<tarcieri>
terrible idea
<raz>
tarcieri: um. says who?
<manveru>
archlinux uses it for its packaging
<tarcieri>
lol
<tarcieri>
raz: I'm just making fun of your argumentation style
<raggi>
manveru: many OS packaging systems do
<raggi>
manveru: in fact, many packaging systems in general
<manveru>
so unworkable...
<raz>
tarcieri: ? i haven't seen anyone say something like this
<tarcieri>
that was a joke, bros
<raggi>
manveru: although most in a similar position as rubygems only do it as an extension
<tarcieri>
raz: yes, yes you most certainly have
<tarcieri>
raz: remember when I called you a dick? that's exactly what you were doing
<raggi>
manveru: for exactly the reason it's difficult for rubygems
<manveru>
yeah
<raz>
tarcieri: seems you're referring to two days ago, the discussion has progressed a bit since then
<tarcieri>
raz: you seem to be doing better lately ;)
<manveru>
they have more centralized maintainers/packagers that you can mostly trust... compared to thousands of individuals
<raz>
tarcieri: and you seem to be doing worse :/
<havenn>
Unless a GPG standalone gem solution becomes popularized to the extent that ruby-core considers adding a dep, probably dead in the water?
<tarcieri>
but manveru just phrased it that way: "i thought we were gonna use pgp?"
<raz>
tarcieri: he just asked a question, i think he's new here and simply doesn't know the state of discussion
<manveru>
^ that :)
<tarcieri>
heh
<raggi>
havenn: or, possibly, someone writes a minimal subset of what we need, for inclusion in rubygems
<raggi>
havenn: but that's potentially sketchy
<manveru>
not trying to talk for anybody here
<tarcieri>
manveru: there are many proposals, not all of which use gpg, and gpg has many issues particularly around multi-platform support and bootstrapping
<manveru>
sorry if it sounds that way somtimes
<raggi>
manveru: i'm enjoying seeing some reasoning about the community, so please carry on
<Malf>
I think part of the GPG question ties into scenario #1 that raz presented
<raz>
yup, well basically all models can be implemented with all libraries that are on the table (pgp, x509)
<Malf>
Clearly someone could propose a gpg solution that handles that scenario without relying on every end user having gpg installed
<raz>
but some models are obviously easier to implement with one or the other
<manveru>
well, since there was trouble just getting a ruby implementation of gzip so things work properly on all platforms... i don't even wanna know how much work gpg would be
<raz>
yup, the impl-barrier for gpg seems high
<raz>
which gives the models proposing x509 an edge ;)
<manveru>
OTOH, if somebody with high stakes makes a nice bounty, it could work :)
<raz>
yap, afaik there is efforts undergoing to get some adults on the case
<raz>
(sec-people from redhat and google)
<manveru>
that would be great
Malf has left #rubygems-trust [#rubygems-trust]
<raz>
only if they don't end up tying gem registration into a google account or such ;)
<raz>
but that seems unlikely heh
<manveru>
the x509 proposal looks neat
<manveru>
just applying for a key looks... complex
<manveru>
any reason to involve mail in the process?
<tarcieri>
wait, there's another "real CA" proposal?
<raz>
i.e. phrase your requirements in the form of scenarios, so peoples brains don't explode :)
<raz>
(it's easier to compare a proposal to a set of scenarios than to translate the requirements to various wildly different models)
<raz>
doesn't have to be only "attack" scenarios, can also be stuff like "maintainer A wants to hand control over to maintainer B" - which is in fact still missing
<raz>
manveru: meaning if github AND rubygems.org get compromised at the same time - bad
<manveru>
bbiab
<raz>
however still a relatively small value of bad, as most people would probably already have the real keys for most of their gems cached
<raz>
the more critical vector in my model are the trust-lists. obviously if someone adds his own key to the 37signals list, and you trust it... well...
<raz>
chains work both ways ;)
<raz>
that's why i proposed to make that part strictly optional and not the default
Perceptes has joined #rubygems-trust
<havenn>
Am I off-base that this is the general priority order?: High) Prevent MITM with X.509 and be able to revoke certs, Med) Elegantly handle multiple maintainers signing and transferring privilege, Low) 'validate' identity of cert-requester
<raz>
havenn: sounds about right to me, but "MITM" needs explanation (can mean many things)
<manveru>
raz: well, i like your proposal a lot too
<raz>
thx :)
<manveru>
how would you handle changes in the key url between versions?
<raz>
manveru: there is no change. the key would actually be the author-key usually.
<raz>
i.e. the same across projects
<raz>
key changes in any way (old author -> new author, or sub-projects etc.) could be done with normal key-chaining
<manveru>
i.e. first it's from github.com/foo/bar then attacker just uses from github.com/fo0/bar or something similar
<raz>
i.e. once a user trusts one key of yours it automatically also trusts any other keys that you sign with it
<manveru>
yes hai si ja aye arr ui da un ... now i'm running out of languages :P
<raz>
except in addition to the fingerprint it will show the url
<raz>
and the gem name ofcourse
<manveru>
yes
<manveru>
anw, now reading the one from tarcieri
<raz>
tarcieri: technically your system is great. as we discussed earlier, personally i'm afraid it falls down at "due diligence on possibly dozens of new gem authors per day".
<tarcieri>
raz: yeah, see "Practical feasability" at the end
<manveru>
do we have any stats on that?
<tarcieri>
I saw someone mention something
<tarcieri>
I think it's like a couple dozen per day
<namelessjon>
manveru: It's something like 650/gems per day, of which that's ~50 new gems.
<tarcieri>
or something like that
<manveru>
well, with required signing that'd go down a lot, i suspect :)
<havenn>
tarcieri: Seems like a robust solution. Is something with less need for manpower maybe viable? OAuth OR manual review or something like that? Seem intensive!
<havenn>
s/seem/seems
<tarcieri>
havenn: it does, I suspect if X.509 is used it will probably be a more automated system like that
<namelessjon>
Also, not sure how many of those are 'new gems from an author already seen'
<tarcieri>
namelessjon: I think it would make more sense to tie certificates to individual gems the way HTTPS certificates are tied to individual domain names
<raz>
lots of slippery slope here.. how do the volunteers prevent me from revoking 37signals key
<raz>
;)
<tarcieri>
raz: if they do, they're fired
<raz>
tarcieri: hehe
<havenn>
Would be a LOT fewer certs to vet and easier for catching up on already-released gems if it was by author rather than by gem. Hrm.
<tarcieri>
and possibly legal action is taken against them
<raz>
tarcieri: i think you could label this model the "app store model". it's basically like the apple app store and google play.
<havenn>
I don't know the stats on average number of gems per author, but i assume it is fairly high?
<tarcieri>
raz: it's really not... that was something else I was suggesting though, albeit as a startup
<raz>
tarcieri: now add some payment infrastructure so we can charge for our gems and this might actually become interesting ;)
<namelessjon>
tarcieri: I agree, but still, if the volunteers also issue you with a 'user' key, then you just have to check they have the new project, not who they are.
<tarcieri>
raz: Ben Smith suggested that in his talk
<havenn>
raz: I will pay you to use my gems... >.>
<raz>
havenn: lol.. really? no problem man, just give me the url ;)
<raz>
i won't even validate :P
<tarcieri>
namelessjon: imagine Jim Bob gets a cert. should he be able to sign "rails"?
<namelessjon>
tarcieri: No, I agree there should be per gem certs.
<raz>
havenn: i've watched it but frankly didn't find it very enlightening
<havenn>
tarcieri: Oops >.>
<raz>
he basically explains "gems can do bad things" (duh!) and in the end says we should sign our gems ;)
<tarcieri>
raz: he talks about a lot of the problems, and also how easy it is to social engineer people into installing malicious gems
<namelessjon>
tarcieri: But if there is also a per user cert, you can reduce the checking for new projects from the same user. i.e. I can just sign a file on github with my user cert, to prove I own that project.
<tarcieri>
raz: he also suggested an "app store" like model where you could have a startup that actually does code reviews on gems
<raz>
tarcieri: well, yes. he also asks the community to please not write malicious gems. ;)
<havenn>
raz: Why didn't we think of that! Lets just ask people to play nice. :P
<tarcieri>
namelessjon: I think you could still have per-user certs, but they'd need to be signed by the project cert
<raz>
tarcieri: yup, which is imho flawed for similar reasons as yours; it's *really* hard to vet gem authors in a meaningful way.
<raz>
if you want accountability you have to attach real names to gems and verify them etc.
<tarcieri>
namelessjon: the whole point being least authority... the scope of certificates issued for particular gems is limited to just those gems and nothing more
<raz>
and don't think anyone wants that
<tarcieri>
raz: I'd be fine with it
<raz>
tarcieri: i'm not. the only thing it'd achieve would be that most people start releasing their gems as binaries and we get a second "gem black market".
<raz>
because many people don't want to jump those hoops (which would have to be significant to be effective)
<manveru>
_why wouldn't be fine with that :P
<raz>
yup.. _why is a nice canonical example here :)
<manveru>
but he'd probably whip up an alternative to rubygems in an afternoon
<tarcieri>
I wasn't proposing getting anyone's drivers license... but trying to piece together who they are from figments of their online identity
<raz>
tarcieri: well, if you're going to limit yourself to that i'd argue that's not effective
<raz>
a malicious party could easily game it
<raz>
and many people simply don't have many useful online figments to draw conclusions from
<tarcieri>
depends how much due diligence you actually do
<tarcieri>
and I think there's a lot to be gleaned from online identities
<raz>
tarcieri: well, unless that's specified, we have to assume: not enough :)
<theartisan>
the commends above about GPG and getting it into ruby-core, that is apparently not a problem if rubygems needs it.
<havenn>
tarcieri: Would gem certs be associated with author certs? I'm curious about the advantages of signing each gem rather than by author?
<theartisan>
s/commends/comments/
<tarcieri>
"GPG" in ruby-core o_O
<tarcieri>
theartisan: what do you even mean by that?
<theartisan>
as a dependency
<tarcieri>
theartisan: a pure Ruby port of GPG?
<tarcieri>
incorporating the C code?
<tarcieri>
and if the latter, how does that work for JRuby?
<raz>
it might make sense to discuss the schemes ignoring the implementation
<theartisan>
drbrain mentioned that if rubygems needed gpg, there is scope to get it added as a dependency of ruby-core
<raz>
at least for a start
<havenn>
tarcieri: I think the discussion was actually a non-Ruby dep on GPG. Sec, looking for what drbrain said verbatim.
<namelessjon>
tarcieri: No, I get that. It just seems redudant that I have to prove who I am using the same bits of identity for each gem I want to publish. With a user cert, prove who I am once (whatever that means), prove I own a project for each gem.
<tarcieri>
namelessjon: well, identities could be modeled at the CA level
<tarcieri>
namelessjon: you could have an accelerated process for approving a gem from a known user
<raz>
err
<raz>
you want to approve every single gem?
<raz>
i thought only authors?
<tarcieri>
I want to have separate certificates for every single gem, yes
* raz
scatches head
<raz>
how many volunteers did you plan to hire again? ;)
<tarcieri>
lulz
* theartisan
is inclined to fall back on the gpg infrastructure as it is already well established.
<tarcieri>
as I said at the end
<tarcieri>
there are 50,000 gems
<tarcieri>
theartisan: and it provides no real trust model
<tarcieri>
it would if you have a trust root
<tarcieri>
but that has no advantages over what's in RubyGems now
<tarcieri>
besides an arguably better cryptosystem
<namelessjon>
tarcieri: Yeah, thats essentially what I'm proposing. Just suggesting a cert is the way to do it, since ... well ... if I can't be trusted with my user cert, I also shouldn't be trusted with a project cert ;)
<tarcieri>
but at the same time an onerous external dependency
<raz>
tarcieri: let's say a volunteer can vet 100 gems a day. then you need 6 volunteers working 7 days a week only to process the existing 50k gems within 3 months.
<tarcieri>
namelessjon: should SSL certs be based on individuals instead of domains? ;)
<raz>
and that's not even getting into *how* they are supposed to vet, new gems, revoke/change requests etc.
<tarcieri>
raz: not denying the practical concerns
<raz>
i lack the fantasy to imagine how this is supposed to work, at all :)
<tarcieri>
haha
<theartisan>
can you not make use of the RSA signature support in openssl to do the signing? and hpk is a fairly simple protocol.
<manveru>
well, if one could vouch for other people, that might work?
<tarcieri>
theartisan: that's what RubyGems already does
<manveru>
without being much of a volunteer
<raz>
manveru: that's then the web-of-trust model
<raz>
it's part of the proposals that don't hinge on a CA
<raz>
they call it "trust list" and such
<manveru>
exactly
<tarcieri>
theartisan: I'm not really a fan of RSASSA and there are known attacks against it, but it's... probably fine from a practical perspective
<raz>
the CA assumes there's someone at the top with authority
<kseifried>
you do realize X.509/etc can cross sign certificates and you can do a web of trust
<kseifried>
but again. cart horse. blahb lah
* tarcieri
more like web-of-trust considered harmful, especially for this use case
<theartisan>
if the gems are signed, and the keys explicitly added, then you have a more secure rubygems/gem
<raz>
kseifried: yes, the impl is a bit of a secondary concern. pgp is only on the table because of the existing infrastructure that could be leveraged (keyservers etc.).
<theartisan>
if bundler logs the authorizing cert in gemfile.lock
<tarcieri>
if it's easy for an attacker to get you to (vicariously) accept a malicious key, the system is worthless
<theartisan>
production systems are less likely to be compromised
<theartisan>
if someone tanks a developers system with a rouge gem its not the end of the world
<raz>
theartisan: actually it is
<theartisan>
and your likely to see things like dialing home and what not with the extra security most developer machines have, firewalls and such
<raz>
but that's a different discussion
<theartisan>
raz, not really
<raz>
theartisan: yes it is, let's just not have this discussion, you are wrong :)
<raz>
theartisan: keylogger, reading your ssh private key etc. etc.
<theartisan>
a tanked production server is the end of the world
<raz>
theartisan: there's no difference, period. both are catastrophic events.
<theartisan>
it can read my ssh keys all it wants, but when it tries to dial home my firewalls will catch it.
<raz>
theartisan: most people don't have that kind of firewall.
<namelessjon>
theartisan: your firewall stops you from making http connections out? irc?
<havenn>
Just an extract from the log, but here is the TL;DR of GPG viability as a dependency: https://gist.github.com/4703557
<theartisan>
if it rm -rf / 's my laptop i can restore from a backup and carry on, if that happens to my produciton boxes thats downtime which is bad
<raz>
theartisan: it can also read everything you have on your laptop and send it anywhere it wants
<raz>
and your "firewall" will not prevent it
<theartisan>
namelessjon: it stops random processes making http and irc connections out
<raz>
theartisan: trivial to circumvent
<theartisan>
but, the point is i will notice
<namelessjon>
theartisan: what if the hack fires up curl?
<theartisan>
and i can invesitgate
<havenn>
Basically, if GPG ships with Ruby then RubyGems can use it. If RubyGems needs it, Ruby will ship with it. Kinda circular, but... :P I think basically if it is *the way* to go, it isn't off the table. But no easystreet.
<raz>
havenn: once we agree on which properties we want from the system we can decide how we want to implement it
<havenn>
Seems to me that a CA signing gem maintainer certs is the path of less resistance.
<raz>
if the favored system is too hard to implement (possibly due to pgp) we can fall back to the second favorite :)
<theartisan>
namelessjon: it would pick that up too
<raz>
havenn: you mean the "volunteers" idea?
<tarcieri>
havenn: what does "GPG ships with Ruby" even mean again?
<tarcieri>
havenn: what is "Ruby" in this case?
<tarcieri>
havenn: every single Ruby implementation out there?
<tarcieri>
what does JRuby do?
<tarcieri>
is JRuby expected to package GPG as part of their distribution now?
* raz
mumbles something about lack of focus in the discussion
<theartisan>
tarcieri: if they want to use rubygems
<tarcieri>
theartisan: does that seem... bad?
<theartisan>
no
<tarcieri>
it seems very, very bad to me
<manveru>
i suspect there is some gpg.jar around?
<theartisan>
there are java impelementations
DonOtreply has joined #rubygems-trust
DonOtreply has quit [Max SendQ exceeded]
<raz>
can we postpone the impl debate and decide for a model first?
<raz>
really, it makes no sense the other way round
<tarcieri>
what exactly do you hope to gain over the signature system that's in RubyGems today?
<tarcieri>
raz: the dream scheme (like mine) doesn't help if it isn't practical
<theartisan>
tarcieri: making people use it, and key distribution
jstr has joined #rubygems-trust
DonOtreply has joined #rubygems-trust
<tarcieri>
theartisan: what about "making people use it" can't be solved with the existing system?
<raz>
tarcieri: yes, but yours falls down due to systemic issues, not tech-impl issues
<raz>
tarcieri: your volunteers are the same problem regardless whether we use PGP or x509
<tarcieri>
raz: it fails due to practicality
<tarcieri>
there are practical technical problems with making gpg a dependency of rubygems
<tarcieri>
the two biggest that come to mind are Windows and JRuby
<raz>
well either way, we should decide for a model that DOES WHAT WE WANT, and then look at whether it's feasible to implement
<havenn>
tarcieri: I think the appealing thing about GPG is that if it is allowable as a Ruby dependency, then implementation is a cinch. Nice plugin already exists that shells out to GPG: https://github.com/grant-olson/rubygems-openpgp
<tarcieri>
if I had my way everyone would use NaCl
<tarcieri>
but I wouldn't even suggest that
<tarcieri>
because I don't think it's particularly practical
<tarcieri>
havenn: yeah seen it, cool story
<namelessjon>
Making people use it is really easy: make rubygems.org reject unsigned gems. Honestly, that's the single easiest thing about any proposal.
<raz>
namelessjon++
<tarcieri>
havenn: do you think that should be incorporated into Ruby core?
<theartisan>
tarcieri: the problem with the current system seems to be key distribution, GPG solves that
<tarcieri>
key distribution is easy: put the key in the gem
<tarcieri>
problem solved
<havenn>
tarcieri: You mean rubygems-openpgp or nacl?
<tarcieri>
the (signed) pubkey of course
<tarcieri>
havenn: heh forget nacl ;)
<jstr>
The biggest advantage for x509 over GPG/PGP is that most machines (developer machines or servers) have openssl (or an equivalent).
<tarcieri>
confirm
<jstr>
GPG/PGP aren't as widely distributed
<jstr>
And are a pain to install on some systems
<tarcieri>
OpenSSL is also already in the Ruby standard library
<havenn>
tarcieri: I personally prefer a CA. I can't speak to the technical aspects of which is superior :P but we already have X.509 as a req, already have it incorporated as a non default into RubyGems, seems like CA-route is way to go.
<jstr>
Yes.
<tarcieri>
and already (kind of) supported by JRuby
<tarcieri>
havenn: confirm
<theartisan>
jstr: we can make GPG a requirement for rubygems though, and that will mean any machine installing gems will have gpg
<jstr>
theartisan Yeah but that is a massive PITA
<tarcieri>
theartisan: who is "we"? lol
<raz>
havenn: note CA != x509
<havenn>
raz: Roger that, but I don't want to pay to sign my own cert!
<tarcieri>
whatever you're proposing needs to be accepted by the people actually maintaining RubyGems
<theartisan>
tarcieri: the maintainers of rubygems?
<havenn>
raz: No one trusts my cert.
<raz>
havenn: no, i mean you can use x509 without a central CA (that's what i'm proposing), they're separate concerns
<tarcieri>
convince Evan Phoenix, Ryan Davis, Eric Hodel, James Tucker, etc
<tarcieri>
theartisan: do you work on RubyGems? if so, I don't know who you are
<havenn>
raz: Then individuals will just hand-wave accept every cert, no?
<theartisan>
no i dont
<raz>
havenn: well, read my proposal if you're interested ;)
<theartisan>
but we pointed out earlier that it was a viable option
<tarcieri>
I disagree about its viability
<tarcieri>
lol the use of "we" is really annoying me here
<tarcieri>
it's kind of like Suicidal Tendencies / Institutionalized
<tarcieri>
you know
<tarcieri>
"WE decided?" "MY best interest?"
<manveru>
i don't :)
<tarcieri>
theartisan: okay that's more than nothing
<tarcieri>
theartisan: now ask headius about how he feels about shipping gpg with JRuby
<raz>
we need someone to steer this :/ hopefully tomorrow someone actually affiliated with rubygems can chime in
<tarcieri>
raz: yeah, what raggi said
<tarcieri>
someone without vested interest in one solution or another needs to be the impartial moderator
<tarcieri>
and they should not participate in the debate
<theartisan>
i think the constant bickering and back and forth is making it hard for them to chime in :)
<raz>
sure they can participate
<raz>
but primarily they should read the proposals, ask questions, and then make a decision
<raz>
because we are not going to reach consensus on our own here :)
<tarcieri>
concensus will be reached when rubygems-proper agrees on a solution
<theartisan>
the problems with each proposal should be commented on, and then work to reword them to handle any problems
<tarcieri>
this is just a rag tag gang of yokels, including myself ;)
<theartisan>
preferably on the issues as apposed to irc
<jstr>
Why don't we make two wiki pages, one of each proposed solution, and then document the pros/cons
<jstr>
Going around in circles here is pointless
<kseifried>
uhh
<kseifried>
jstr, : yes, that's why some of us are working on a requirements doc
<tarcieri>
jstr: some of the proposals are documented on github
<namelessjon>
jstr: That's what the issues are
<manveru>
maybe we can get ptacek as mediator?
<kseifried>
proposing a solution when you don't know what the actual question is... sigh
<tarcieri>
jstr: this is just the peanut gallery
<tarcieri>
manveru: that'd be great, if he's interested
<jstr>
kseifried tarcieri Yep, I started some of the writing days ago
<tarcieri>
manveru: I can ask him
<raz>
fyi
<raz>
<samkottler> raz: honestly it seems like the group with an implementation will get the further
<theartisan>
tbh the wiki would had been a better place to store them
<raz>
time to get coding perhaps
<tarcieri>
raz: it's the Ruby Way!
<samkottler>
tarcieri, raz: exactly!
<raz>
gives me a nice advantage though
<raz>
my proposal will only be like a ~15 lines patch :P
<samkottler>
raz: :D
<tarcieri>
my solution doesn't require much coding, since it leverages what's already built into rubygems
<raz>
gonna look into it later
<tarcieri>
in fact
<tarcieri>
it requires 0 coding
<raz>
tarcieri: uh, you may want to set up a CA and stuff?
<tarcieri>
no coding, I win!
<raz>
tarcieri: or do you expect the rubygems team to do that?
<tarcieri>
raz: heh, not saying there isn't work
<havenn>
An up-and-running CA with a pull request to RubyGems or a large number of people actually using a GPG plugin seems compelling (don't see the latter happing).
<raz>
tarcieri: and all the infrastructure for gem vetting, registration etc.?
<tarcieri>
raz: heh
<raz>
tarcieri: i'd say you have a few nice months of coding in front of you.
<tarcieri>
raz: it can be a text form
<tarcieri>
and a mailing list
<tarcieri>
no coding
<tarcieri>
the tooling is already done by openssl
<raz>
tarcieri: i'm sure the rubygems team will appreciate your turnkey-solution as you hand it in :)
* samkottler
slams his face on his desk as this convo goes around in circles
<tarcieri>
that's not the ideal solution, but it's the bare minimum required
<manveru>
tarcieri: ptaceks wife is on irc atm, i can ask her
<tarcieri>
manveru: heh, I have him on IM *shrug*
<tarcieri>
he's away though
<manveru>
works too :)
<havenn>
tarcieri: Ideally, should there be a single CA? (Just curious if having a fallback for apocalytic reasons is valid or bad idea?)
<manveru>
they both work in security anyway
<tarcieri>
havenn: I think there should be a single CA for authenticating "rubygems.org"
<jstr>
havenn: nothing to prevent multiple CAs for multiple sources
* theartisan
has no time to implement anything, between a 80 hour work week, speaking engagements, and a small reminisce of what was once a social life little time is left for personal projects.
<tarcieri>
yeah I'm kind of already overstretched for time
workmad3 has joined #rubygems-trust
* samkottler
is hoping to get some time from work
<theartisan>
what resources are there? there was talk of maybe redhat resources? was that kseifried?
<samkottler>
theartisan: I am a red hat employee and kseifried is as well
<theartisan>
ah
<theartisan>
raggi: you mentioned potential resources too?
<samkottler>
we need to talk internally about what kind of time people will get
<theartisan>
the first step is properly defineing the problem
<theartisan>
maybe we should shelve all proposals untill then?
havenn has left #rubygems-trust ["Leaving..."]
<theartisan>
is anyone well suited to author that doc?
<theartisan>
im guessing some of the large corps will have people who are skilled at such things.
<raz>
anyone happen to have a gem handy that is signed? (just the name)
* raz
is looking at the code now
<manveru>
rack
<raz>
hm
<raz>
manveru: Unsigned gem
<manveru>
i thought raggi signs them?
<raz>
ah.. might be HighSecurity wants that extra stuff in the chain
* raz
reads up
<kseifried>
theartisan, : I'm on SRT, I'm the cloud guy, most of our cloud products make heavy use of Ruby/Rails/gems
<kseifried>
theartisan, : I've also start rallying people, got about a dozen interested/longer term involvement
<manveru>
raz: sorry, they are pgp signed, i guess the gem isn't
<raz>
manveru: yup, looks like it, unless i'm reading the docs wrong
<manveru>
then i guess i don't know :(
<raz>
i think some people talked about some "z*.." gem being signed but i don't remember which
<manveru>
zenspiders?
<theartisan>
kseifried: anyone that would make a good editor for the requirements doc?
<manveru>
minitest, zentest, rubyinline etc
<kseifried>
theartisan, : some of are workong on one yeah
<kseifried>
some of us rather
<raz>
manveru: yay, minitest is signed
<theartisan>
no solution is going to be better than any other while the problem is "FIX ALL THE THINGS" :)
craigmcnamara has joined #rubygems-trust
<kseifried>
and that's why we're creating a requirements doc first
<theartisan>
wheres the doc living?
<kseifried>
dunno
<raz>
hm yea, nice demonstration of the problem
<raz>
where the fuck do i find the public key for minitest
<theartisan>
can we get the requirements doc on the wiki, into a git repo, or in a linked google doc?
<kseifried>
it needs to be cleaned up a bit but then yeah it'll be public
<kseifried>
as you may have noticed on irc to many cooks with no direction = mess
<theartisan>
a git repo might make more sense
<theartisan>
then issues can be filed against it and it can be properly edited
<kseifried>
theartisan, : it's under control
<theartisan>
we can set it up under rubygems-trust and hand out selective access
<theartisan>
too many cooks would ruin it, but comments should be made :)
<kseifried>
they will be
<theartisan>
actually, who needs to be on the rubygems-trust github org?
<manveru>
well, thomas ptacek agreed to coordinate together with his wife
<kseifried>
theartisan, : myself and the google guy are working on this with other people, it's going quite well, we'll be sharing it not to long
<manveru>
if people should wish so
<kseifried>
theartisan, : trust me, things are moving forwards and we'll be roping everyone in
<theartisan>
i have no time to contribute code, and it would probably not be good enough anyway, there are probably better people to have on the org members list
<kseifried>
yeah, we've got that covered =)
<theartisan>
?
<theartisan>
there are only 4 people on the member list
DonOtreply has quit [Quit: Computer has gone to sleep.]
mattski has joined #rubygems-trust
<yorickpeterse>
We're adding people to the org?
<yorickpeterse>
tbh I feel that whoever has some interest in it and isn't a total scam (e.g. joins for the sake of the Rockstart attitude) is welcome to join
<yorickpeterse>
This wouldn't become some organization like the W3 where you have to put down some serious money before you can play with the rest
<yorickpeterse>
* shouldn't
<samkottler>
I actually see basically no parallels between this and the W3C...
<yorickpeterse>
That's a good thing, I'm just saying we shouldn't be too strict in who can be a member of the organization and who can't
<yorickpeterse>
At least not for now
<samkottler>
yorickpeterse: right
<raggi>
manveru: nope, i pgp sign the git tags
<raggi>
raz: haha, you finally tried to find a signed gems public key eh
<tarcieri>
samkottler: heh, the W3C
<tarcieri>
I have an unpublished blog post on WebCrypto and why there should be a separation between the W3C and whatever cryptographic group writes the normative spec for WebCrypto algorithms (that whoever being someone like ECRYPT)
<raggi>
tarcieri: why would you need to review requests for certs?
<tarcieri>
raggi: the goal would be to try to catch fraudulent requests
<tarcieri>
Satan asks for a cert for "rails" DENIED
<tarcieri>
and so forth
<tarcieri>
I think a lot of the review process could be automated
<raggi>
tarcieri: so these certs are attached to the gem name namespace?
<tarcieri>
that's what I had in mind
<raggi>
k
<tarcieri>
similar to how HTTPS certs are tied to domains
<raggi>
yeah, i'm about 1/2 way down, so maybe you state that explicitly later on
<tarcieri>
yeah probably wasn't clear enough about that
<raggi>
i'm not sure requests for new namespaces really need a review committee too much, i mean, there's an odd confict here
<raggi>
first of all, the review comittee have to actually see some code in order to determine if it's meaningful
<tarcieri>
what's that?
<tarcieri>
yeah, that was a stated goal
<raggi>
rather than just "yeah you can have that namespace"
<raggi>
but ofc, with the number fo gems we have that are basically 1-3 lines
<tarcieri>
heh
<raggi>
it would be very easy to get something past, then change it's nature entirely
<tarcieri>
confirm
<raggi>
take rbx-require-relative, for example
<tarcieri>
this would not protect against someone pretending to be legit then turning malicious
<tarcieri>
only thing it provides for that is revocation
<raggi>
right
<raggi>
if it doesnt' protect against that
<tarcieri>
to really solve that problem you need the "app store" model
<tarcieri>
which would probably be a startup
<raggi>
then it doesnt' get in the way of intentional attackers
<tarcieri>
that reviews code line-by-line
<raggi>
only coincidental attackers
<tarcieri>
and people could pay them for audited gems
<raggi>
right, there are some thgouths floating aroudn for a hybrid model around that problem
<samkottler>
there should probably be a model for people to become trusted gem auditors
<raggi>
but it's outside of the scope of this specific discussion - although there are ways that signing could aid it
<raggi>
(extensible signing)
<samkottler>
like the OS's have people who are known good packagers
<tarcieri>
I can see demand for a service like that but, yeah...
<raggi>
samkottler: no need
<samkottler>
raggi: why not?
<raggi>
kseifried and i discussed a model we think might work well, wihtout needing to be "blessed" as auditors
<raggi>
so, if you could send cryptographically signed "vouches" for "I/we have audited this gemfile, and deem it good for us"
<raggi>
you allow anyone to submit them
<raggi>
but provide a feature in the client that allows you to filter by that, or disallow unvouched stuff
<raggi>
then redhat teams / google teams, etc can all submit their audited vouches
<raggi>
it has no negative impact on the larger ecosystem
<samkottler>
raggi: that sounds good, but what about the problem of people who don't believe the gem should be vouched for
<raggi>
and the wider expanse of smaller orgs or individuals can choose, if they wish, to consume that data
<raggi>
samkottler: they don't have to use the data
<raggi>
samkottler: this is why i would say it shoudl be separate from distribution trust
<raggi>
the content problem and the distribution problem are seprate
<samkottler>
raggi: cool, so I'm google and I can say 'we vouch for this gem' and someone else with a different audit process can choose not to do so?
<raggi>
yep
<jstr>
Requiring manual verification of certificate requests is a bit crazy imho
<jstr>
it should be automatic, just do email verification or something
<samkottler>
the interesting stuff happens when there is convergence of trust
<tarcieri>
jstr: I think it can be largely automated, but I'd want more authentication factors than just email addresses
<jstr>
tarcieri: SSL vendors just do email verification
<raggi>
samkottler: right, some paranoid individual users may have fun by saying "i'll only use gems blessed by google and redhat", and yet they needn't have any direct association wiht the orgs in order to benefit
<tarcieri>
jstr: who *just* does email verification? :P
<samkottler>
raggi: precisely
<raggi>
samkottler: similarly, unlike a committee system, the orgs are not liable for their vouches, you either trust them or not
<jstr>
I just bought an SSL certificate from namecheap with email verification
<raggi>
samkottler: which is better from a liability standpoint - resulting in uptake
<tarcieri>
jstr: seems bad? can't say they didn't do that, but...
<tarcieri>
jstr: I have doubts?
<jstr>
I think we should limit this to just verifying who gems came from, not vetting the creators or the gem contents
<raggi>
tarcieri: it gives them a chance to say "you should use EV certs"
<raggi>
tarcieri: not that the users have a damn clue
<jstr>
For that to work you'd need to absolutely trust the people doing the people doing the vetting, which is a bit crazy imho
* theartisan
senses more fun with RHEL boxes and stupid auditors saying "you can only install gems passing audits by 3 of these 5 organisations"
<tarcieri>
jstr: you either do that, or you don't have a trust model
<tarcieri>
jstr: if you don't mind not having any kind of trust model, you can skip the trust root part
<jstr>
tarcieri: if you can cryptographically prove who the gem came from that's enough
<samkottler>
theartisan: I somehow doubt that's the way it will go since things will be controlled higher up the chain
craigmcnamara has quit [Quit: craigmcnamara]
<tarcieri>
jstr: how do you prove that without a trust root?
<jstr>
Have a trust root
<raggi>
jstr: the gem came from "joe blogs", do you trust it?
<tarcieri>
ok
<jstr>
No
<jstr>
That's why we need a CA, whether it's implemented by PGP or x509 is another question
<theartisan>
most recent place i worked was blocked from using centos6 because it was too new and forced to create a mirror of all os packages each of which needed an external audit...
<theartisan>
apparently redhat and centos people are not to be trusted :)
<jstr>
Evan is right because GPG and PGP both require extra dependency installation
<theartisan>
i personally think the whole purpose of the audit was to make my life as miserable as possible.
<yorickpeterse>
oh god, audits
<tarcieri>
jstr: confirm
<yorickpeterse>
They are only as good as unbiased the auditers (auditors?) are
<jstr>
why are we even talking about audits
<yorickpeterse>
btw read my comment about "my little CA". We need to write some code instead of talking about it :)
<theartisan>
thats another thing to factor into any CA proposals
<theartisan>
whos going to guarantee its all ship shape?
<raggi>
well you coudl start by reviewing rubygems-aws
<jstr>
theartisan: the implementation would need to be assessed by people who know what they're doing
<theartisan>
jstr, i can forsee audit companies being a complete arse about who has signed what gems in the future.
<theartisan>
many of them like to keep the level of crazy dialled up to 11 in my experience.
<jstr>
theartisan explain?
<raggi>
sorry, what changed?
<samkottler>
then just choose not to deal with them
<yorickpeterse>
Gem audits are only going to make things more complex
<raggi>
audit companies will do that today
<raggi>
regardless
<raggi>
signing has no impact on audits
<samkottler>
the point of vouchers is there *isn't* an audit company...
<jstr>
raggi: agreed
<raggi>
the first thing any sane security auditor will do, if you're using gems, is beat you over the ehad for not keeping local caches
<jstr>
signing and auditing are completely separate arguments
<jstr>
arguments/discussions
<samkottler>
this is being OT right now...
Perceptes has quit [Quit: Leaving.]
<raggi>
i'd really like to remind everyone that the "verify identity of gem publisher" is a bonus goal
<theartisan>
main problem is verifying the payload wasnt tampered with on the wire.
<raggi>
i'm still interested, wiht this group, to know what "insecure download" means
<jstr>
If you can prove the source of a gem, it removes to some degree the onus to audit the source
<tarcieri>
raggi: what's the main goal then, verify gems haven't been modified?
havenn has joined #rubygems-trust
<theartisan>
i still think the wording around #2 is a bit shakey
* tarcieri
is a bit worried there's a little too much cargo culting going on in these discussions
<tarcieri>
"SSH does this! Let's do that!"
<raggi>
tarcieri: for me, the most important things are
<tarcieri>
SSH does encrypt-and-MAC. Should we copy that?
<raggi>
tarcieri: reduce the time to known good, during incident response, significantly (maybe even eradicate it)
<kseifried>
tarcieri, : no
<kseifried>
tarcieri: honestly look at rpm as a starting point
<raggi>
tarcieri: reduce the complexity of incident response significantly
<kseifried>
end to end authentication, so who cares about the intermediaries =)
<raggi>
tarcieri: provide clear documentation about the state of the trust model, so that users have a clear knowledge of what they're trusting
<kseifried>
that's the correct way to handle this
<raggi>
tarcieri: provide a template for unknown threat response
<tarcieri>
kseifried: RubyGems is in a bit different boat than dpkg/rpm
<kseifried>
ok and for the record: the new iphone connector is craaaaaaaazy small
<kseifried>
tarcieri, : right. but similar, hell of a lot more similar than SSH =)
<raggi>
tarcieri: provide documentation for incident response processes
craigmcnamara has joined #rubygems-trust
<kseifried>
raggi, : FYI I've changed my feature column to cover this more
<samkottler>
raggi: and a response protocol so researchers can share what they find
<tarcieri>
kseifried: that's a good point, however the ideas should be called out on their respective merits, not just "X does Y"
<tarcieri>
kseifried: both SSH and SSL made horrible, horrible design mistakes
<kseifried>
tarcieri: or we actually have experts make recomendations rather then flailing around blindly
<tarcieri>
hahaha
<theartisan>
raggi: dont tie anything specifically to rubygems.org is another one ;p
<kseifried>
tarcieri, : I know. I've written about them for 10+ years
<theartisan>
which it sounds like you have in mind anyway
<kseifried>
tarcieri: sounds like I have what in mind?
<raggi>
kseifried: i'm thinking of adding some stuff from a different direction, specifically documenting customer groups desires
<kseifried>
yah
<kseifried>
raggi, : definitely
<kseifried>
raggi, : gems is primarily consumed by services, but us poor vendors =)
<raggi>
end users, developers, service providers, library providers, vendors
<raggi>
there's actually a lot of them, and they have really different properties
<kseifried>
yah
<kseifried>
raggi: yeah from my article notes: Affected users of the software who distribute it, (this is recursive, vulnerable software A may be used or embedded by project B which in turn is shipped by Vendor C and used in hardware by vendor D) or provide it as a service in some way =)
<raggi>
yeah
<raggi>
the downstream stuff is wonky
<raggi>
similarly there's a lot of second stage / multilevel attack vectors too
<raggi>
most of the trust models we've seen so far arent' attached to namespaces, so their vulnerable to cross-namespace attacks too
<raggi>
(trust trojans)
<raggi>
that's also why i really don't like the "project level
<raggi>
model
<tarcieri>
eh?
<kseifried>
yah because that's not discrete/controllable
<tarcieri>
raggi: what you just said would seem to support the project-level model?
<kseifried>
tarcieri, no.. it's al ot messier than you expect
<tarcieri>
kseifried: how so?
<raggi>
tarcieri: i mean multi-gem projects
<tarcieri>
aah
<raggi>
i also really don't like the UX of a cert per gem model
<raggi>
at least, in most incantations i can think of
<raggi>
s/per gem/per namespace/
<raggi>
the temporal authorization aspect has my head spinning a bit too
<raggi>
as we really don't handle timestamps well right now, and that's a big problem
<tarcieri>
raggi: US for whom?
<tarcieri>
err
<tarcieri>
UX
<raggi>
tarcieri: gem publishers
<tarcieri>
people requesting certificates?
<tarcieri>
aah
<tarcieri>
yes
<raggi>
tarcieri: if you end up with 100 certs
<raggi>
ECOMMON
<kseifried>
kill me
<tarcieri>
confirm
<raggi>
tarcieri: any thoughts on the temporal aspect?
<tarcieri>
raggi: I think ideally you would use the project-level certs to sign certs for individual publishers
<tarcieri>
what do you mean by the "temporal aspect"?
<raggi>
tarcieri: i'm referring to everything in namespace N released before "december 2012" is signed by X, and everything after, is signed by Y
<tarcieri>
aah
<tarcieri>
so validation of old gems
<tarcieri>
yeah that's tricky
<raggi>
right
<raggi>
there's two distinctly different approaches
<tarcieri>
probably have to resign them with the new cert?
<raggi>
obviously
<kseifried>
and how do we validate old gems if the signing cert was revoked because it was exposed? =)
<raggi>
either re resign everything (dangerous)
<raggi>
or, we make the client temporally aware
<raggi>
i think the latter is a better approach
<raggi>
old sigs are not invalid
<kseifried>
I think temporal awareness for something internet connected is only sane
<jstr>
kseifried: the gem producer would need to re-sign are a getting a new cert
<kseifried>
otherwise we also enter the world of replay attacks
<raggi>
rewriting files, or having a precedent for mass alteration of files is bad
<kseifried>
also how do we handle the removing newer gem and replacing with older signed gem that has known vuln, etc
<jstr>
after*
<kseifried>
all sorts of shenanigans!
<raggi>
as how do you tell the difference between a valid resign, and a resigning attack?
<raggi>
it alters the scope of a theft of reissue attack significantly
<kseifried>
raggi, : duh. my magic rock will tell me. google didn';t give you a magic rock when you joined? =)
<raggi>
kseifried: just yank it
<raggi>
kseifried: but that's my opinion
<kseifried>
hahha
<kseifried>
no this is similar to rpm issues
<raggi>
kseifried: it's not easy - for the reason you're bringing up
<raggi>
kseifried: you can release a new pointlevel
<kseifried>
like we have a lot of signed rpms out there with known vulns (e.g. CVE-2013-0333)
<raggi>
if we're temporally locked, not version locked
<raggi>
(which is the only sane way)
<kseifried>
so then we have to repo data above it
<raggi>
kseifried: bear in mind, that yank == no more index visibility, but the file is still available
<raggi>
i.e. no new dependents, but old dependents are not broken
<raggi>
yanking has seriously shitty implications for mirrors today, though
<jstr>
Doesn't x509 take care of all of this?
<raggi>
but mirrors are again, someone else' problem
<raggi>
jstr: a sig isn't invalid because the gem content has a security flaw
<raggi>
jstr: and there's a balance to be had as to wether we should be revoking that sig
<jstr>
the sig can be revoked though, and rubygems can prevent the gem being installed
<raggi>
jstr: if someone depends on it in a non-vulnerable way, why would we break their app?
<kseifried>
jstr, : huh. what.
<raggi>
jstr: what's a reasonable level of control to exert in that regard/
<kseifried>
this is a control/process issue first off
<raggi>
yes
<kseifried>
"do we allow/support this"
<kseifried>
then if yes, how to implement
<jstr>
Security flaws are one thing, compromised gems are another
<raggi>
right, we have to choose a support position
<raggi>
either the trust model helps with it, or ignores it
<raggi>
we can't hinder it though
<jstr>
Security flaws can be managed as they are now - the gem producer issues an update
<kseifried>
jstr: there is 50,000+ gems and outside a few core ones like actionpakc/etc there are _2_ CVEs
<kseifried>
trust me, there are more than 2 security flaws in all those gems =)
<jstr>
OK - flaws != compromised gems, right?
<raggi>
jstr: yeah, that's the "ignore it" method, and that's totally fine, it's just something that should be considered
<kseifried>
jstr: from a user perspective it;'s basically the same thing potentially
<jstr>
Yep, the flaw is the publishers responsibility
jeer has quit []
<kseifried>
jstr: so I fix my gem
<kseifried>
publish
<kseifried>
attacker for example replaces the new gem with old (still signed) gem on a mirror
<kseifried>
now what?
<raggi>
kseifried: well, that can't happen
<kseifried>
we do a check against a CRL/OCSP type thing for each gem install?
<raggi>
kseifried: not at the same version at least
<jstr>
the gem is compromised, we revoke the certificate
<kseifried>
raggi, : sorry, yeah I assume they'd bump the #
<tarcieri>
raggi: remember on RubyForge when someone actually reviewed each request to create a new gem? Is that necessarily a bad thing?
<raggi>
kseifried: the gem repository is WORM
<kseifried>
jstr: but the new version of the gem is fine
<kseifried>
jstr: you're throing the baby out with the bath water =)
<raggi>
tarcieri: yes, i do, i raised this the other day
<raggi>
tarcieri: poor tom
<raggi>
:(
<tarcieri>
haha
<jstr>
Any time a gem is compromised (e.g. replaced with a bad version), we should be revoking certificates
<kseifried>
dude I did 1600 CVE's last year, it sucks but it helps
<raggi>
tarcieri: you remember that this was half of what nick wanted to solve, too
<tarcieri>
raggi: yeah, I do...
<jstr>
That doesn't mean a flaw is discovered, it means someone somehow manages to ship a gem with exploit code in it
<raggi>
tarcieri: rubyforge(1) could easily have been patched to be `rubyforge push <gemname>`
<raggi>
tarcieri: and we'd still have rsync
<raggi>
and backups
<raggi>
and mirrors
<tarcieri>
heh
<raggi>
but we'd also have the gforge UX
* raggi
grins
<raggi>
tarcieri: evans point about external keyservers made me smile too
<kseifried>
we should leverage DNSSEC and carrier pigeons as backup
<namelessjon>
How are you supposed to replace a gem with an old version? Surely the signature encompases the gem metadata, too. It doesn't seem out of place to have the client complain on "I tried to download foo-1.0.0 and instead I got foo-0.0.1" (even aside from the underlying storage being WORM)
<raz>
whoever came up with the idea of storing all that stuff in marshal format should be tarred and feathered
<tarcieri>
raggi: yeah
<raz>
erm, there is no WORM on the internet
<raggi>
namelessjon: your question seems odd, maybe you can rephrase?
<tarcieri>
namelessjon: the existing system computes separate signatures for metadata and data
<namelessjon>
Sorry, that was directed to the talking about version substitution. Even if I could write an old version in place of a new one, the client should complain about how the gem version is not the one it was expecting?
<namelessjon>
(even if the signature otherwise checks out)
<namelessjon>
tarcieri: Ah. That seems less than ideal.
<tarcieri>
namelessjon: yeah, I suggested signing the entire gem, and appending the signature to the end of the file
<tarcieri>
I think that's what RPM does
billdingo-afk is now known as billdingo
<raz>
hmm looks like my patch works out easier than i thought