whitequark changed the topic of #rubygems-trust to: Fork at github.com/rubygems-trust :: https://github.com/rubygems-trust/rubygems.org/wiki/Overview :: Hacking With Gems: http://www.youtube.com/watch?v=z-5bO0Q1J9s :: Logs at http://irclog.whitequark.org/rubygems-trust
deus_rex has quit [Quit: leaving]
Perceptes has joined #rubygems-trust
workmad3 has quit [Ping timeout: 255 seconds]
serge has quit [Quit: Leaving]
<theartisan> https://github.com/rubygems-trust/rubygems.org/issues/4 updated alternative proposal (basically use GPG)
Perceptes has quit [Quit: Leaving.]
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
<kseifried> 3rot13, there ya go
<kseifried> worked for 3des
<raz> :P
<kseifried> tarcieri, : you're writing https://github.com/rubygems-trust/rubygems.org/issues/4 ?
<kseifried> anyways you need to specify full key fingerprint, keyid is to short/easy to collide
craigmcnamara has joined #rubygems-trust
craigmcnamara has quit [Client Quit]
cbetta_afk has joined #rubygems-trust
cbetta_afk is now known as cbetta
cbetta has left #rubygems-trust ["["Textual IRC Client: www.textualapp.com"]"]
Perceptes has quit [Quit: Leaving.]
mephux has left #rubygems-trust [#rubygems-trust]
Perceptes has joined #rubygems-trust
Perceptes has quit [Ping timeout: 252 seconds]
<samkottler> kseifried++
<kseifried> samkottler, : hey boss
<samkottler> kseifried: how's it hangin?
<kseifried> long day off hah
<kseifried> glad monday is PTO
<samkottler> kseifried: nice :-) I could use some of that
<kseifried> mmm I can't wait until I win the lottery and can hire assistants
<kseifried> this is my dream: http://www.monkeyhelpers.org/
<kseifried> but I fear like Seinfeld the monkey might try to kill me
<samkottler> kseifried: in the meantime http://www.fancyhands.com/ is awesome for personal stuff
<kseifried> yeah to bad it's all embargoed info
<samkottler> kseifried: heh indeed
<kseifried> actually.. hrmm
<kseifried> seriously this might be worht a serious look
<kseifried> how are they for goggling answers, like 1 page reports?
Perceptes has joined #rubygems-trust
Perceptes has quit [Ping timeout: 252 seconds]
jeer has quit [Remote host closed the connection]
jeer has joined #rubygems-trust
havenn has joined #rubygems-trust
havenn has quit [Ping timeout: 248 seconds]
jfelchner has quit [Ping timeout: 252 seconds]
jfelchner has joined #rubygems-trust
<raggi> kseifried: you probably have a concierge service you can use for most of that stuff though ;-)
<kseifried> I wish
<raggi> hehe
<raz> the crypto veterans will probably chuckle when they watch us churn our heads over problems they have long discussed ;)
<kseifried> raz: no worries I'll get SST onto it =)
<raz> kseifried: that's great, we really need an adult on the case :P
Perceptes has joined #rubygems-trust
Perceptes has quit [Ping timeout: 244 seconds]
havenn has joined #rubygems-trust
<kseifried> uhhh... well we have people who are over 18 so legally I guess...
<kseifried> I seriously still feel like a kid with credit cards
<kseifried> I don't get this adult thing.
<kseifried> Antiarc, : yeah I've start poking people @redhat about PyPI/hackage/CPAN/etc.
<dstufft> That's well known
<dstufft> FWIW
<dstufft> although it's kind of annoying whoever posted that decided to post working code
<kseifried> I think the best case is rubygems fixes this and produces a solution model/framework and then we sell it to the rest of the world
<Antiarc> Yup. Just pointing it out since it illustrates the need for verified SSL (which is kind of "duh" for software written today)
<kseifried> dstufft: even with ssl mitm is gonna cause all sorts of problems :P
<dstufft> Fun fact
<dstufft> Python stdlib doesn't have a way to verify SSL in 2.x
<dstufft> 3.x does though :V
<kseifried> I wouldn;'t worry about ssl much, about 5% of sites get it somewhat right
<kseifried> and detals like that
<raz> dstufft: well, i can beat that. ruby net/http would randomly segfault until very recently.. no ssl required ;)
<dstufft> Although PyPI does have a SSL certificate, it's not a not trusted by default one
<dstufft> "because"
<dstufft> fuck if I can find a real reason for it
<dstufft> I can bitch about PyPI for a long time :/
<raz> let's not get carried away with looking at the *other* rubygems code ;)
<dstufft> I still need to get Crate.io secure from BEAST and CRIME :/
<dstufft> I need more hours in the day
<raz> dstufft: is BEAST really relevant? i don't remember the details but iirc it was a rather cornerish corner case?
<dstufft> It is yes, but It can be mitigated against so why not
<kseifried> BEAST is semi relevant, mostly you need an XSS as well to exploit it
<dstufft> Yea
<dstufft> I think there are still valid XSS's on PyPI
<dstufft> though I haven't checked recently might not be
<dstufft> not sure if Richard fixed them or not :V
* raz only recalls the SSL-check site description marking the solution about as problematic as the problem itself ;)
<kseifried> as a rule if a web site exists it has XSS
<kseifried> a good way to check your ssl is https://www.ssllabs.com
<kseifried> it's pretty sanbe, nice colors
<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
<whitequark> kseifried: it's webscale!
* kseifried twitches
<whitequark> kseifried: https://gist.github.com/560087
<raz> i bet i'd sooner get linux rename /dev/null to /dev/google than getting google to reply to anything i send them
<raggi> haha, that's my gist for shardnull isn't it
<whitequark> raggi: oh this is YOUR gist
<whitequark> the world is damn small
<kseifried> wow
<kseifried> that is literally the FIRST use I've ever seen of mingw
<raggi> kseifried: you shoudl read the roflscale troll
<whitequark> kseifried: mingw was used in my high school programming course, as a part of dev-c++
<whitequark> it did fine
<raggi> it's like my favorite irc exchange ever
<tarcieri> raggi: can I use Node.js to shardnull, and if so, will it be faster than Mongodb?
<whitequark> rofl.
<kseifried> no I have nothing against mingw, just never seen anyone ever use it
<raggi> tarcieri: well, it only uses 4 libeio threads
<whitequark> kseifried: it is way less hassle than both cygwin and vc++. so...
<raggi> tarcieri: so you're limited by that right
<raggi> tarcieri: parallism, how does it work?
<whitequark> raggi: are you sure he wasn't kidding?
<whitequark> that is really way too stupid
<raggi> whitequark: yes
<raggi> whitequark: it wasnt' my first exchange with him, sadly
<whitequark> i don't even know if this is very funny or very sad
<raggi> whitequark: which is why i flipped the troll switch so fast
<raggi> whitequark: well, you either rage, cry, or troll
<tarcieri> raggi: I think we need to increase the libeio thread pool for more shardnulls
<raggi> tarcieri: just fork bro
<raggi> it'll be fiiiiiiiine
<tarcieri> lol
<raggi> maybe they should just mmap it instead
<raggi> i heard mmap was a fast thing
<raggi> right?
<raggi> tarcieri: so, did anyone port that grep thing to node yet?
<tarcieri> lol
<kseifried> ok back to work for me, seeya all on twitter and so on
<tarcieri> no, but this guy ported ack to C, and it rules
<raggi> kseifried: btw, what timezone you in?
<kseifried> that's difficult
<kseifried> legally: MDT
<raggi> k
<raggi> haha, i see
<kseifried> my body is sort of somewhere in the pacific
<raggi> well, it's not work time pacific :)
<kseifried> I generally work like 13:00-17:00 EST, then 20:00 to like 04:00 EST
<kseifried> mon-fri, then on weekends only like 4-6 hours on weekends/day off =)
<raggi> yeah
<raggi> ok, i'll keep that in mind, try to catch you when you're on, and not when you're not
<kseifried> raggi: email works well, also ping me on skype
<raggi> as it sounds like you're at least as busy as i was 6 months ago
<raggi> :)
<kseifried> yeah it;s how I live
<kseifried> I'll probably slow down a bit when my kids get older
<raggi> yeah, i told myself i'd slow down after christmas
<raggi> then security shit happened...
<kseifried> hahah
<kseifried> the bad news is if you live in security land it's basically always like this
<raggi> well, i just got out of startup land, i'm not planning on jumping on the mass cve train any time soon
<kseifried> it's not so bad
<kseifried> I;ve been forcing people to make good requests that take much less time to process
<whitequark> tarcieri: hm, you're not on #ruby/#ruby-lang?
<tarcieri> butno
<tarcieri> err
<tarcieri> no
<raggi> butno, sounds like a new form of "hell fuck no"
<tarcieri> lulz
<whitequark> tarcieri: where would be the appropriate place for discussing deep_freeze/move semantics?
<whitequark> I'm interested in these ideas
<tarcieri> whitequark: well, brixen is interested in "thread affinity" for objects
<kseifried> threading is a fad, I wouldn't worry
<tarcieri> lulz
<raggi> haha
<kseifried> I wonder, what is a good way to teach children about parallelism
<raggi> 4kb stacks should be enough for anyone
<whitequark> tarcieri: a bit of context: I'm writing a (not so) ruby compiler.
<tarcieri> rofl raggi
<tarcieri> whitequark: nice
<raggi> kseifried: throw two balls at them
<kseifried> that might work (twins)
<whitequark> tarcieri: in the sense that I'm not going to add that to any of existing implementations.
<raggi> kseifried: so they already get parallelism
<kseifried> somewhat
<raggi> kseifried: teach them locking
<kseifried> that aprt they get, one will distract you and bam, the other one is on top of the stove
<raggi> haha
<raggi> well, then there's always the dining babies problem
<tarcieri> rofl
<tarcieri> are dining babies and the sleeping babysitter problems related?
<raggi> i suspect so
<kseifried> oh that's easy, I've already divided my house into containment zones with several levels of controls :P
<kseifried> primary zones do not have nice carpets, that's something you get to learn the hard way
envygeeks has joined #rubygems-trust
envygeeks has left #rubygems-trust ["Bye"]
<raggi> heh
<raggi> i didn't read it all the way last time
<raggi> i didn't spot the ettercap line
<raggi> hehe
<raggi> i guess it's time to expect a bunch of new script kids
<kseifried> script kiddies (hopefully) grow up
<raggi> watch out for nexgenhacker101, he's probably grown up
<kseifried> and this is why I have a sack of door knobs waiting for my kids to learn to pick them
<kseifried> oh wow. you w... argh
<tarcieri> raggi: tracer tee
<raggi> tarcieri: t there t there t there
<tarcieri> raggi: that video is lulz, can't tell if troll or serious
<raggi> gotta love the arg validation too
<tarcieri> http semicolon
<raggi> http dot dot
<tarcieri> traceroute: unknown host http://google.com
<tarcieri> :(
<kseifried> awww.. well at least he's trying
<kseifried> it's kind of cute, like a puppy pee on the carpet
<raggi> lol
<kseifried> wait how come feeding a url worked.
<raggi> kseifried: it matches a regex or the like
<kseifried> connection speed. heh
<tarcieri> last two digits of an IP address stand for IP server connection number
<kseifried> wow
<kseifried> he really got this... backwards
<kseifried> like how do you get clued enough to run tracert and then fail this badly
<tarcieri> kseifried: I assume it's a troll
<kseifried> no... I've seen this before
<tarcieri> yeah I've seen it before too :P
<kseifried> like this type of thing, but for real
<tarcieri> o
<kseifried> people who claim... oh waht's a good one
<kseifried> well like the classic "I have raid so I don't need backups"
<kseifried> "but what if the building burns down?" "... raid?"
<raggi> oh, but we did that
<raggi> "we have s3, so we don't need backups"
<tarcieri> we have a web of trust, so we don't need a CA
<raggi> epic fail
<tarcieri> lulz
<kseifried> see
<kseifried> you to have seen it
<raggi> yep
<raggi> oh, lol, there's a netbios hacking video
<kseifried> what was that uhhh
<raggi> (default share)
<kseifried> windows coammnnd to remote query it
<raggi> i ahvent' seen the actual attack
<raggi> but yeah
<kseifried> like list all shares/suername and stuff
<raggi> probably just the default share win95 stuff
<kseifried> yah
<kseifried> like before everything got firewalled
<kseifried> gah I am a crazy old man like my dad was before me. eeek.
<raggi> oh, well, the share browser never listed the $shares
<raggi> :)
<raggi> what was that favorite tool though
<raggi> the one with the epic backdoor
<tarcieri> here you go: http://www.nazifag.com/tony.mp3
<raggi> sub7
<kseifried> oh the monster truck.
<raggi> tarcieri: what's this?
<tarcieri> heh
<tarcieri> something a friend made
Perceptes has joined #rubygems-trust
<tarcieri> ohai Perceptes
<tarcieri> lulz
<Perceptes> sup
<tarcieri> Perceptes: here you go, listen to this: http://www.nazifag.com/tony.mp3
<Perceptes> lol, i heard that before
<tarcieri> heh I probably linked it
<Perceptes> if i was going to impersonate someone's voice, i would pick someone with a less distinct voice
<tarcieri> rofl
<tarcieri> yeah
<Perceptes> also, asshurtmacfags is the best twitter handle ever
<tarcieri> confirm
<tarcieri> lulz
<Perceptes> shit like that makes me regret using my real name
<Perceptes> oh well
<tarcieri> hahaha
<raggi> tarcieri: lol
<tarcieri> next time someone in here asks for my "security credentials" I'm gonna link 'em that
<raggi> haha
<kseifried> wait wait wait. we can get credentials?
<tarcieri> lulz
<kseifried> I want a badge too!
<tarcieri> yeah, could also deep link Douglas Crockford Principles of Security
<raggi> kseifried: yeah, let me put an epxloit in rack and push an "RCE FIX" release
<tarcieri> "now that you've verified my credentials you will surrender to me all of your personal secrets"
<tarcieri> rofl
<raggi> where should i have it mail the creds to?
<raggi> :trollface:
<kseifried> actually that would be kind of cool. "Internet Police, Ruby Division"
<tarcieri> lulz
<kseifried> or like "Internet Police, Vice and 4chan"
<tarcieri> I will just claim 303 and leave it there
<raggi> "we got more bots than anonymous"
<tarcieri> said audio file... courtesy the 303
<raggi> are there actually any usable stats anywhere on how many ruby devs there are out there?
<tarcieri> no idea
<kseifried> like ruby/rails/gems, or users?
<raggi> developers
<raggi> users is huge
<kseifried> sorry I means users = devs using ruby
<kseifried> hrmm. I imagine a lot, I mean figure 10-20 on average per startup
<raggi> tbh, i'd take any researched numbers for any combo of the above
<raggi> haha
<raggi> yeah
<raggi> but for a long time i was lower than the community thought
<raggi> but the number of rack downloads since jan really surprised me
<kseifried> well ... I bet it's a LOT more than you think
<kseifried> judging the cloud space, pretty much everything is rubyt here
<kseifried> except for openstack
<raggi> right
<kseifried> plus exploit stuff, metasploit is all ruby
<raggi> i guess i mean 1st level users
<raggi> like "actually write ruby code"
<raggi> (knowing it's ruby)
<tarcieri> the number of Celluloid downloads surprises me, heh
<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?"
<tarcieri> raggi: rofl
<tarcieri> seems good
<raggi> tarcieri: omg, did you see thredis?
<tarcieri> yeah that's actually one of my coworkers
<kseifried> I do worry a bit what happens when in 20 years we're still stuck at ~3Ghz and 4000 cores
<raggi> kseifried: that already happeened to me
<raggi> kseifried: they're just not on a single bus layer
<kseifried> I mean on a single chip
<kseifried> yeah
<kseifried> so what happens in like a 16 sockets 64000 core 1U rack server
<raggi> cache contention :'''''''''(
<kseifried> and 1terabit ethernet or something
<raggi> fucking 8 core cpus are already dog shit slow for many things
<raggi> makes me angry
<raggi> i think about the state of schedulers and i get really sad
<kseifried> hahaha funny story there
<kseifried> trying to test schedulers on single core systems, can't find any
<raggi> lol
<tarcieri> hyperthreads are fun
<tarcieri> was listening to Cliff Click talk to some guy at Datastax about that
<tarcieri> JVM scalability on 32 core machines
<raggi> if i met cliff click
<raggi> i would have soooo many questions
<tarcieri> haha
<tarcieri> yeah I asked him quite a bit of shit when I met him at Strange Loop
* raggi is jealous
<tarcieri> chilled with the guy for an hour and a half
<raggi> "I said today was thinking of Hash are backed by null roflscaling experience: If it proves P=NP via Use."
<kseifried> dude we all know the google solved P=NP and rents the solution out to the NSA.
<tarcieri> lulz
<raggi> oh yeah
<raggi> they don't need echelon anymore
<raggi> we just deployed some fiber and shit
<kseifried> haha I love reading oracle response timelines
<raggi> wait
<raggi> hashes of signed jars
<kseifried> yah
<raggi> please tell me that's hashes of jar sigs, not hashes of jar files
<kseifried> oh hahaha
<kseifried> trust me
<kseifried> here ya go
<raggi> but jar files are totally padable
<kseifried> shush.
<kseifried> ah the files we deal with are off the maven/etc repos
<kseifried> so in our case it works quite well
<raggi> lol
<raggi> yeah
<kseifried> I mean if someone hacks the *** out of maven iit's fubar anyways
<kseifried> basically the main vector for the victims DB is people using out of date jars
<raggi> it makes sense
<kseifried> and also to track since there's so much insane embedding
<raggi> it's just back to the sigs inside vs sigs outside argument
<raggi> inside == content level exploits are still viable vectors
<raggi> outside == content level exploits can be handled by revocation processes
<kseifried> yeah the idea here is that the devs are the bad guys, not attackers =)
* raggi nods
<raggi> they don't tend to have malicious intent
<raggi> most of the time
<kseifried> neither does my two year old when he gets a fork and tries to stab me with it
<tarcieri> heh @ http://pastie.org/256094
<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.
<Antiarc> However, I haven't thought that through.
<havenn> Antiarc: thx!
<raz> havenn: also don't miss mine! https://github.com/rubygems-trust/rubygems.org/issues/5 :P
<raz> well, best do just read all of them ;)
<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.
<raz> i've scribbled up a quick list of scenarios: https://github.com/rubygems-trust/rubygems.org/issues/7
<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> manveru: o_O
<Malf> hah true
<manveru> err, gpg
<raz> manveru: there are various proposals up right now, see https://github.com/rubygems-trust/rubygems.org/issues
<tarcieri> manveru: who's "we"?
<manveru> the people making and installing gems
<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?
<tarcieri> I saw the automatic x509 stuff
<tarcieri> yeah that's not really what I had in mind, but would make for a nice alternative as what I had in mind really isn't practical
<manveru> well, it seems like it has a lot of points where mistakes can be made
<manveru> but not sure if there's any system that doesn't have that problem
<raz> well, it doesn't solve scenario #1
<raz> that's the main problem i see
<raz> or rather, the chain-history-server may solve it, but the automatic CA adds nothing - just a point of failure and complexity
<tarcieri> yeah not really a fan of an automatic CA, but it has a trust model of sorts. just really easy to attack comparatively
<raz> well the keyword is "automatic"
<tarcieri> yeah
<raz> a signature that anyone can obtain is just not worth much
<tarcieri> it wouldn't really be "anyone can obtain"... you'd be trusting the integrity of RubyGems.org
* tarcieri updates his proposal to note: least authority, does not trust rubygems.org
<raz> no, integrity of rubygems.org has nothing to do with it
<raz> as i understand it you say "hi, please sign my gem" - and it signs
<tarcieri> if rubygems.org were the auto-signer, then yes, it would
<raz> in what way?
<tarcieri> rubygems.org would be the one signing gems
<tarcieri> therefore it would have something to do with it :P
<raz> and what does the signature tell me about the gem?
<tarcieri> not much, that it made it through rubygems.org at one point in time, possibly before it was compromised
<tarcieri> again, not a fan
<raz> hehe
<manveru> pretty much every proposal leaves you vulnerable with a pristine machine talking to a poisoned rubygems.org
<raz> manveru: mine doesn't
<tarcieri> manveru: mine doesn't!
<tarcieri> lol
<raz> tarcieri: which was yours?
<manveru> yours is?
<tarcieri> still writing it
<manveru> @raz
<raz> it doesn't solve it but unlike some other proposals it also doesn't pretend to
<raz> i.e. it just offloads it on the user
<tarcieri> it punts on the problem
<tarcieri> yay
<raz> (no false sense of security etc.)
<havenn> What are the highest priorities? Tried to put together a list (pardon my noobness :P): https://gist.github.com/4703413
<raz> havenn: you may want to merge with https://github.com/rubygems-trust/rubygems.org/issues/7
<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
<manveru> raz: well... so 80% of people will point public_key_https_url to https://github.com/foo/bar/tree/master/README.md ?
<raz> manveru: yep
<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
<raz> manveru: well, it prompts you every time.
<raz> you will run "gem update rails"
<raz> and it will prompt you: "woops, unknown key for rails, do you want to download from github.com/fo0/bar?"
<tarcieri> thar ya go
<raz> and at that point you should probably be suspicious (why a new key for rails? does that url look legit?)
<raz> it's the same as when SSH prompts you about a changed host-key
<manveru> "seems like keys changed since the last version, please make sure it's trustworthy and type yes 15 times"
<raz> tarcieri: nice, reading :)
<raz> manveru: 15 times in 15 different languages ;)
<raz> manveru: it will basically look like this prompt http://symbiosis.bytemark.co.uk/lenny/docs/figures/ssh-key-fingerprint-warning.png
<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.
<havenn> Ooh, I thought I'd seen the Ben Smith talk but dun think I have... Here is link if anyone else wants to watch it: http://www.confreaks.com/videos/1243-aloharuby2012-hacking-with-gems
<tarcieri> havenn: it's in the topic, FYI
<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
<theartisan> is that not enough?
sferik has quit [Quit: ["Textual IRC Client: www.textualapp.com"]]
<tarcieri> what do Windows users do?
<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> theartisan: GPG doesn't really "solve that"
<jstr> GPG solves that as well as x509 theartisan
<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
<raz> let's not get too heated, shall we :)
<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
<raz> hrm
<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
<tarcieri> heh, Evan Phoenix on GPG: https://twitter.com/evanphx/status/298201886908088320
<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
<raggi> presumably, this is what we want to work from: https://github.com/rubygems-trust/rubygems.org/wiki/Overview
<theartisan> that was the initial goals yes
<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
geal has joined #rubygems-trust
alexmreis has quit [Quit: alexmreis]