<tarcieri>
raggi: that's thinking about the problem wrong, IMO
<tarcieri>
raggi: I mean, yes you have to defend against all of that, but the system should be designed from the ground up around the idea that RubyGems.org has been completely pwned and is serving nothing but malicious gems
ereslibre has joined #rubygems-trust
<raggi>
confirm
<raggi>
but i think that's only a small slice of what we need to define really
<raggi>
to ensure that the system as a whole continues to be generally trustworthy
<raggi>
we need to have good ways to recover from that, to make it not be malicious all the time
<raggi>
from a purely technical perspective, you're right, but that's only one of the factors that matters
<raggi>
put it this way
<raggi>
any implementation detial that enables that to be safe
<raggi>
still doesnt' allow us, in the event of that happening
<raggi>
to just say
<raggi>
"fuck it, lets just leave the service as-is"
<raggi>
as that isn't trustworthy
<tarcieri>
raggi: I'm just saying, if your system relies on the integrity of the rubygems.org DNS record, you've already failed ;)
<raggi>
nor is it useful
<tarcieri>
that said, bundler is using TLS, and hopefully checking the certificate?
<raggi>
depedns on what the user does
<tarcieri>
heh
<raggi>
the source lines are explicit
<kseifried>
tarcieri, we'll have end to end signing I assure you (or else I'll be very sad =)
<raggi>
as far as checkign goes, not sure, i think they use the rubygems code
<tarcieri>
kseifried: that's what I'm advocating
<kseifried>
tarcieri: don't worry, we'll not do it poorly/insanely
<raz>
gonna add the other side (display url/download on validation) tomorrow when i get around to it
<raz>
all in all it looks like it won't amount to more than a ~150 line diff to get it all implemented in a clean fashion (the base64 hack obviously needs to go)
<raggi>
urls suffer much worse bitrot than author emails
<raggi>
what's this for?
<raz>
it's the ssh-style proposal
<raggi>
seems orthogonal to me
<kseifried>
yeha
<raggi>
what do urls change?
<raggi>
other than breaking backward compatibility
<raz>
raggi: it's nicer for the user to display "do you trust https://37signals.com/README.md"? than "do you trust ab:23:34:b4:..?"
<kseifried>
raz: ... so much fail.
<kseifried>
urls are not finger prints
<kseifried>
IDN
<kseifried>
uh what else
<raz>
kseifried: it's not meant as a fingerprint
<raggi>
so now i mitm two servers
<raz>
just read the proposal, we even discussed it the other day
<raggi>
mitm rubygems.org and 37signals.com
<raggi>
seems hard
<raz>
your destructivity is also pretty retarded
<kseifried>
raz: seriously, anything that displays a URL with a DNS name to the user is ... fail
<raggi>
ok, ignore list
<raz>
kseifried: alright, let's talk again when your code is up for comparison
<kseifried>
raz: ok
<raz>
raggi: it would also help if you came up with a proposal of your own instead of constantly trolling the people who do actual work here
<kseifried>
raz: we're working on it
<kseifried>
we're actually figuring out what the problem space is first though
<kseifried>
slower but better than pushing code that ends up being a steaming turd
<jstr>
where have we got to?
<kseifried>
raz: so how does your system handle failure/dead urls/etc?
<kseifried>
raz: and what happens when a domain changes hands or gets hijacked?
<raz>
kseifried: dead url equates a lost key. just read the proposal, the rationale is explained.
<raz>
it's only concerned with continuity and not much else, and i never claimed it wants any more than that
<raz>
might serve as a stopgap measure while you solve the remaining problems
<kseifried>
no. stopgap measures are bad
<kseifried>
they cost a lot of time and money to implement, better to do it correctly, once
<raz>
sure. we'll have to see see how long "correctly" will take.
<jstr>
The community is also unlikely to appreciate multiple attempts at getting this right..
<kseifried>
uhm probably about a month or two
<kseifried>
raz: there' s honestly no rush on this, the problem has existed for years across all code repos like this
<kseifried>
raz: this isn't a critical drop everything issue
<kseifried>
redhat fixed it ages ago for ourselves so I'm covered =)
<kseifried>
any solution e create has to be idiot proof for all involved
<raz>
all i did was start a PoC, i really don't understand where the nerdrage is coming from
<kseifried>
it's not rage
<kseifried>
it's tired
<kseifried>
you don't even have a specification
<kseifried>
so you're coding, which is nice
<kseifried>
but... are you cutting down the right trees?
<raz>
erm, the proposal is the spec?
<kseifried>
yeah it's missing stuff
<kseifried>
like.. sigh
<jstr>
kseifried: is someone working on a problem space document at the moment?
<raz>
so what's wrong with coding up the part that works, so one can look at a working example?
<kseifried>
yup
<raggi>
yes
<raz>
the hostility mystifies me
<kseifried>
because it doesn't work
<kseifried>
at least not to solve the actual problem
<kseifried>
dude this is not hostility...
<jstr>
Is it on a Google Doc I can view?
<kseifried>
this reminds me of my friend in compsci
<kseifried>
group project
<kseifried>
4 people
<kseifried>
one guy starts writing code
<kseifried>
like without even figuring out what the end oslution will be
<kseifried>
that kind of activity just isn't super useful
<raz>
for me it's useful to familiarize myself with the codebase
<kseifried>
ok sure
<raz>
personally i'm also pretty sure it will come down to an impl close to this, but i'll let you figure that out yourself over the next few months ;)
<kseifried>
raggi: can youmake google docs team have a word count for selected text, not just the whole doc? :P
<raggi>
i can submit a request
<raggi>
if i had achieved "readability" i'd just send them a changeset
<kseifried>
as a magazine guy it makes me weep =)
<raggi>
but well, the code review stuff, yeaaaaah
<raggi>
kseifried: oh, it will do selection
<raggi>
meta+shift+c
<kseifried>
ohh it does
<kseifried>
holy shit sorry
<kseifried>
my eyes are falling out
<raggi>
haha
* kseifried
dances
<kseifried>
600 words down, 4000 to go =)
<raggi>
yeah at least
<raggi>
i have so much stuff i want to document in here
<raggi>
but i also am worried of causing too much tl;dr
<raggi>
it already feels "long" considering there's almost nothing there
<drbrain>
yeah
<raggi>
and we need MUCH more
<kseifried>
the best aprt is I almost failed grade 5 cause I didn't right so gud!
<raggi>
drbrain: i'd love to hear something abou tht ehigh level goals, even if it's "i don't know"
<kseifried>
raggi, : simple. we have the reqs doc and the notes/additional info doc
<raggi>
unless you're talking about bens presentation that everyones sending around again
<raggi>
oh
<raggi>
no, but i've heard the rant like 3 times
<raggi>
including taking part
<kseifried>
I honestly have not had time to get involved in ruby community/etc which is annoying. to busy putting out fires/building cars and whatnot. I need a helper monkey
<raggi>
(even though i have no right to authority in that discussion)
<drbrain>
I support matz as my BFDL
<kseifried>
raggi, : hey at google do you guys have helper monkeys?
<drbrain>
err, BDFL
<raggi>
benevolent dictator for life?
<drbrain>
yes
<kseifried>
drbrain, : BDFL is the way to go for all things I think. the problem is finding the one
<raggi>
kseifried: we have a concierge service
<raggi>
kseifried: i don't think we're allowed to use them for "general chores"
<kseifried>
raggi: do they do code reviews? ;)
<raggi>
kseifried: although i haven't tried asking them to change the sheets
<raggi>
people keep telling me to use the service more
<raggi>
but it doesn't feel natural
<kseifried>
yah
<kseifried>
I always suspect my mom will beat me if I do something like that =)
<drbrain>
I need to remember to put on my reading glasses more often
<kseifried>
even in hotels I only stopped making the bed a few years ago
<raggi>
kseifried: it's mostly my mum telling me to use em, lol
<drbrain>
especially when reading
<kseifried>
drbrain, : lasik FTW!
<raggi>
kseifried: she uses hers like "bitch sudo do my chores"
<kseifried>
your mom works at google?
<raggi>
no
<raggi>
kpmg
<drbrain>
kseifried: I may as well wait for replacement eyeballs
<kseifried>
drbrain, : I hope so, once my lasik wears off I'm gonna be pissed
<raggi>
drbrain: yeah, i just got glasses
<kseifried>
unless it's google glasses, that would be cool
<raggi>
drbrain: and i hate them. hate hate hate
<kseifried>
hahahaha
<drbrain>
raggi: I have two pair!
<raggi>
kseifried: haha, there's this thing floating around i saw recently
<raggi>
kseifried: "glassholes"
<kseifried>
nice
<kseifried>
on my todo list is building a pocket herf gun =)
<kseifried>
"and that's why you don't text/surf the web when having lunch with me"
<drbrain>
besides glasses, I have to go to a special eye doctor
<drbrain>
they have cool videos of putting corrective lenses *inside* your eyeball
<kseifried>
yeah they made me watch a video of all the procedures possible
<kseifried>
so... ugh
<raggi>
drbrain: i only have a mild astygmatism, but it was apparently giving me headaches and really bad posture
<kseifried>
wait bad posture?
<raggi>
kseifried: yeah, by lunchtime i'd be leaning forward
<raggi>
kseifried: by 10pm i'm basically eating the screen
<kseifried>
ahhhh
<drbrain>
you can't wait too long between glasses, otherwise the adjustment is terrible
<raggi>
drbrain: i used to have 20 20 through +5 and -5, 20 years ago
<raggi>
drbrain: now i have perfect vision, with a 050 astygmatism correction @ 180º
<raggi>
it's pretty minor
<drbrain>
I noticed my eyesight degrading in my left eye around 1998, took another year to need glasses, I couldn't read the chalkboard anymore
<raggi>
yeah
<drbrain>
well, it got really annoying to read the chalkboard
<raggi>
the first day was really noticable
<raggi>
i spent most of the day not wearing mine today, and it wasn't a problem
<raggi>
as soon as my eyes get tired though, then they are important
<raz>
it's always fun when people get new glasses and run into all the things :P
<kseifried>
what gets me is my kid now screams if you take his glasses off
<kseifried>
he knows he can't see without them and freaks out if you try to get them off
<kseifried>
bad genetics FTW!
<raggi>
nah
<raggi>
your iq goes up when you put glasses on
<drbrain>
I am unlucky enough to be slowly losing my peripheral vision
<kseifried>
sweet he'll be a genius then
<drbrain>
which is why I'm waiting on those replacement eyeballs
<raz>
ouch that sounds serious
<raggi>
drbrain: that tech is maturing fast
<raggi>
drbrain: it might well happen in time
<drbrain>
raz: I went in for a checkup on Tuesday and did better than 8 months ago
<raz>
yea, google eyeballs :D
<kseifried>
dude if you told me that I could have a 30 minute surgery and go from 20/400 to 20/20 I;d have though you were a space alien
<kseifried>
but lo and behold, that's _old_ tech now
<raggi>
yep
<raz>
drbrain: that's good. do you know what it's caused by, just aging?
<raggi>
cybernetic eyes are gunna be fucking amazing soon
<kseifried>
I wanna see into infrared/ultraviolet
<raz>
my eyes are holding up surprisingly well, despite ~30yrs of screentime
<kseifried>
and better contrast
<raggi>
yeah, adjustable frequency response
<drbrain>
raggi: I read an article last month about growing eyeballs from stem cells without scaffolding, I think the managed a 0.2mm retina complete with eye cup!
<raggi>
instagram filters, rofl
<kseifried>
raggi, now that is ufnny
<raggi>
"i'm livin in 70s mode"
<drbrain>
raz: protein buildup around the optic nerve causing thinning of the retinal nerves
<drbrain>
it's called optic disc or optic never drusen
<drbrain>
I'm not sure if this answers your question or not
<raggi>
(the doc header)
* raz
struggles to follow what this is about
<raggi>
it claims name is ascii
<raz>
shouldn't it be "verify sig" and then the gem is off the leash?
<raggi>
yet it appears to be utf-8 encoded on most modern systems, in 1.9+
<drbrain>
this code came from RPA
<raggi>
yeah
<raggi>
it's mfp code right?
<drbrain>
so it may reference a tar header that predated UTF-8 being a common thing
<raggi>
oooold
<drbrain>
yup
<raggi>
where'd he go anyway?
<drbrain>
unknown
<raggi>
heh
<raggi>
so we support the magic header
<drbrain>
I don't think we do anything when reading it
<raggi>
no, probably not
<drbrain>
the only use of "magic" I see is in the tar_header
<drbrain>
tar_reader.rb and tar_writer.rb don't reference it
<raggi>
i'm not actually worried about that really
<raggi>
i'd be much more interested to see if we're validating paths properly
<raggi>
and links
<drbrain>
other than my one concern above about tools, the document seems good so far
<raggi>
yeah, it's pretty early days, but i have some more coming, and more time this week
<raggi>
thanks for taking a look
<raggi>
my main aim right now is to try and ensure that the goals are sufficiently general as to not be suggestive, but also representative of what we really need
<raggi>
not what we think we need given prior discussions of potential solutions
<jstr>
raz: my assumption is that we need to untar the gem before we can read any included signature raz
<raggi>
drbrain: look at you and your digest io middleware
<raggi>
hehe
<drbrain>
raggi: it looks like the extract code assumes no directories are present
<drbrain>
just files
<drbrain>
I think if you stuck a directory into a data.tar.gz you'll get an exception if there are any files ini t
<raggi>
drbrain: did you delete some of the implementation at some point? or refactor it
<drbrain>
this is all refactored since the rubygems 1.8 series
<raggi>
regarding size, i mean the tar implementation
<drbrain>
I refactored Gem::Builder, Gem::Format, Gem::Package::TarInput and Gem::Package::TarOutput into Gem::Package
<drbrain>
TarInput and TarOutput clumsily handled creating and unpacking .gem files
<drbrain>
with front-ends in Gem::Builder and Gem::Format
<drbrain>
I think a refactor was missed after the switch to the .gem package format for RubyGems
<kseifried>
refactoring doesn't hhelp if they make the same mistakes =)
<raz>
jstr: yes grasped it by now (4am here) ;) .. imho if one wanted to bother about that we'd probably look into attached the sig at the outsade (tar by default ignores trailing garbage)
<raz>
uh, and spelling doesn't get better at this time of day either
* raz
wanders off for a nap
<jstr>
Too obscure raz. :)
<kseifried>
raz: which .eu are you?
<raz>
kseifried: germany
<kseifried>
nice
<raz>
jstr: well, more plausible than trying to fix all possible vectors of tar - imho ;)
<kseifried>
you think after 40 years tar would be well understood. this really makes me wonder
<raz>
tar ain't so hard, i actually looked into it a while ago
<raz>
but once the filesystem gets involved...
<kseifried>
yeah
<kseifried>
we should just use cloud based object stores FWT
<kseifried>
raggi: hey problem solved, you just need to hook us all up with google fiber
<raggi>
kseifried: just share all your gems in google drive
<raggi>
it'll be fiiiiine
<raggi>
right, i'm getting kicked outta this place, bbaib
<kseifried>
dude I realize I trust google whether I like it or not. email, calendar, docs, all my web search
<kseifried>
you probably know more about me than I do
<raggi>
you know what we know
<kseifried>
you are better at making connections =)
<kseifried>
like the whole unscented hand lotion/pregnancy thing
Perceptes has quit [Quit: Leaving.]
<raggi>
kseifried: er, that was target
<kseifried>
right
<kseifried>
but you can do it as well
<kseifried>
and I kind of wish you would and tell me the results =)
<raggi>
yeah
<raggi>
i personally hope that's where the google now team are headed
<raggi>
but there's a huge cultural / community balance thing in the whole arena
<raggi>
i don't envy the folks that deal with that in the products that lead it
<kseifried>
hahah good
<kseifried>
scroogled =)
<kseifried>
great story
<raggi>
"See what third parties are saying about Google Shopping and the Scroogled campaign. Microsoft does not necessarily endorse all of the content available at these links."
<kseifried>
crazy people site holding a copy of his doc. hah
<kseifried>
CloudFlare is a venture-funded startup that routes around Internet abuse by
<kseifried>
DDoSers, cyberbullies, and copyright pirates to hide behind their servers.
<kseifried>
acting as a reverse proxy. They also encourage illegality by allowing hackers,
jstr has quit [Quit: Computer has gone to sleep.]
<raggi>
lol
<raggi>
the webcam thing particularly makes me laugh
<raggi>
i used to live in the uk
<kseifried>
what makes me sad is how useless they mostly are
<raggi>
er
<raggi>
cctv?
<raggi>
not at all
<kseifried>
unless of course you ascribe to the Basilisk network theory forwarded by Charles Stross =)
<raggi>
heh
Perceptes has joined #rubygems-trust
Perceptes has quit [Ping timeout: 252 seconds]
jstr has joined #rubygems-trust
jstr has quit [Client Quit]
jstr has joined #rubygems-trust
<raggi>
drbrain: ping
teancom has joined #rubygems-trust
<drbrain>
raggi: pong
<raggi>
drbrain: do we want to consider gems.github.com part of the rubygems trust model in this problem spec?
<drbrain>
how so?
<drbrain>
for one thing, gems.github.com is no longer being updated
<raggi>
well, i guess it's just an untrusted mass
<raggi>
ok, i'll kinda leave it as that
<drbrain>
that too
<drbrain>
is there any reason we shouldn't use only cover rubygems.org?
<drbrain>
(and its mirrors)
<drbrain>
-use
<drbrain>
if our model is good we should be able to present it to other places that wish to publish gems, such as internal repositories
<kseifried>
drbrain, : the stuff we're working on will cover all of it
<raggi>
i think it would be irresponsible to not at least consider internal replicas of the infrastructure
<raggi>
but from a design goal standpoint, yes, we're focusing on rubygems.org
<raggi>
it's just that, as you know, gems.github.com has an impact on our trust model, being that it's still in use
<kseifried>
well fixing it at rubygems.org gives us a framework that will work for others generally unless we muck it up
<raggi>
right
<drbrain>
kseifried: yeah, that's the thought I was aiming for
<kseifried>
OTOH we don't want to get infected by over-generalizing-itis
<kseifried>
so we plan to keep it semi sane =)
<drbrain>
bed time
<raggi>
yep
Perceptes has joined #rubygems-trust
craigmcnamara has quit [Quit: craigmcnamara]
jstr has quit [Quit: Leaving.]
workmad3 has joined #rubygems-trust
workmad3 has quit [Ping timeout: 264 seconds]
<theartisan>
raggi: the application users under "Indirectly through other package systems" are covered by the due diligence of the packagers right? or is my bias mistakingly reading that as "linux os packages"
<theartisan>
and ignoring something important
<yorickpeterse>
Morning
kseifried has quit [Ping timeout: 245 seconds]
jstr has joined #rubygems-trust
workmad3 has joined #rubygems-trust
wlll has quit [Read error: Connection reset by peer]
billdingo-afk is now known as billdingo
havenn has quit [Remote host closed the connection]
geal has joined #rubygems-trust
Perceptes has quit [Quit: Leaving.]
dstufft_ has joined #rubygems-trust
dstufft has quit [Read error: Connection reset by peer]
alexspeller has quit [Ping timeout: 252 seconds]
jstr has quit [Quit: Computer has gone to sleep.]
dstufft_ is now known as dstufft
alexspeller has joined #rubygems-trust
geal has quit [Ping timeout: 260 seconds]
workmad3 has quit [Ping timeout: 255 seconds]
workmad3 has joined #rubygems-trust
bfleischer has joined #rubygems-trust
geal has joined #rubygems-trust
bfleischer has quit [Quit: bfleischer]
geal has quit [Ping timeout: 255 seconds]
teancom has quit [Remote host closed the connection]
teancom has joined #rubygems-trust
geal has joined #rubygems-trust
bfleischer has joined #rubygems-trust
stevenhaddox_ has joined #rubygems-trust
<bfleischer>
has anyone suggested keeping hashes of the gems in version control (like the hashes used to verify them?) as a proxy for validating them
rob___ has joined #rubygems-trust
workmad3_ has joined #rubygems-trust
workmad3 has quit [Ping timeout: 264 seconds]
rob___ has left #rubygems-trust [#rubygems-trust]
jacobkm has left #rubygems-trust [#rubygems-trust]
geal has quit [Ping timeout: 255 seconds]
geal has joined #rubygems-trust
DonOtreply has joined #rubygems-trust
Judson has quit [Ping timeout: 245 seconds]
cwgem has quit [Quit: Welp...]
havenn has joined #rubygems-trust
<raggi>
theartisan: well, it comes with some different expectations of trust
<raggi>
which is what i'm documenting
<raz>
the "version control" part is the hard one (which version control? etc. ;))
jfelchner has quit [Ping timeout: 255 seconds]
<raz>
basically one definition of version control is the kernel of the problem (we want a specific version of a gem - how to know which and how to ensure it)
<raz>
s/is the/near the/
jfelchner has joined #rubygems-trust
billdingo is now known as billdingo-afk
kseifried has joined #rubygems-trust
workmad3_ has quit [Ping timeout: 255 seconds]
<bfleischer>
it could be part of the 'gem push' payload
craigmcnamara has joined #rubygems-trust
<geal>
the version control is a nice idea, but managing gems goes against a fundamental property of VCS: "thou shall not rewrite history". With gem management, we should be able to invalidate a gem that was prviously released (because of a backdoor on the developer's side, a developer uploading the wrong version, etc)
Judson has joined #rubygems-trust
jstr has joined #rubygems-trust
<raz>
i'm not sure what problem this is about anyway (the discussion was already way past this point).
<raz>
the main premise that the new system must deal with is what happens when rubygems.org is compromised. version control may be part of the solution, but you'll have to be a little more specific about how you'd implement it.
jfelchner2 has joined #rubygems-trust
jfelchner has quit [Ping timeout: 245 seconds]
<bfleischer>
it appeared to me that a lot of the work that was done to ensure gems weren't compromised could be boiled down to having an authoritative hash of all the gems and a script that can check against it. obviously that's an integrity issue, not prevention
<bfleischer>
and that work is really already done, anyway, for the gems up to a few days ago
<jstr>
bfleischer: the issue with that is you have no way of knowing if a gem you're installing is the same as the one on rubygems.org, or whether it's the same as the one uploaded by the gem author
<raz>
the problem is not creating a hash but giving the user a way to know which hash he should compare to
<raz>
bfleischer: a key-point to consider is that the checksumming work that has happened in the past days is noble but ultimately futile. rubygems.org has been vulnerable since day 1 and nobody can prove that the checksums that were compared to are actually legit. in all likelihood nothing bad really happened - but hte goal for the future is to avoid this situation altogether.
<bfleischer>
raz, jstr maybe a 'gem verify' command for such scenarios that hits an api endpoint? anyway, will look at the discussion there. I was just addressing Scenario 1 for verification.. detection… I dunno
<bfleischer>
raz ok. running in a ruby sandbox would also be a possibility for prevention.. not sure how that affects performance
<raz>
bfleischer: remember the premise, rubygems.org is compromised, you can not trust anything that runs on it (including sandboxes or vms)
<geal>
raz: separate the trust handling (checksum list, signatures, CA, whatever) from the download server
<bfleischer>
ok.. glad you guys are working on it. :) back to lurking
<geal>
managing trust should not be fully automated
<raz>
sandboxing falls under "hardening the host", which is of course also necessary. but with a target as juicy as that you will eventually see another compromise
jstr has quit [Quit: Computer has gone to sleep.]
<raz>
geal: every involved host will get compromised eventually
<raz>
things would be easier if that wasn't a law of nature :)
<geal>
well, if you see things that way, we cannot protect anything, ever :p
<raz>
depends on your definition of "protect". what we can do is mitigate the impact.
<raz>
i.e. there's the difference between "all gems/users being compromised at once" and "selective gem affected"
<raz>
you can also to a degree decide which parties an attacker must compromise *simultaneously* in order to do any harm
<geal>
well, I don't want to push to much for my proposal ( https://github.com/rubygems-trust/rubygems.org/issues/10 ), but the ideas behind it are important: compromising the gems file server should not have any impact on the trust, deciding on which developer to trust is too hard for the end user, decentralize a bit (multiple trust authorities, multiple file servers) for more robustness
postmodern has joined #rubygems-trust
<raz>
geal: your and mine proposal are near identical, just different tooling
<raz>
as such i agree with the general approach ;)
<geal>
rubygems.org as a single point of failure is bad, because of availability problems, trust issues (how can we know if the admins are unfaithful), and recovery (in case of compromise, where do you get back the good data)
<geal>
the most important thing for me is keeping the human in the loop. Automated systems are nice in theory, but inflexible, and once they're compromised, there's no way back. With peopleware, it is clumsy, slow, inefficient, but it allows error recovery
<raz>
well, there's just no way to automate trust. at most for very small values of trust. ;)
<raz>
the proposals for that are up as well, but the working one would require an army of (trusted) volunteers to look at every single gem..
<geal>
in my proposal, the notaries would handle the relationships with developers. Once they have to GPG keys of developers and a contact, everything can be automated, until there's a change of key, a gem needing revocation, or a compromise
<geal>
and paranoid people would still be able to run their own notary :p
<raz>
in practice "notaries" would simply people publishing their trust lists
<raz>
unless you believe into volunteer groups magically popping up left and right, doing very mundane work in a trustworthy fashion.. ;)
<bfleischer>
hasn't linux etc solved this problem, though?
<raz>
bfleischer: it's a different problem
<geal>
raz: well, both are possible. That is not the perfect system...
<raz>
geal: one is realistic, the other is wishful thinking ;)
<raz>
if ponies are in the budget then i'd just go straight for the farm of a few hundred trusted volunteers to review every gem :)
<geal>
the big problem I could face is trust list which are not complete. Notary 1 know about a gem, notary 2 doesn't know it. Do I trust the gem in that situation?
<raz>
geal: yup that's inherent to the approach. 37signals trusts this, rackspace doesn't - user will have to make a policy decision
<bfleischer>
that's what you do with e.g. debian repositories, though
<raz>
bfleischer: debian repos are centrally maintained, if you want to add something you have to go through a maintainer.
jstr has joined #rubygems-trust
<bfleischer>
not if you just add a new source. ruby gems also supports multiple sources
<raz>
bfleischer: if you add an untrusted source to your sources.list then you're in the same spot as rubygems is now
<geal>
there could be three states: 1) I know and trust this gem. 2) I know and don't trust this gem. 3) I don't know this gem. Revoking a gem would put it in 2)
<raz>
s/untrusted/unofficial/
<geal>
raz: adding an untrusted source is how you handle private repositories. It is needed :)
<raz>
geal: yes. well, afaik the debian signing works at the repository level, not the package level.
<pietr0>
also at the package level. the build daemons publish signed checksum files of the packages
<raz>
well, it all hinges on being able to obtain the trusted key (e.g. from debian.org) that says "all files are still the same as we included them"
<raz>
it's a slightly easier problem when not everyone can just add anything they want :)
<geal>
which means bureaucracy, something the debian project is very good at
<raz>
hrhr
<pietr0>
signing by gem authors and signing by rubygems.org are independent and solve different issues
<jstr>
not necessarily pietr0
<raz>
pietr0: in my opinion the signature by rubygems.org is worthless (but there are people around here who disagree with that)
<pietr0>
i somewhat disagree with that
<raz>
unless rubygems.org actually looks at the gem before signing it, all it tells you "yes, this once went through rubygems.org"
<raz>
which, if you happen to download the gem from rubygems.org, is kind of self-evident ;)
<pietr0>
it tell not only "yes, this once went through rubygems.org" but also "it hasn't changed since it went through rubygems.org"
<raz>
pietr0: well, that's true, but in what case is that interesting information?
<pietr0>
it would prevent a MITM and folks wouldn't have had to spend days verifying gems
<raggi>
so, the 80 man hours of work that happened after the poc was uploaded, would only be reduced by a rubygems.org signature, and would not be helped at all by author signatures that lack a central trust root.
<raz>
pietr0: when rubygems.org is compromised then the attacker can create that signature for any gem he likes
<raggi>
so while it may not help gem users, it does help distributors.
<raggi>
there are many customers in this syste.
<jstr>
raz: SSL vendors deal with this problem all the time
<raz>
what stops the attacker from replacing rails-1.0.gem, and resigning it? (when he has access to rubygems.org to replace the file in first place?)
<raz>
jstr: you mean commercial CAs?
<jstr>
raz: if you keep the CA/signing information on a non-exposed server then you can secure things to some degree
<raggi>
raz: component isolation
<jstr>
raz: if the private key used for signing is known only to the developer then he can't resign it
<geal>
jstr: unless you have a way of detecting the server compromise, someone could using the intermediate CA for a long time to sign malicious gems
<raz>
raggi: wishful thinking
<jstr>
geal: true, but having a way of detecting server compromise is a prerequisite to running a server
<raz>
jstr: that's why i disagree with the CA. if people are encouraged to trust the CA by default then a compromise can go undetected for a very long time.
<geal>
gems signature should be they way you verify that they were note tampered with. Otherwise, what is the point?
<raggi>
i give up
<jstr>
raz: that is true for any solution - probably least true with a CA or another similar cryptographic approach
<jstr>
raz: the benefit of a CA is that the community at least has the option of revoking a developer certificate and making further distribution impossible through the official channels
<raz>
jstr: no, it's the fundamental difference between WoT and a hierarchic CA
<geal>
jstr: the problem does not come from the CA itself, but the automated sugning
<jstr>
geal: The signing is done by the developer under the CA model, and isn't automatic
<raz>
jstr: the same can be achieved in any model. as long as the user trusts rubygems.org he can trust a blacklist that it publishes.
<raz>
he can in fact trust *any* blacklist he wants.
<kseifried>
you guys are 1) over thinking this and 2) going down rabbit holes. 3) you don't have a requirements list so it's basically pointless to figure out solutions.
<jstr>
raz: What you're claiming about CA is basically true with WoT too for any reasonable short period of time
<jstr>
kseifried: where is the requirements list?
drbrain has quit [Remote host closed the connection]
<bfleischer>
re: 'from rubygems', MITM, SPF-like signing could help, no?
<jstr>
kseifried: it's perfectly reasonable for people to discuss potential solutions here
<raz>
jstr: not sure which claim you were referring to now
<jstr>
raz: compromised gems can go undetected for a very long time
<raz>
jstr: small but important difference; with a compromised auto-CA the attacker can backdoor any gem at any time. in WoT he can only compromise the gem that he has stolen the author-key for.
<jstr>
raz: you're assuming that author keys never change, which is not the case
<raz>
jstr: where am i assuming that? :)
<raz>
in my model the poor user has to acknowledge every key change by hand
<pietr0>
raz: yes, but if we separate signing from publishing and make the mirrors pull from rubygems.orgthen the pull process can see that a gem was changed and fail/alert people.
<pietr0>
raz: laos, i'm not saying that the only thing we should do is signing by rubygems.org.
<pietr0>
raz: i think that signing by rubygems.org would improve the current situation for both rubygems.org volunteers and gem users.
<raz>
pietr0: yea, most of this has already been discussed in the proposals on github anyway, no point repeating it here (and possible getitng the details wrong while doing so:))
<raz>
pietr0: the one thing i'm saying is: an auto-signature must not override trust. if it does then i must be able to turn it off and have a reasonable way to find signatures manually (i.e. authors msut be encouraged to publish them)
<geal>
raz pietr0: and discussing it on github leaves a trace of the discussion, so that's more useful IMO
<pietr0>
unfortunately i haven't had the time to read the gituhb issues during the weekend. i have convinced my boss to let me use some of my work hours to help with rubygems.org so i'll catch up today
<pietr0>
raz: i totally agree
<raz>
personally i'm just waiting for the uber-proposal from raggi and kseifried to drop
<pietr0>
i think that signing by both authors and rubygems.org, an improved version of what debian does, would be needed
<geal>
pietr0: I was going to bed when someone pointed me to the issues. I ended up reading and commenting until 3am ^^
<pietr0>
nice
<theartisan>
is there any scope for making the metadata in a gem file json?
<theartisan>
the serialized stuff just doesnt sit well with me.
<raz>
theartisan: don't know but strongly agree
<theartisan>
the only package manager that should be forgiven that is npm :)
<raz>
whoever came up with that idea should not be allowed near a keyboard again
<theartisan>
or pypi considering json is basically valid python too
<theartisan>
raz it probably made sense at the time, what was the availibility of good json decoding libraries when the first gem format was drafted?
<raz>
theartisan: no excuses, it's just incompetence
<theartisan>
20 20 hindsight is a powerful thing ;p
<raz>
you need no hindsight to know that you don't feed user-provided input to a parser that about equals eval()
<theartisan>
static languages are normally more fun, you get to run arbitrary code on the CPU
<pencil>
conner: you're right...
<conner>
pencil, once jruby-openssl + bouncy-castle-java are installed manually, it works again
<conner>
so jruby installs from last week are working
<pencil>
ah...
<conner>
trying to stand up a new VM this morning explodes
vbatts|work has joined #rubygems-trust
<pencil>
your openssl version probably doesn't support subjectAltName: rubygems.org matched
<theartisan>
can we not make those dependencies of rubygems on jruby?
* theartisan
knows little about jruby
<conner>
jruby comes with some sort of limited ssl support
<theartisan>
i tend to treat it the same way as jython, something to be ignored
<conner>
I wish
<vbatts|work>
jruby 1.7 includes openssl support
<conner>
unfortunately, this is a problem app
<conner>
*production
<conner>
vbatts|work, I can't just upgrade jruby without going through QA
<conner>
the fact of the mater is this was working last week
<conner>
and now it's not
* raz
chuckles at the freud typo ;)
<theartisan>
aren't scala and groovy basically ruby for java done nicely? is there even a reason to run ruby on the jvm? :) </troll>
<conner>
raz, there may be some truth in that typo :)
<geal>
raz: I think that was more OOP's fault. Before OOP: "let's store strings and int". After OOP: "I should be able to store whatever object I want"
<vbatts|work>
conner: i'm late to the conversation. sorry
<conner>
vbatts|work, summary: a clean jruby install this week can't even install jruby-openssl
<vbatts|work>
conner: clean install of which version?
<conner>
vbatts|work, it was working last week and installs from last week with jruby-openssl installed still have a working jgem. The SSL cert changed on the 30th
<conner>
vbatts|work, 1.6.8
<vbatts|work>
(jruby and jruby-openssl)
<raz>
geal: yes it was of course a bit tongue-in-cheak. ;) however, point remains, there's no excuse, it's just plain old incompetence.
<conner>
vbatts|work, 1.6.8 does not come with jruby-openssl
<raggi>
conner: you can configure that out
<raggi>
conner: which ssl cert changed?
<stevenhaddox_>
conner: Someone asked about something similar in #rubygems earlier. Is there a way to get past your SSL error by manually downloading the gem and installing with `gem install -l <path>/<gem_name>.gem` ?
<raggi>
conner: rubygems proper ships with the CA cert, not the rubygems.org cert, so even if rubygems.org is reissued, it shouldn't fial
<raggi>
conner: even if they foolishly shipped the rubygems.org cert (i don't know why they'd change this), you can use gem configuration to repoint at diffferent certs
workmad3 has joined #rubygems-trust
<conner>
raggi, how?
<raggi>
conner: set ssl_ca_cert to a path to a valid cert in your gemrc
<raggi>
put the gemrc in either RbConfig::CONFIG['sysconfdir']/gemrc, or ~/.gemrc, or set ENV['GEMRC']
<conner>
the big question is why was this change made?
<stevenhaddox_>
raggi, conner: I can't vouch for this 100%, but there was discussion about reissuing the certificate just in case the original box had allowed it to be tampered with iirc.
<raggi>
conner: rubygems proper doesn't break
<raggi>
conner: and the error you pasted has nothing to do wiht the cert change
<raggi>
conner: i doubt jruby's gem breaks either, actually
<raggi>
conner: that's you're missing a required dependency for gem
<conner>
raggi, no, I'm not
<conner>
raggi, the fix is to manually download and install jruby-openssl
<conner>
a 100% puppetized build that worked last week fails today
<conner>
the only thing I have to install manually now to fix it are bouncy-castle-java and jruby-openssl
<raggi>
conner: i'm pulling jruby's source to see if something is different than it should be
<raggi>
conner: this looks no different from the normal rubygems source. the http connection has not even been opened yet, when the error occurs - it cannot be anything to do with infrastructure changes
<stevenhaddox_>
raggi: for what it's worth, downloading manually and installing with -l flag worked for someone else in #rubygems earlier as well.
<raggi>
stevenhaddox_: yes, i know, and connor already knows that
<conner>
yes, and that does fix it
<conner>
the question is what has changed in the last week
drbrain has joined #rubygems-trust
<raggi>
stevenhaddox_: i'm trying to point out that this failure he's suffering has nothing to do with infrastructure changes on our heend
<raggi>
conner: it's not us that's changed, there's no rubygems.org infrastructure involved at all in your error
<conner>
raggi, could you try to reproduce the failure by running jgem from 1.6.8 yourself?
<raggi>
conner: it hasn't got that far, by that point
<raggi>
conner: yes, i can reproduce it
<raggi>
oh, heh
<raggi>
actually
<raggi>
i might be wrong
<conner>
raggi, and as I said, this was working last week
<raggi>
sec
<raggi>
nope, not wrong
<raggi>
the SRV record stuff is only rubygems 2.0
<raggi>
not present in this bundled version
<conner>
so what your saying is that jruby 1.6.8 has never had a working gem implimentation
<raggi>
besides, that actually wouldn't make a difference
<raggi>
conner: not for https sources, no
<raggi>
conner: did you change your source list to https?
<raggi>
in a gemrc or something?
<stevenhaddox_>
raggi: wouldn't the http => https redirect kill it even if he hadn't? (if 1.6.8 doesn't support https at all)
* stevenhaddox_
is just curious
<raggi>
stevenhaddox_: we installed a redirect?
<stevenhaddox_>
raggi: yeah.
<stevenhaddox_>
part of the aws migration
<raggi>
ok, that was it then
<raggi>
conner: that's the cause of your issue
drbrain has quit [Ping timeout: 255 seconds]
<raggi>
conner: another option for you, besides fetching with curl or the like first, is to change your source in gemrc to http://production.cf.rubygems.org
<raggi>
conner: but i would recommend against that option, as it removes all mitm protection
<raggi>
conner: you're better off fetching over verified https, using curl or the like
<raggi>
or bundling jruby-openssl with your build
<raggi>
stevenhaddox_: thanks, i missed that
<stevenhaddox_>
raggi: not a problem.
<raggi>
conner: and sorry for being wrong :(
<raggi>
stevenhaddox_: i have mixed feelings about this suggestion
<raggi>
stevenhaddox_: but maybe we can special case jruby-openssl
conner has quit [Ping timeout: 240 seconds]
<raggi>
stevenhaddox_: at least for a little while
<stevenhaddox_>
raggi: I wouldn't be the one to ping on that. evan / vertis / others in #rubygems-aws would have opinions I'm sure.
<stevenhaddox_>
perhaps a tweet from headius with a gist is the quick way to inform?
<stevenhaddox_>
raggi: I'm guessing you'd have more influence in gaining his attention though
<raggi>
stevenhaddox_: yeah, that's probably wise either way
drbrain has joined #rubygems-trust
<stevenhaddox_>
gah... was hoping conner was still here
Judson has left #rubygems-trust [#rubygems-trust]
drbrain has quit [Ping timeout: 264 seconds]
<stevenhaddox_>
raggi: sent a couple of tweets to headius. We'll see what happens.
<raggi>
stevenhaddox_: thanks, it shoudl help :)
conner has joined #rubygems-trust
<stevenhaddox_>
conner: if you come up with an automated script to get past the download / install process with jruby-openssl could you send me a gist I can share with others?
<stevenhaddox_>
I've only looked at JRuby, never actually created an app with it and can't try it out now, but would love to help share with others who may ask.
workmad3 has quit [Ping timeout: 245 seconds]
<conner>
stevenhaddox_, will do. I'm trying to finish up the borked production deployment over this
<conner>
stevenhaddox_, I will have to code up a puppetized fix but that probably won't be until late this afternoon
<stevenhaddox_>
conner: no sweat, I appreciate it. I'm on twitter (@stevenhaddox) or via e-mail works too. I'll PM.
stevenhaddox_ has left #rubygems-trust [#rubygems-trust]
schisamo has left #rubygems-trust ["Be back later"]