<tarcieri>
does this seem like a reasonable scheme to you?
<raz>
exactly, the funny number being a key id
<raz>
well, above the confirm/deny it would also say "btw this key is trusted by 37signals"
<tarcieri>
o_O
dstufft has joined #rubygems-trust
<raz>
that's how WoT works, remember? :)
<tarcieri>
and how do you know 37signals is 37signals
<raz>
because the 37signals key has 235983476 signatures saying "this FANBOI trusts DHH"
<raz>
and yes, *there* some due diligence makes sense, and will obviously happen
<tarcieri>
I would suggest you read the archives of the cryptography mailing list on WoT vs PKI
<raz>
why do you keep pointing into all sorts of directions rather than answering my very precise question?
<tarcieri>
the central algorithm of the main open source project I'm working on is based on distilling truth from a web of trust
* raz
adjusts desk lamp
<tarcieri>
it is an extremely difficult problem
<raz>
one that doesn't affect us, we don't need truth, only gems
<tarcieri>
because you don't know what the fuck you're talking about and you're trying to lecture me on the very problem I am trying to solve, which is very, very, very hard
<tarcieri>
I don't even know how to relate to you
<raz>
you can just say inspector
<tarcieri>
I would suggest, for starters, you review the papers linked on the Cryptosphere's suggested reading section
<tarcieri>
particularly the Sybil Attack
<raz>
and really, i've asked a simple question, or have i said something wrong?
<tarcieri>
no, it's just you're incredibly ignorant and overbearing
<raggi>
and all this signature shit is a waste of time
<raggi>
so basically, we're done
<raggi>
it's already published
<raz>
raggi: that's not right and was explained about 3 hours ago
<tarcieri>
raz: long story short, yes you can do that, but you need a better algorithm for extracting "trust" than is presently available in any software like that
<tarcieri>
raz: and really, it all becomes about predictions, not trust
<raz>
tarcieri: well, sorry for being trollish here :)
<raggi>
i'm heading out anyway
<raz>
tarcieri: yes, you are tackling a real problem and a hard one
<raggi>
tarcieri: hopefully i'll catch up wiht you over the weekend
<tarcieri>
raggi: yeah for sure man
<raggi>
but no pressure, if you're busy
<raggi>
ciao
<raz>
tarcieri: i think i'm just saying this is really a bit of a crazy scope creep
<tarcieri>
raz: I'm just saying without an authority, you have no trust model
<tarcieri>
you have a trust model because you have a neck to wring
<raz>
tarcieri: honestly, you still haven't answered what kind of vetting the CA should realistically do
<raz>
i mean, this thing is run by volunteers, what do you expect them to do?
<raz>
for how many thousands gem authors?
<tarcieri>
I've spelled it out several times... and I think what freenode did for groups isn't bad
<tarcieri>
and yeah, basically let people submit figments of their online identities
<raz>
well, i remain skeptical
<tarcieri>
with some basic requirements
<tarcieri>
I need to write up a full proposal
<raz>
it will always be trivial to inject a "fake" identity
<tarcieri>
OAuth to Github and confirming they control the projects they want to publish gems for would be nice
<tarcieri>
sure, that's what revocation is for
<raz>
while the only thing we actually care about is continuity (or reputation)
<tarcieri>
"we"
<raz>
well, me and the other guy that said it earlier today :)
<tarcieri>
you have no answer for a gem which is compromised when you install it for the first time
<tarcieri>
among other problems
<raz>
and how does your model provide that answer for a gem installed the first time?
<raz>
he has a github account so his gem is probably not malicious?
<tarcieri>
and "install it for the first time" per whatever level of granularity you're tracking "continuity"
<tarcieri>
if someone is malicious, revoke their certificate
<raz>
so he makes a new one and pushes a new gem, just like he would in any other model?
<raz>
this doesn't seem like a solvable problem to me
<Antiarc>
certs have to be scarce to make revocation have any real teeth, which isn't sustainable under a volunteer model
<raz>
Antiarc: perhaps we could hook it into bitcoin ;)
chipc has joined #rubygems-trust
chipc has joined #rubygems-trust
chipc has quit [Changing host]
<tarcieri>
having any manual review process at all creates (artificial) scarcity
<raz>
i mean.. gem mining.. get it? ;)
<Antiarc>
tarcieri: That's my point; you'd have to have review to add scarcity.
chipc has left #rubygems-trust [#rubygems-trust]
<Antiarc>
And review isn't really durable under a volunteer model
<tarcieri>
Antiarc: that's exactly what I'm proposing
<raz>
i really still don't understand what you are going to review
<raz>
i make a repo with a nice hello-world gem, and ask you to review that
<Antiarc>
I gather you mean something analogous to EV SSL certs?
<tarcieri>
raz: identities of individual authors and the projects they intend to publish
<raz>
then i add totally malicious code to that repo and push it as a gem
<tarcieri>
Antiarc: I don't think any existing CA operates in the way I'm thinking, heh
<raz>
so stricter than EV certs? ;)
<Antiarc>
tarcieri: I'm probably misunderstanding you then
<tarcieri>
Antiarc: the closest thing in existence is probably Freenode Groups
<tarcieri>
which are struggling
<tarcieri>
I linked their process earlier
<tarcieri>
this is why I'm asking how many people will care in 2 months, heh
<raz>
but this one really sounds way out there to me
<Antiarc>
I want a system that is more or less self-sustaining with minimal oversight once it's launched
<tarcieri>
Antiarc: I kind of feel the same way
<Antiarc>
But that's me being a lazy programmer who hates manual work :P
<raz>
Antiarc: agree 100%.. and i would add: because anything else will not survive anyway. it will just get dumbed down until it's feasible.
<Antiarc>
I think there would be a review board whose job it is to issue revocations and keep the CA running, but there shouldn't be much to do beyond that.
<tarcieri>
Antiarc: I'm all for anything that can't be pwned by an active attacker
<tarcieri>
and actually has a trust model
<Antiarc>
Well, I think the problems that we aim to solve should be enumerated.
<raz>
i really wonder who you expect to manage this CA with many thousand customers, revokes, lost keys, etc?
<Antiarc>
I see:
<Antiarc>
1) Backdoored code
<tarcieri>
I just want to write a straight up proposal
<Antiarc>
2) Identification and booting of malicious authors
<tarcieri>
raz: me
<tarcieri>
lol
<raz>
tarcieri: lol ;)
<tarcieri>
if that's what it comes to!
* raz
smacks tarcieri with his desk lamp ;)
<tarcieri>
would rather have a group of volunteers
<Antiarc>
3) End-user ability to verify authenticity of software before installing it, up to a trustable root (or sub-root)
<raz>
Antiarc: i think 2) is not doable. i think the only thing really doable (and which the initial discussion was about) is to ensure reasonable continuity - i.e. the last 5 versions of rails gem were pushed by key X, so the next version should *probably* come from the same key or i'd better show a scary warning
<tarcieri>
I would like to have a system where I can go I asked for gem X, and according to authority Y I can trust the certificate chain for gem X's signature, therefore I can trust this gem
<Antiarc>
raz: 2) is doable with a revocation framework, but it's a lot of work.
<raz>
Antiarc: well yea.. i don't see how you'd do that, short of collecting actual identities (drivers licenses etc?) and.. umm.. playing small government
<Antiarc>
tarcieri: That's basically already in place with the existing x509 infrastructure, except that a) there is no established trust root, and b) any user can sign any cert, which makes the chain of trust too easy to pollute for the non-aware consumer.
<tarcieri>
Antiarc: whole point being needs a trust root
<Antiarc>
Yup.
Hamled has joined #rubygems-trust
alej has joined #rubygems-trust
<raz>
lol, this is going in circles
<Hamled>
sup alej
<raz>
the trust root is only worth anything if it actually verifies every single gem
<tarcieri>
raz: it doesn't need to verify every single gem, just verify the signers
<Antiarc>
It seems like step 1 could be "rubygems set up a CA and a cert signing app, submit your cert, rubygems reads the email out of the cert, sends an authentication email, once verified the cert is signed and returned"
alej has left #rubygems-trust ["Leaving..."]
<tarcieri>
raz: although I could see value in a service that actually *does* verify every single gem
<Antiarc>
That gets you a way to tie a signature to verified control of the email.
<tarcieri>
raz: sounds like a startup idea ;)
<raz>
tarcieri: so ivan, 14yrs old from russia really wants to publish his first hello-world gem. does he get blessed by the CA or not?
poikon has quit [Remote host closed the connection]
<raz>
he also doesn't know anyone and nobody knows him, he's just a kid
<tarcieri>
raz: I... discuss noobs in my blog post. perhaps you should (re)read it? ;)
<raz>
tarcieri: keyword? "noob" appears two times but apparently not in this context
<tarcieri>
lol yes?
<tarcieri>
perhaps you don't know what a noob is?
<raz>
It should be noob-friendly, and not require that people are particularly well-known or have a large body of published software, but should still perform due diligence in ascertaining someone’s identity.
<tarcieri>
seems good?
<raz>
so.. in other words.. we're down to "identity" again
<raz>
so ivan must send his drivers license?
<tarcieri>
not necessarily
<Hamled>
how about require a donation of at least $50 with an identifiable payment source
<tarcieri>
rofl
<Hamled>
$50 USD I guess I dunno
<raz>
actually i think by now you agree yourself that this idea is not very feasible, you just don't want to say it ;)
<tarcieri>
seems good Hamled
<tarcieri>
raz: o_O
<tarcieri>
raz: you assume a lot about people. it's a bad trait
<Hamled>
so why can't you use established PKI practices for signing ruby gems
<raz>
tarcieri: well, what identity then? only thing you said was github, facebook etc. .. that's not serious or is it?
<deus_rex>
Hamled: may I suggest a currency more in the spirit of OSS, the bitcoin?
<tarcieri>
Hamled: that's kind of like what I'm proposing
<tarcieri>
raz: yes, that's serious
<raz>
Hamled: because vetting every single gem or gem-author doesn't seem very feasible for a volunteer organization
<Antiarc>
you're conflating identity with vetting
<raz>
tarcieri: and what problem are we solving with that again?
<tarcieri>
raz: having a trust model
<Antiarc>
identity is simply being able to know that Joe is who he says he is in some other trusted context
<raz>
tarcieri: so ivan's gems won't throw a warning on installation, because the CA says so?
<raz>
ah n/m, we're going in circles
<tarcieri>
raz: yes, nor will countless others that would otherwise have to be manually scrutinized
<raz>
doesn't matter, whichever you implement will be an improvement over what we have now
<dstufft>
raz: FWIW I'm with you on verifying continuty and not much else :V
<dstufft>
broken security/identity validation is worse than no security/validation
<raz>
and if it sucks people will just fall back to the code that's already in there right _now_ (the dirt simple x509) and i won by knock-out last round ;)
<tarcieri>
dstufft: yeah I agree, was... also one of the points of my blog post
<raz>
dstufft: thanks.. i was starting to eye my beer here suspiciously ;)
<tarcieri>
raz: that's kind of what I'm suggesting
<tarcieri>
there's nothing particularly wrong with the existing signature system which necessitates moving to a different scheme
<dstufft>
raz: I'm not a rubyist though :) I'm trying to solve the same problem over here in Python land so figured i'd join up here and see what folks were discussing since I've been thinking through this for a bit now
<Antiarc>
Seems like you could just for continuity in the signing chain, which allows for co-signing and project inheritance
<Antiarc>
just check*
<Antiarc>
So I own project Foo, I've been signing it with my cert, and I had the project off to Joe. I sign Joe's cert with mine, and the trust chain remains intact.
<Antiarc>
He can continue to deploy builds of the gem with his cert without anyone complaining.
<raz>
dstufft: yea it's not trivial, but i think we're in overengineering stage right now ;)
<dstufft>
raz: seems like it :)
<tarcieri>
o_O
<Antiarc>
step 1: Ya'll start signing your gems today, and worry about chain of trust tomorrow :P
<raz>
Antiarc: step 1b: *enforce* signing gems (reject other pushes)
Ben__ has joined #rubygems-trust
Ben__ has quit [Client Quit]
<dstufft>
^
<tarcieri>
kinda funny how anyone who's actually working on rubygems or cryptography is on the same wavelength as me, and everyone else is out there in la la land
<raz>
and 80% of the immediate problem (rubygems.org MITM) is solved
<Antiarc>
raz: That's done by rubygems. Us, as authors, have a responsibility to start signing our gems regardless of the infrastructure in place.
Ben__ has joined #rubygems-trust
<tarcieri>
trust models are hard
<dstufft>
Antiarc: No, any unsigned gem is an avenue for MITM
<tarcieri>
I'd like to take steps to create one
<dstufft>
Don't make a trust model they are hard and you'll get it wrong
<raz>
Antiarc: doesn't work that way. it costs the authors nothing, so force it to overcome they inherent lazyness (most of them are males, remember)
<Antiarc>
dstufft: That's why I'm saying to start signing them :P
<Antiarc>
raz: I've signed all my gems and filed issues on a couple dozen of the most popular gems encouraging them to do the same. Several are moving on it already.
<Antiarc>
Community pressure works just fine.
sferik has joined #rubygems-trust
<tarcieri>
sup sferik
<sferik>
hey tony
<raz>
Antiarc: why not force it and release the rubygems team from having to go through the pain of the past days again when it gets hacked again?
<deus_rex>
raz: wow, misandry much?
<Antiarc>
speaking of, tarcieri, I notice that celluloid isn't currently signed ;)
<raz>
deus_rex: just realism, i'm male myself ;)
<tarcieri>
Antiarc: confirm, will fix
<Antiarc>
raz: Why not do *both*?
<raz>
Antiarc: ask them nicely *and* force them? ;)
<Antiarc>
I'm not arguing against enforcing signing, I'm just saying that anyone with a gem can bump things up a notch *right now* by signing their stuff.
<tarcieri>
Antiarc: feels a bit silly signing stuff without a trust model to me though ;)
<raz>
yep sure
<Antiarc>
We can do that right now with exactly zero extra work by anyone. That's a good step 0.
<dstufft>
tarcieri: SSH doesn't have a trust model
<dstufft>
known_hosts works pretty well
<Antiarc>
tarcieri: I trust that you control the github repo. I can verify it against the pubkey on github if I feel paranoid!
<raz>
but it only really helps the rubygems guys when all gems (or the large majority is signed)
<Antiarc>
If your github repo gets jacked, then yeah, we're back to square one :P
<raz>
the rest they would have to verify again from whatever md5 sources
<tarcieri>
dstufft: most people wouldn't even notice an SSH MitM though
<tarcieri>
Antiarc: likewise what if someone pwns my tty and takes over my ssh-agent
<dstufft>
tarcieri: Most would because known_hosts will go "HEY THERE ASSHOLE, SOMETHINGS AMISS"
<raz>
tarcieri is really out to solve P=NP tonight ;)
<tarcieri>
know how that can happen? see link in topic
<Antiarc>
tarcieri: Indeed. It's not anywhere near a full fix, but it means that if Rubygems gets exploited again I can ensure that my copy of Celluloid is blessed.
<tarcieri>
Antiarc: unless you installed a pwned version to begin with
drbrain has quit [Ping timeout: 255 seconds]
<tarcieri>
raz: and no, I just care about security
<dstufft>
known_signatures + allow people to opt into verifying by hand their own keys, allow people to import their own trust roots so if someone insane wants to go set up a CA they can
<Antiarc>
No, because I can check the gem sig against the pubkey on github, not the pubkey in the gem.
<dstufft>
ta da done
<tarcieri>
dstufft: doubt it, most people would delete the offending line and reconnect
Ben__ has quit [Client Quit]
<raz>
tarcieri: to my untrained eye it seems you keep trying to solve chicken/egg problems by adding more chicken ;)
<namelessjon>
dstufft: But how many random ssh servers do you connect to, vs gem/pips do you install?
<Antiarc>
If people are bypassing known_hosts without specific knowledge that the host changed in an allowed fashion, they deserve what they get :P
<tarcieri>
raz: you add a neck to wring
<deus_rex>
we can't really expect to protect people from their own recklessness to that extent, tarcieri
<tarcieri>
raz: someone actually tasked with that responsibility
<raz>
tarcieri: poor volunteers and their necks :/
<tarcieri>
lulz
<tarcieri>
I'm volunteering
<tarcieri>
it's my neck
<tarcieri>
or someone else's, doesn't have to be mine
<raz>
as a side-point, i *really* like that today anyone can just push their gem without any friction
<raz>
making that harder may not be catastrophic, but i'd find it sad
<tarcieri>
yes, and nobody's verifying their gems
<namelessjon>
I don't think you scale that well, tarcieri ;)
<tarcieri>
namelessjon: haha, yeah really needs to be a network of volunteers
<tarcieri>
doesn't seem like anyone else gives a shit so, *shrug*
<raz>
tarcieri: i never install a gem before having looked at documentation and stuff. otherwise i usually wouldn't even know the gem exists. the missing link for me is being able to verify that the documentation i'm looking at, and the gem i just installed actually amtch up.
<tarcieri>
raz: do you look at the code, and if so, how closely?
<tarcieri>
also see link in topic
<tarcieri>
lol
<raz>
tarcieri: probably equally close, and often closer, as any volunteer vetting agent would
<dstufft>
namelessjon: the differerene isn't really all that meaningful there
<tarcieri>
I'm not even suggesting the volunteers look at the code
<ldk>
I missed everything that happened here today due to a vps crash, anyone who was around care to summarize?
<raz>
or are you now volunteering to carry out pen-tests against every new gem? ;)
<tarcieri>
just authenticate the publishers
<raz>
ldk: i think someone had an irc log but i'm not sure who
deus_rex_ has joined #rubygems-trust
<deus_rex_>
I agree with dstufft that anything like a CA should be opt-in
<raz>
ldk: it was a *lot* of text, summarizing would be hard
craigmcnamara has quit [Quit: craigmcnamara]
<ldk>
raz: thanks, that's alright. any big decisions made that you noticed?
<deus_rex_>
I should also note though that I have absolutely no authority to speak on security
<tarcieri>
I don't think anything short of some kind of central trust authority is practical
<Antiarc>
The whole point of a CA is that it can automate signature verification
<tarcieri>
even if that trust authority is 100% automatic
<raz>
ldk: not that i know of. there's still a bit of two camps (CA-style versus web-of-trust style)
<tarcieri>
Antiarc: o_O
<Antiarc>
Otherwise it becomes a manual process where you have to chase down and trust each individual gem's pubkey
<deus_rex_>
tarcieri: maintaining a central trust authority is *wildly* impractical, and would require a huge amount of effort for comparatively little gain, in my view
<tarcieri>
Antiarc: oh, I see what you mean, and yes, exactly
<dstufft>
a central authoity isn't pratical, you'll do it wrong you'll get hacked. Then your trust will be useless and you'll be in a worse situation
<Antiarc>
tarcieri: Sorry, realized that was a bit ambiguous once I typed it out :P
<tarcieri>
deus_rex_: the gain is you don't have to do
* raz
hugs deus_rex_ discretely in a non-gay manner
<ldk>
raz: thanks, that's where it was when i left last night
<dstufft>
and when you do, you're going to open up the entire ruby community to getting pwned silently, instead of that one guy who happened to first hit rubygems between compromise and discovery
<tarcieri>
I've addressed all these arguments
<tarcieri>
already
<tarcieri>
last night
<tarcieri>
before you even made them
deus_rex_ has quit [Ping timeout: 252 seconds]
<tarcieri>
in the system I'm proposing, there is one dot
<raz>
Antiarc: ideally we tatoo the CA key onto the volunteer and then bury him 6ft deep in an undisclosed location
<tarcieri>
that's it
<dstufft>
I read your blog post tbh, it was junk
<Antiarc>
exactly, tarcieri
<Hamled>
when I make a native program for windows, for example, I can sign it with my company's key. This key is simply one that we acquired through a trusted CA, there's no centralization. Microsoft only needs to sign stuff for drivers, basically.
<Antiarc>
Or more precisely, one dot per distribution network
<Antiarc>
(rubygems, gemfury, etc)
<tarcieri>
dstufft: lol christ, okay do you have more specific feedback?
<tarcieri>
dstufft: perhaps some specific point you want to nitpick?
<Hamled>
I see no reason why you can't let people sign their own Gems, have the gem installer say "This gem was built by X" if the signature is validated through a cert chain that the installing computer trusts, or say "This gem's authorship could not be verified" otherwise
<Hamled>
then its entirely up to the author if they feel like signing their gems or not
<ldk>
raz: where do you come down on the gpg/x509 debate?
<tarcieri>
Hamled: where do the cert chains come from?
<tarcieri>
Hamled: and why should you trust them?
<ldk>
i'm leaning toward gpg at the moment
saturnflyer has joined #rubygems-trust
<dstufft>
tarcieri: Sure. You aren't prepared to run a CA. The fact you're suggesting it is pretty much proof that you aren't prepared to run one.
<Hamled>
tarcieri, if you want to ensure maximum likelihood of installee computers trusting the cert, then you get them signed by a trusted CA
<Hamled>
for example, VeriSign
<raz>
ldk: i'm saying just use what we have, force the authors to sign their gems, add a field to the gemspec where they can put the location of the pub key (https url). deploy, rinse, and then think calmly about how to make it nicer.
<Hamled>
if you have your company's cert signed by VeriSign and then you sign your gem with your company's cert, 99% of all computers will trust it
<tarcieri>
dstufft: that's not very specific, but please continue, I'm sure you have some substantive point to make
<Antiarc>
raz: Relying on anything in the gem to specify where to find the pubkey is fatally flawed.
<tarcieri>
dstufft: so far I hear "CAs are hard" yeah I am aware
<Hamled>
you don't have to create your own CA chain for the gem host, because then 99% of computers *wont* trust it
<raz>
Antiarc: yes. but it's a baseline, and with the help of common sense will work most of the time.
<dstufft>
tarcieri: So what then makes you qualified to run a CA
<tarcieri>
dstufft: paranoia
<dstufft>
lol
<raz>
Antiarc: i.e. most users will probably raise an eyebrow before pulling the rails public key from ivan.p0wnz.uu.ru
<Antiarc>
raz: No it won't. In the event of a compromise, the gem would still "verify" because it would point to the attacker's pubkey. A false sense of security is worse than no security.
<raz>
Antiarc: note what i didn't write: i didn't write anything should auto-verify.
<raz>
:)
<tarcieri>
Hamled: not really a fan of linking back to someone like Verisign and that's irrelevant for a system like RubyGems where there isn't a trust root in existing CAs anyway
<raz>
Antiarc: i said, deploy the infrastructure, and force the gems to be signed. don't force anyone to verify yet.
<Hamled>
tarcieri, I guess my question is why is VeriSign / Comodo / GeoTrust / Godaddy not good enough
<Hamled>
tarcieri, eh
<Antiarc>
Doesn't really matter. Relying on the gem to tell you how to verify it is inherently broken. That's the whole reason that chains of trust exist.
<raz>
Antiarc: that pulls rubygems.org out of the MITM trap, which imho is a worthy first milestone
<Hamled>
why don't you want to link back to the core set of most trusted authorities? And what does this have to do with RubyGems itself? RubyGems is simply the delivery mechanism for the data which itself has the signature. If you get the data from anywhere, including RubyGems, and you can verify the signature with a known trusted CA, then that seems completely sufficient to me?
<dstufft>
Hamled: theortically because they cost money which is sort of a an unreasonable burden to expect a 14 year old kid to pay money just to release a gem, plus there are many problems with PKI and the existing PKI folks
<Hamled>
I never said you should require it
<raz>
Antiarc: it doesn't rely on the gem, it relies on the USER
<tarcieri>
Hamled: I was proposing an entity distinct from RubyGems
<raz>
Antiarc: you keep thinking automatic, i did not say and not mean automatic :)
<Antiarc>
raz: If you're putting it in metadata, it'll be automated. We're programmers. That's what we do.
<raz>
lol
<Antiarc>
I've already said that we can do this, except via an entirely out-of-band verification mechanism.
<raz>
Antiarc: OOB as in?
<dstufft>
Hamled: If you don't require it then all it takes is soemone installing a gem to overwrite your hosts file, or if ruby folks have some sort of config file to tell bundler or whatever the fuck rubyists use to point to rubygams.org
<Antiarc>
Sign your gems, put the pubkey somewhere trusted that isn't rubygems, problem solved. Mine are in my projects' github repos.
<raz>
ah you mean central key repo?
<dstufft>
Antiarc: lol no
<dstufft>
"somewhere trusted"
<raz>
Antiarc: great. you just said the exact same thing just with different words. ;) we agree.
<Hamled>
dstufft, if you're worried about that then don't install unsigned gems
deus_rex has joined #rubygems-trust
<Antiarc>
dstufft: You're missing about twelve hours worth of context around the discussion. Consider that before you get too uppity.
<Hamled>
if this concept has been solved for native code distribution which doesn't even allow you to view the source if you're paranoid about what you're getting, how is it a problem for gems
<Hamled>
I guess the way I look at it is, if you make your whole own CA / trust chain, then you're putting a lot of burden on yourself to be capable of actually verifying the identity of the people to whom you grant signed certificates. I think if someone wanted to attack ruby users by uploading a malicious gem they'd be far more inclined to try it if all they had to do was fool you into thinking they were someone else when you granted them the
<raz>
i think we can slowly drop the CA idea by now?
<tarcieri>
raz: lol jeezus christ
<tarcieri>
THE WHOLE IDEA IS OFF THE TABLE
<Antiarc>
security is hard, let's go ride bikes
<raz>
oh sorry i didn't read everything the last few lines
<tarcieri>
can we drop the WoT idea yet? because anyone who knows fuck all about cryptography realizes they're fundamentally flawed?
<raz>
tarcieri: my impression was that you're the only one arguing for CA right now
<Malf>
Took a while to catch up but it seems we've got a solid flamewar in the works here :)
<raz>
(perhaps i'm mistaken)
<Malf>
ahaha bikes it is!
<Antiarc>
I'm in favor of a root trust, as well.
<tarcieri>
raz: uhh, see also raggi and drbrain
<tarcieri>
raz: you know, people who actually work on rubygems
<raz>
tarcieri: ah okay, they're not around, i just missed it
<tarcieri>
raz: seriously guy, you're being a dick
<tarcieri>
PKI is not "off the table"
<raz>
because i did that desk lamp thing earlier? :)
<tarcieri>
it is a debatable option
<raz>
okay okay
<raz>
then perhaps we should talk about who is gonna actually implement one of the two or both
<Malf>
lol PKI is both
<Malf>
so I hope it's not off the table
<Hamled>
hey dstufft how much do you know about certs n stuff
<tarcieri>
raz: I'll try to write up a serious proposal tomorrow
<raz>
i think the two options have been pretty well specified by now?
<dstufft>
Antiarc: FWIW i've been debating this problem for about a year now wrt Python/PyPI and i've gone through, talked over with experts, and rejected a lot of these ideas already :)
<raz>
tarcieri: that sounds like a good idea!
<Antiarc>
dstufft: Then might I recommend that you bring that knowledge to good use, rather than being condescending and trollish?
<Antiarc>
You're kind of coming across as a jackhole right now
<raz>
dstufft: pfft.. look, we're 2 days in and almost done! ;P
<Malf>
Isn't that the ruby way? Find a difficult problem, say "That looks easy!" and then charge forward blindly
<raz>
yeh, let's perhaps cut down on the aggression a bit, i'll try to do it myself
<Malf>
:)
<tarcieri>
Malf: lol
<raz>
Malf++ :)
<dstufft>
Antiarc: probably am, I'm a bit angry on the internet at times
<dstufft>
:V
<Hamled>
V:
<dstufft>
CA's are basically a non starter, you'll start out with the best intentions I'm sure. You'll be a very prime target for anyone who wants to exploit a large number of people. Unless you're ready to drop a lot of money to setup and maintain the infastructure to do so you'lre going to make the system worse.
<dstufft>
Trying to establish a full blown WOT is really hard, and most people won't go to the bother to verify identities, plus it makes it dificult to be a new guy on the scene and publish you gem
<Antiarc>
Rubygems is already a very prime target for anyone who wants to exploit a large number of people.
<Malf>
Having worked closely with a variety of folks who worked for/at CAs I have to agree on the difficulty there.
<tarcieri>
dstufft: do you read the cryptography mailing list?
<tarcieri>
dstufft: because what you said is literally the opposite of what everyone with a clue concluded on a thread about PKI vs WoT
jacobkm has joined #rubygems-trust
wlll has joined #rubygems-trust
<dstufft>
"the cryptography mailing list"
<Malf>
There can be only one...
<tarcieri>
yes, the cryptography mailing list
<tarcieri>
well, there are two
<tarcieri>
the old one is defunct and doesn't even work anymore
<Malf>
One for the CA folks and one for the WoT folks? :)
<Malf>
aww
<tarcieri>
lol
<tarcieri>
I'm talking about cryptography@randombit.net
<raz>
feel free to add that to a wiki or something, or to wildly lobby against it :)
<tarcieri>
raz: well, you have a self-referential trust problem there
<raz>
tarcieri: yes, i know.
<raz>
we talked about that for about an hour i think ;)
<raz>
the good thing is, i don't actually have that problem, the user has it :P
<tarcieri>
dstufft: can't find the thread I'm thinking of, and this web UI is fucking terrible
<dstufft>
tarcieri: I'm kinda amused at a crytpo mailing list using software that doesn't encrypt it's passwords
<tarcieri>
it was shortly after... some immediate cert got pwned
<tarcieri>
lol
<dstufft>
s/encypt/hash/
<raz>
tarcieri: on a more serious note. if the user decides to trust foobar.ru/pubkey.txt for the rails-gem, then yes, that's unfortunate. in the normal case he should do the exact same common sense vetting that your proposed CA volunteers would do. ("Oh, github.com/rails/pubkey.txt? ok, might be legit)
<dstufft>
raz: biggest problem with your proposal is that you're farming your trust out to random servers on the internet
<raz>
dstufft: actually to the intersection of rubygems.org and $random_server
<tarcieri>
raz: yes, except the volunteers could do that one time, instead of repeating the verification N times (or M * N times for M boxes and N gems)
<raz>
where $random_server will be github.org in 99% of cases
<raz>
tarcieri: see bullet 4, sentence 2 :)
<tarcieri>
lulz
<raz>
we have discussed a few options (short of going full CA), i.e. that whole WoT story
<raz>
no need to repeat that, my proposal is out, your turn :)
<raz>
(and yes i'm fully aware how mean that is, as yours will be infinitely harder to write :P)
<Antiarc>
codifying the pubkey location as a component of the gem is the problem. A fully out-of-band verification measure is the only way to make that work with any measure of trust. Yes, this means you have to discover the location of the canonical pubkey on your own - that's the whole point.
<raz>
Antiarc: yup. if i wanted to be straight-edge i'd have skipped the "announce public key url in the gem" part
<raz>
just let the stupid user go find it himself
<raz>
but imho *if* it is used as a starting point like this, then people would quickly come up with ways to build a sort-of-WoT around it
<raz>
out of the very same lazyness argument that someone (you?) earlier mentioned
<raggi>
that's not true
<raggi>
we have that today
<raggi>
and no one solved that
<raggi>
todays solution is a WoT solution
<raz>
raggi: we don't have that. the key difference is that signing is not enforced and nobody bothers to verify signatures because hardly any gem has one.
<namelessjon>
raz: One issue with your scheme. Popular gems are the most attractive targets. They also tend to have the largest groups working on them, with potentially many people who can mint releases. So the gems you're most interested in pwning have the most frequently changing keys to trust.
<raggi>
raz: more have them than you think
<raggi>
raz: and it was enforced once, people just turned it off
<raggi>
i'm really done having this argument
<raz>
namelessjon: yup that's indeed an interesting problem, but i *think* a surmountable one
<Antiarc>
namelessjon: There can be a master key per project, and project members' keys can be signed with that key. No need to change keys around.
<Malf>
I thought it was using X.509 certs today. Is that really a WoT?
<raz>
raggi: yes, let them turn it off. having the signatures is still a win even if most people don't verify them.
<tarcieri>
Malf: until there's a trust root, it's a WoT
<raggi>
Malf: you have to share trust yourself, there's no central authority
<raggi>
Malf: and it might not be built into the tool, but you can share trust today
<raz>
namelessjon: Antiarc was faster, yes, that should work
<Malf>
I guess I'm not seeing the web part of it if each individual is manually authorizing individual things
<Malf>
raggi: Right that's why I was questioning the web part
<raggi>
Malf: well, then you just made my point...
<Malf>
thanks for the clarification
<raggi>
:)
<raz>
welp, anyway. it's there, i'm looking forward to the competitors. :)
<raz>
i think moving to gists or some ml is more productive from this point
<Malf>
Mainly I didn't realize X.509 had a WoT model option built into it. I thought it was entirely hierarchical
<raggi>
it's neither
<raz>
Malf: x.509 can be shaped into near everything, it's ... a horrible beast
<Malf>
guess I'll have to go searching for more detailed docs on that then
<Malf>
been a while since I've read up on it
<raggi>
honestly, openssl may support something less over the top
<raggi>
but x509 is very standard
<Malf>
right
<raz>
well, one step lower is plain RSA
<Malf>
I mean I know it came from the old directory services stuff
<Malf>
and went through lots of fun processes to get where it is today
<Malf>
everything I'm reading still seems to claim it's a strict hierarchy as opposed to a WoT model
drbrain has joined #rubygems-trust
<Malf>
Maybe my search skills are failing me
<Malf>
anyway
<Malf>
afk
<raz>
well, it's a bit of an umbrella term, it could even be that x509 specifically implies the CA-PKI star-topology
<raz>
semi-star.. pseudo-star.. broken tree..
<raz>
but i think people nowadays mostly use the term to denote they're using the openssl api called "x509 and friends"
* raz
ponders putting the problems right in there ;)
<dstufft>
raz the url is baked into the Gem right? So I exploit Rubygems, I delete your gems and replace them with my own that point to a different url and sign them with the key at that url
saturnflyer has left #rubygems-trust [#rubygems-trust]
<raz>
dstufft: yep. but: the user will be prompted with your url. so you better make your url look legit.
<raz>
not infeasible obviously, but imho a big step over having nothing at all (today)
<Antiarc>
So open a github account. Done.
<raz>
Antiarc: sure, but how is that scenario different with any other solution? (minus the prompting)
<dstufft>
Fake trust is worse than no trust
<dstufft>
:/
<Antiarc>
raz: Because the pubkey field implies trust
<raz>
fake seems a bit harsh
<Antiarc>
Which is why I am continuing to say that pubkey discovery has to be 100% out of band for that to work.
<raz>
the link merely implies: this gem belongs to *this* url
<raz>
trust is for the user to decide
<raz>
as said, the only problem this really tackles is the rubygems.org MITM
<dstufft>
I mean unless you have an infallible system you'll have problems with fake trust
<raz>
it's in no way a comprehensive solution
<dstufft>
You just try and minimize it
<raz>
dstufft: exactly
<dstufft>
raz: But it doesn't do that at all really. someone MITM can just on the fly replace the url and resign the package
craigmcnamara has quit [Quit: craigmcnamara]
<deus_rex>
^
<dstufft>
I have a proof of concept around here that un the fly unpacks a Python source dist and modifies ithe setup.py to open a web browser to a page
<raz>
dstufft: yes. but realistically i'd think most people probably find gems by looking at their homepages or at github?
<raz>
at least that's how i discover most gems
<raz>
i don't just install random stuff normally
<raz>
so when 'gem install' suddenly queries me with a different url, i'd be suspicious
<dstufft>
raz: I think you probably do more due dilligence then most people
<raz>
dstufft: hm. i don't even count that as due diligence. i mean, how do *you* normally discover gems?
<raz>
do you just go "gem list" and then install what looks promising? ;)
<havenn>
yes >.>
<raz>
lol okay..
<Antiarc>
Think about bundler.
<Antiarc>
You add 3 gems to your Gemfile and 30 dependencies come with them.
<Antiarc>
You gonna go vet each of those?
<dstufft>
raz: Well for Python stuff I tend to search Crate.io (PyPI essentially) and go from there
<raz>
in that scenario i obviously lose. but frankly, i don't see how one of the other solutions would provide more confidence there.
<dstufft>
raz: Well you can close your gap in your solution by caching the url on the client side
<dstufft>
e.g. they are only vulnerable to that the first time they've installed the gem
<Antiarc>
Why go with the URL? Cache the pubkey.
<dstufft>
But yea tat ^
<dstufft>
that
<dstufft>
w/e spelling is hard
<raz>
Antiarc: good point. in my naive "let's get started with something" i'd just call that implied trust. if you pick the toplevel gem then there's little point even prompting you about the others.
<dstufft>
raz: So I just need to MITM a gem that hardly anyone installs by itself but lots of things depend on? :)
<deus_rex>
activesupport?
<Antiarc>
gem self-signing is good for recovery from things like what Rubygems just had happen. It is not practically much good for most end users.
<deus_rex>
(sigh)
<Antiarc>
Some users would get value out of it, for most it would be ignored or turned off.
<raz>
dstufft: yup, not unplausible. however, if continuity was implemented (cert locally cached, flag raised when updates don't match) then your injection would be soon detected - unless you manage to make your gem look so promising that someone else adds it as a dep to his project without further checks ;)
<raz>
Antiarc: yes, what you just said. that's what i mean when i say "it solves only one aspect" - but at least that's one problem less, at a fairly small cost.
<Antiarc>
Why push it as an end-user system with a rubygems-bin component then?
<Antiarc>
That obfuscates the issue and presents a non-solution as one that instead muddles the actual problem on the client's end.
<raz>
erm, i only want to push it to the gem *authors*
<dstufft>
raz: FWIW I'm a big propoent of the SSH model by default allowing paranoid users to turn that off and require manually accepting each key + allowing people to install their own trust roots (so a business for example could publish a trust root and disallow anything that hasn't been vetted)
<raz>
so rubygems.org gets its full set of gems signed
<Antiarc>
But you're talking about people who install gems.
<Antiarc>
Nevermind.
<Malf>
Thanks for the link. Granted my reading skills may be weak as it's getting later here. However that and a few other docs seem to continue to confirm that X.509 is a hierarchical model and not a WoT model unless you are using the term WoT extremely loosely.
<raz>
yes sorry, i was responding to the valid concerns
<raz>
obviously everyone *can* validate the gems, but in practice i doubt most people actually would
<raz>
although the latter might then be tackled in step 2 with some convenience addons..
<raz>
and above all you could start gathering data for a WoT. which obviously is not attractive when you're opposed to WoT. ;)
<raz>
like, it would be really relatively simple to tack on something like "trustlists" hosted by whoever, to ease the verification burden
<raz>
as discussed earlier.. but obviously that enrages the purists, as it's not pure at all
havenn has quit [Remote host closed the connection]
<raz>
my main concern remains whether something will happen at all over the next few weeks, i'll be curiously watching that
<raz>
the risk of aiming for the perfect solution is not getting anything done at all
<raz>
especially with a subject as complex as this :/
<Malf>
agreed on that
<raz>
i'm gonna take a nap soon, but for a scenario:
<raz>
rubygems.org gets hacked again, unknown number of gems may be tampered with
<Malf>
My only real nit with pushing towards something like your proposal in the immediate term is that we get a little extra churn later when a longer term solution is established.
<raz>
if all gems are signed by then, the people who verify will soon start getting continuity errors and raise flags
emboss has quit [Ping timeout: 252 seconds]
<raz>
if not..well.. hopefully some alternative solution is in place by then, or the rubygems guys will have to do the md5 dance again :]
<Malf>
heh
<raz>
i mean, people unrelated to rubygems.org could even run "continuity CI's" or such
<raz>
like just keep scanning gems and their sigs.. etc..
<raz>
all scrappy and unpure, but in the end effective
<dstufft>
raz: FWIW if you want to verify continuty you need a good way to transition from one key to another
Mab879 has joined #rubygems-trust
<raz>
dstufft: yup, stolen key is an interesting problem
<dstufft>
raz: well not just stolen key
<dstufft>
maintainer transfer, lost key, expired key
<dstufft>
additional maintainer
<raz>
yes, all the same
<dstufft>
well slighlty different, transfer/expired/additional can sign some document that transfers or adds trust to a different key
<raz>
as said, don't claim to solve these
<Malf>
the good ole "What if they're hit by a bus tomorrow" problem
<raz>
in my approach i'd say "raise the red flag, let the user decide whether he wants to store the new key"
<dstufft>
if it's a stolen/lost key or an expired one that didn't get transfered in time raise a red flag
<raz>
yup well, for the verifier it all looks the same
<raz>
he suddenly sees a new key for a gem for which he already has an old one
<dstufft>
Ideally if you're presenting this to users you want to handle as many of the problems automatically as you can
<raz>
hopefully accompanied by a colorful readme with many lolcats and excuses, explaining why that was necessary ;)
<dstufft>
The more annoying it is for someone installing a gem, the more likely it gets disabled
<raz>
dstufft: i think that's the key disagreement between those CA-guys and me. i don't believe this can really be automatically handled.
<raz>
well, it can to a degree, but the complexity is enormous
<raz>
i honestly don't expect to see *that* scenario comprehensively solved within this year ;)
<raz>
unless there's really a CA with humans doing a ridiculous amount of work
<dstufft>
raz: well the CA is the ultimate in UX as it's handled all for you magically. I really don't suspect a CA solution to be reasonable so you're left sorting out better methods don't don't push too much burden on your users
<raz>
dstufft: yea, sadly there doesn't seem to be much middleground.
<raz>
it all fails at "the cert-url is embedded in the gem"
<raz>
i think we can do all sorts of dances around that, externalize it, in the end we arrive at PGP ;)
<raz>
i mean, it's not like these (PGP) are the very people who have thought about this problem very hard for a long time ;)
<raz>
s/not like//
<raz>
(4am here, grammar gets worse :P)
<Malf>
I do tend to think the pgp direction does have a slightly higher likelihood of resulting in something that's plausibly used/verified. I imagine we'd have to end up with a rubygems keyring similar to the *nix package managers keyrings giving us a quasi-root to trust as most casual users if we wanted to eliminate most of the user-facing pain though.
emboss has joined #rubygems-trust
mr_ndrsn has joined #rubygems-trust
<Malf>
Again plausibly used purely from the "CAs are a lot of work" perspective.
<dstufft>
I still think continuity is the best effort here, first time you install a gem it goes "yo I don't kow if X is trusted for rails, should I trust it?" The bulk of people will just hit Yes, but that doesn't matter as the bulk of the time they'll be jsut fine hitting Yes. From there on afterwords it verifies rails gems are signed by that key, if it isn't then it yells loudly and refuses to install without some sort of
<dstufft>
--insecure flag.
<dstufft>
On top of that if you build it ontop of GPG you can let people install or particupate in a WOT
<raz>
Malf: yup. afaik this is also precisely what at least apt uses. not sure about other pkg managers.
<dstufft>
or have a custom company wide WOT
<dstufft>
or whatever
<Malf>
right
<Malf>
I do like that ssh-like behavior too.
<raz>
funny how the consensus swings around depending on which people are around ;)
<dstufft>
If you take the recent attacks against Rubygem, the only people who would have been vulnerable is someone installing a gem they hadn't seen before in between the time someone exploited rubygems and rubygems got shut down
<Malf>
right
<Malf>
raz: hah yeah very true
<dstufft>
not perfect, but that's a heck of a lot smaller surface area than "everyone"
<raz>
dstufft: only under the premise everyone actually verifies. under the more realistic premise that only a few people actually go through that pain (at least early on) it would still take a while until someone raises the flag.
<dstufft>
get bundler to embed the key in it's Lockfile to handle remote servers
<raz>
but... in the end, well, i wouldn't be proposing it if i didn't think this was an improvement over no security at all :)
<Malf>
right
<Malf>
and I'm sure we'd all be more than happy to contact the appropriate folks in alarm if/when things looked bogus frmo the verification POV
<dstufft>
raz: The thing everyone would veriffy, automatically. Now some folks would choose to ignore it and just --insecure it, but there's likely to be folks going "hey why is rails suddenly saying the sifnature no longer matches"
<raz>
yup, imho there's quite a few ways to take that very naive approach and make it nicer
<raz>
dstufft: yup, like that
<dstufft>
on twitter, emails, github etc
<raz>
there's a balance to strike in terms of "warning blindness"
<raz>
but it should be doable
<raz>
but the key precondition is that all gems are forced to be signed
<raz>
imho
<dstufft>
it's slightly more user hostile than a CA, but you also spread out the risk. If the CA gets exploited you get trust for every gem on every system
<dstufft>
Oh aboslutely
<raz>
when you do it only for some, then well.. still better than nothing, but not exactly an improvement
<dstufft>
if all gems aren't signed you just replace the ones that aren't signed
<dstufft>
and use that to maneuver your way onto the box
<dstufft>
possibly replacing /etc/hosts to point rubygems somewhere else
<Malf>
that sounds like a sweet gem
<raz>
yes. the problem i have with CA is not that i think the UX or security wasn't better (it would be awesome). i just lack the fantasy to see those volunteers maintain such a complex infrastructure in the long run.
<Malf>
Trying to download it but rubygems.org is still readonly :/
<Malf>
yeah same
<Antiarc>
In order to actually exploit an owned CA, you have to exploit both the CA *and* the distribution platform. Exploiting the CA just gives you the ability to generate arbitrary "trusted" certificates.
<dstufft>
Antiarc: You can still exploit MITM
<Malf>
Having known people who worked in the CA world I have a hard time believing we're going to find people who are willing and able to properly maintain one in their spare time
<dstufft>
Also I assume ruby has something like PyCon, go there hit the wifi you just owned a bunch of ruby boxes
<dstufft>
go to a coffee shop in SF, you'll get a bunch
<Antiarc>
You have to actually own the router to successfully MITM
<dstufft>
No you don't
<raz>
Antiarc: i really think you are underestimating the complexity of running a CA at that scale. (i run a few very small internal ones, and you have to be *really* careful all the time)
<raz>
and that's not even getting into the whole vetting idea which sounds completely unrealistic to me
<dstufft>
Antiarc: I've got PoC's that do this for PyPI,could be run ona cheap computer that looks like a wallwart
<dstufft>
run around SF, drop a few of them into some power outlets
<dstufft>
ez-pz
<raz>
is ezpz the new python pkg manager? :P
<Antiarc>
You have to either be able to hijack DNS or actively modify TCP connections in order to MITM.
<dstufft>
Antiarc: hijacking DNS is trivial
<Antiarc>
and both are solved by doing the actual transfer via TLS
<raz>
Antiarc: rubygems is a juicy target. centralizing anything there is imho really just a bad idea.
<Antiarc>
I'd be interested in a link and/or PoC because you apparently know something about networking infrastructure that I don't :P
<Antiarc>
raz: A CA would be a separate system. Eggs all in the same basket is an obviously awful idea.
<dstufft>
Antiarc: DNS (without DNSSEC) is completely unathenticated, when your computer goes "hey gimme the DNS for rubygems.org" it blindly accepts the first answer you get back
<raz>
Antiarc: yes, but the CA would be the eggs and the basket!
<raz>
Antiarc: just imagine that thing being compromised - what would the recovery look like?
<Antiarc>
raz: Invalidate the root cert, issue a new one?
<dstufft>
if i'm on a local network with you I'm going to be the first answer you get back in the vast bulk amount of times
<raz>
Antiarc: invalidating all gems?
<dstufft>
Antiarc: Look at the reasoning behind DNSSEC
<raz>
the more beer i drink tonight the more i'm convinced people are really getting caught up in aiming for perfect security ;)
<Malf>
hah well I think some people certainly are
<raz>
yea it's a noble goal no doubt
<dstufft>
raz: heh my model is far from perfect, but it narrows the gap quite a bit, and it leaves the option open for a WoT (or even really a CA based on WoT) in the future :/
<Malf>
and the rest is a largely reflection of what level of security is adequate in each person's view combined with the fact that most of the people in here are probably not fully versed on the subject
<raz>
dstufft: what was yours again? iirc mostly like mine? ;)
<raz>
were you the "keep sigs external" guy?
<dstufft>
raz: somewhat similar yea, SSH model. Enforce everything is signed, First time a computer sees a signature for a gem if it's not already trusted via GPG WoT (unlikely at first since there's nothing in the proposal to build one) prompt them to accept it, if it ever changes yell loudly ala SSH
<raz>
dstufft: yup. do pretty much agree with that.
<Malf>
Reminds me of monkeysphere a bit
<raz>
details obviously shape out while doing then..
<dstufft>
it's somewhat similar to HSTS too
<Malf>
(which is really just trying to add in WoT in a form to the SSH situation)
<Malf>
true
<raz>
dstufft: the only reason i'm not proposing to go PGP right away is because that apparently has impl issues (no native ruby pgp). ignoring that part i'd say use PGP and get coding already :)
<dstufft>
raz: yea that's a hard thing in Python too
<dstufft>
on Linux you can reasonbly assume that GPG will exist on the system as most Linuxes use it for their own package managers
<dstufft>
OSX and Windows less so
<Malf>
yeah
<dstufft>
actually dunno if OSX comes with GPG or not
<raz>
yep we discussed that..uh.. hours ago...
<raz>
i think someone is actually going to look into it
<Malf>
newer versions might, not sure
<Malf>
I definitely had to set it up initially on my osx box at work
<Malf>
but that was a couple of releases ago
<raz>
yea, i'd also be worried about newer versions exposing a different cli interface and such
<raz>
but i guess gpg doesn't really get updated that often ;)
<raz>
Malf: btw monkeysphere looks interesting, gonna read up on that later
<Malf>
yeah it's sort of a cool notion
<Malf>
although I recently had a dependency problem with it on my debian box
<Malf>
had to turn it off to get X to start via gdm
<brycek>
ml doesn't ship with gpg
<Malf>
er gdm3
<Malf>
not really sure if gdm3 or the monkeysphere agent was at fault
<raz>
brycek: yea iirc someone earlier said he wants to look into how to install it on various platforms via a gem
<raz>
which may be feasible i think
<dstufft>
I think on windows you can ship a static .exe
<dstufft>
there's a python lib that does this
<raz>
yea, i guess the gem could just pull static builds on any platform
<Malf>
ahh no api for GPG? blech
<raz>
but iirc someone raised concerns about that .. but it might be solvable in one way or another
<raz>
dstufft: it's funny to have a python guy in here ;)
* raz
left python years ago for ruby-land
<dstufft>
heh
<dstufft>
I think ruby is mostly crazy :) Cool but crazy, I look at your guys packaging stuff a lot to try and make Python better
<Malf>
similarly if the key goal goes back to the notion that people like ourselves will see the red flags and report them then windows/osx users who fail to install gpg would, hopefully, only suffer in the short term
<deus_rex>
bundler is one of saner dependency managers
<raz>
yea, the python community has more of a focus on structure and code quality. ruby could use some of that. but well, ruby is just sexy. ;)
<dstufft>
yea I like bundler
<Malf>
bundler is probably one of the first things that started to really win me over on the ruby front
<raz>
the crazy thing is how much of a trainwreck the underlying code of most popular ruby infrastructure is
<raz>
including bundler
<raz>
it somehow works, but you really don't want to look at how it works ;)
<raz>
yet the convenience is so hard to argue with...
<dstufft>
I run Crate.io which is a PyPI mirror but not like the other mirrors I'm gearing it to be an actual replacement for PyPI eventually
<raz>
(disclaimer: bundler may have improved since i looked at it, which was years ago)
<deus_rex>
dstufft: put some padding in your search input, criminy
<dstufft>
deus_rex: man I suck so much at design
<raz>
dstufft: python imho still lacks package management that can match gem? last i looked there was virtualenv and pip, but both were still pretty rough
<dstufft>
I just cribbed some bootstrap and and had a friend help a bit
<Malf>
yeah sorry search isn't big enough
<Malf>
not using it
<Malf>
I demand a full-screen box
<dstufft>
raz: yea
<dstufft>
That's on my landscape too :/
<raz>
golang really has this stuff nailed so hard it hurts
<dstufft>
After I'm more satisified w/ the web side of things
<raz>
you just specify your git repository directly in the import '' line ;)
<dstufft>
lol
<raz>
but actually, i think in terms of trust they also have no good solution yet
<dstufft>
you could do that in Python :V
<dstufft>
well sort of
<dstufft>
I have an import hook around here somewhere that imports code over http
<dstufft>
it's completely insane
<Malf>
hah
<Malf>
I need to get me some of that
<Malf>
drop it into some of the python code at work and give the sysops guys a heart attack
<Antiarc>
I think you could technically use GPG rather than x509, but Evan made it clear that anything considered for inclusion in Rubygems would have to be implementable with the Rubygems stdlib.
<raz>
Antiarc: yup, looks well written (gonna have to re-read a few times)
<raz>
as discussed earlier i don't agree with the approach, but we'll see what comes out of it
<Antiarc>
s/Rubygems stdlib/Ruby stdlib/
<raz>
perhaps i'll make a small write-up of my critique tomorrow
<Antiarc>
(I typed Rubygems a lot in the last hour)
<Antiarc>
Please do. Critique away.
<raz>
at least this is a much more productive approach than endless irc flames, so thanks very much for writing this :)
<Antiarc>
I've got no skin in this - I just want a secure system so I can sleep at night. :D
<raz>
yea, me too
<raz>
in the end any impl will be a win ;)
<raz>
i wonder if we could put the discussing somewhere more structured than random gists
<raz>
issue tracker of rubygems-trust perhaps?
<raz>
but not so important
<raz>
we can just link the gists in the wiki
<Perceptes>
issues seems superior to gists
<raz>
Perceptes: yea, but also quickly turns into a mess when dozens of people start commenting
<raz>
perhaps it's not even bad to leave it in gists
<Perceptes>
you can comment on gists too
<Perceptes>
issues is just more discoverable
Antiarc has quit [Disconnected by services]
<raz>
Perceptes: yup but the actual contribution doesn't get drowned in comments
Antiarc has joined #rubygems-trust
<raz>
hm.. erm.. well whatever, it semms i'm shooting down my own idea right now ;)
<jfelchner>
Antiarc: Good to see an actual proposal and it's so good I withdraw my argument for another form of implementation. :)
<raz>
as long as it's somewhere people can find it, it's all good :)
<Antiarc>
(I installed VirtualBox and got disconnected, so I missed any comments in the last couple of minutes, raz)
<raz>
Antiarc: nothing important, only short debate about moving the proposals from gists to github issues
<Antiarc>
Oh. I posted an issue with a link to the gist
<Antiarc>
Because I'm dumb and put it in a gist first
<raz>
ah!
<raz>
yea, it doesn't really matter either way.. we're on the internets, it's all possible ;)
<dstufft>
I think you're underestimating how likely it would be for both systems to get compromised at once
<dstufft>
FWIW
<raz>
yup i'm making a few scribble notes right now, that's one of them
<Antiarc>
I'm assuming different data centers, different keypairs for logins, absolutely minimal attack surfaces. Not sure what more you can do beyond that.
<raz>
Antiarc: the risk exists as long as it's the same people imho
<raz>
well, it always exists, but that amps it
<raz>
but ofcourse that may be solvable
<Perceptes>
what does "dead-drop" mean?
<dstufft>
you drop it and leave, you don't hang around
<dstufft>
in the real world
<Antiarc>
Perceptes: You put the data on shared storage, and another machine picks it up as a form of double-blind IPC.
<dstufft>
sort of like a blind transfer
<Antiarc>
The idea is that a compromise of machine A would have a single data-only interface to machine B, so you can't pivot that into a compromise of the system to obtain the private key or whatnot.
<Antiarc>
Just a way to limit attack surface.
<Perceptes>
thanks
<Antiarc>
The idea is to have the private key and the signing happening on a machine that has literally nothing on it except openssl, sshd, and nfs (or some similar combination)
<Antiarc>
The idea obviously being to limit the attack surface to as small an area as possible.
<raz>
will see to work on that some more tomorrow, some points may be invalid because i didn't fully parse the proposal yet
<dstufft>
Machine B is the ball game, that get's comped your trust model is done.
<dstufft>
Antiarc: Shold probably mention in the proposal the requirement for proactive detection
<raz>
yeh, lots of SPOF :/
<dstufft>
ideally by multiple indepedent security firms on a rolling schedule
<Antiarc>
dstufft: Yup, B is critical, which is why I want its attack surface to be as small as possible.
<dstufft>
because if you're a smart exploiter if you got onto B you'll be quiet aobut it and use it to sign trust
<raz>
i wonder if we go to that kind of complexity if something akin to bitcoin might not actually be worth looking at
<Antiarc>
blockchains would be great for something like the cert chain histories.
<raz>
but oh well, admittedly that's yet another notch up the complexity ladder
<Antiarc>
That would prevent forged history.
<raz>
Antiarc: yea, but it's even more complicated ;)
<Antiarc>
And computationally expensive.
<Antiarc>
And a shitload of data to shuttle around.
<raz>
yea, probably not feasible
<raz>
but that machine B is really kinda worrying
<Antiarc>
Absolutely. If there are ways to reduce the attack surface, I'm all for 'em
<Antiarc>
If I had my druthers, I'd pay someone to move a USB drive from A to B and back every hour :P
<Antiarc>
And B wouldn't be connected to the interwebs
<raz>
heh.. well it's volunteers.. and ruby-people, not exactly security experts..
<raz>
that all doesn't mix so well with running a CA
<dstufft>
FWIW (and this is why I said deisgning a CA is hard and people will get it wrong) you mentioned Redis, redis just recently had an attack that allowed filesystem enumeration so it's not outside of the realm that Redis could be an attack vector (not that file system enumeration in and of itself is a vector).
craigmcnamara has joined #rubygems-trust
<raz>
dstufft: it amusingly might even be for a veeeeery sophisticated attacker. at least normal openssl CAs store stuff like the serial in the filename ;)
<raz>
but admittedly that's very far fetched
emboss has quit [Quit: Leaving]
<Antiarc>
dstufft: Well, in the redis case, I'd put it on A and have B connect to it, so A has zero knowledge of B. But point noted.
<Antiarc>
(better yet, put redis on C, so that A and B have no knowledge of each other)
<Malf>
wasn't sure where to leave comments at this point so I'll just ask here
<Malf>
does that proposal result in the developer generating separate keys for every service they want to deploy to?
<Malf>
or did I misread that
<Malf>
service meaning gemserver
<Antiarc>
Malf: Yes.
<dstufft>
Antiarc: Then C is an attack vector FWIW
<dstufft>
although less of silent one
<dstufft>
I get C and I drop my own keys into redis
cwgem has joined #rubygems-trust
<dstufft>
or NFS or w/e
<Antiarc>
dstufft: Yup. I addressed that point; you could generate unverified keys, so you could upload new gems, but new versions of existing gems would be rejected.
<Antiarc>
So still a vulnerability, but a limited one.
<Antiarc>
It's really a game of "spread the risk around as much as possible"
postmodern has joined #rubygems-trust
<Antiarc>
Malf: I'm fuzzy on this, but you might be able to generate one key per service and sign them with each other, and include both in the cert chain.
<Antiarc>
I would leave that to the actual crypto people though.
<Antiarc>
Very admittedly not my strong suit, so I'm not even going to try :P
<Malf>
Yeah I guess I'm thinking most devs would prefer to have a single key per project to manage
<Malf>
I really only glanced at the proposal though
<Malf>
perhaps there's enough room in there to hide the granted key details from devs somewhat automatically
<cbetta>
i'd call ir formalised thought and a call to arms
<whitequark>
1) if developers' machine is compromised, it's end of game. the credentials WILL be stolen.
<whitequark>
2) you simply cannot prevent code execution at install without breaking too much.
<whitequark>
(same stands for forced signing)
<cbetta>
feel free to add your thoughts to the post whitequark
<whitequark>
right
<namelessjon>
whitequark: But if the credentials are encrypted, you at least have to wait until they're USED before you can steal them (giving more time for the compromise to be noted and steps to be taken), instead of "Install and they're copied"
<whitequark>
namelessjon: if developers' machine is compromised, you have much worse problems
<cbetta>
whitequark not a reason not to slow down any further compromise
<cbetta>
hence why people have passphrases on their ssh keys
<namelessjon>
whitequark: Yes. Yes, you do. But by that logic, why encrypt my gpg key?
<whitequark>
definitely not because your machine might be compromised ;)
<whitequark>
to allow you to make a backup freely; to allow you to not care about mishandling of your hard drive after you toss it in trash
<whitequark>
at least
<cbetta>
nah for that I have full disk encryption :)
workmad3 has quit [Ping timeout: 264 seconds]
<namelessjon>
cbetta: One alternative/addition to 'email the developer' is publish a log of gem checksums (perhaps using some kind of linked hashing), and maybe also a "this gem was yanked" in there too.
<cbetta>
how would that notify me that someone uploaded a bew version of one of my gems instead of me?
<cbetta>
*new
<yorickpeterse>
If somebody can upload gems they can probably change the Email address for those notifications
<namelessjon>
That's probably why its better as an addition, but it makes tampering with old versions harder, even if a key is compromised, because there's a log of them. And yeah, as yorickpeterse says, gives you a log you can check yourself, rather than relying on being told
<cbetta>
yorickpeterse not sure, credentials are just an api token right?
<whitequark>
you can also send an email when email is changed
<cbetta>
whitequark agreed. sensible policy around all that has been solved by many online company before
schisamo has left #rubygems-trust [#rubygems-trust]
schisamo has joined #rubygems-trust
FooBarWidget has joined #rubygems-trust
FooBarWidget has quit [Client Quit]
jbgo has quit [Quit: Leaving.]
jtanium has quit [Quit: jtanium]
jtanium has joined #rubygems-trust
workmad3 has joined #rubygems-trust
jtanium has left #rubygems-trust [#rubygems-trust]
<namelessjon>
It also makes rubygems.org publically commit to a copy of the code, without actually needing signatures. For more paranoia, you can only install gems with a published hash. That way, even if rubygems.org is compromised, and the attacker uses the key on the server to sign their new gems (and disables the email, because why wouldn't they?), they have to publish a hash and let you know, or clients could choose not to install it. It (...)
<namelessjon>
helps to keep the server honest.
<schisamo>
back
workmad3 has quit [Ping timeout: 252 seconds]
havenn has joined #rubygems-trust
<Antiarc>
My proposal addresses that circumstance by maintaining an independent cert chain history, which is even better than hashes, IMO
<whitequark>
... and plays nicely with cert revocation
<Antiarc>
Yup
<whitequark>
in order to clean up the fallout
<namelessjon>
Antiarc: This is complementary to your proposal, really. I'm not saying no signatures. But public key crypto is hard. Bad randomness can compromise a key, as well as other issues. In the event of compromise, you can't trust ANY signatures made by that key, even ones on 'historical' gems. If the rubygems server has to publish hashes as it goes, then there's a permanent public record of its state. One that doesn't rely on getting (...)
<namelessjon>
the correct public keys for any given gem.
<Antiarc>
in the event of a key compromise, you would issue a revocation request for that key, and the rubygems binary would pick up on that and flag any gems signed with that cert
<Antiarc>
(That said, I think hash history is great)
<namelessjon>
Antiarc: Yes, but then you have all the historic versions of the gem you also can't trust the signature on (but might need to have versions of, for bundled gemsets pinned to a particular version). Having the hashed history available lets you check the existing gems quickly.
<Antiarc>
No argument. Just saying that it shouldn't be used to solve problems already solved via the cert chain :)
<Antiarc>
Having a reliable history of a gem's hashes fills a lot of holes in the current setup.
<Antiarc>
It'd certainly had made the recent recovery easier.
billdingo-afk is now known as billdingo
<raz>
funny, that's pretty much what i proposed yesterday before falling asleep :P
<raz>
now you just have to realize that the CA root makes no sense and we're even :D
kevinprince has joined #rubygems-trust
workmad3 has joined #rubygems-trust
<kevinprince>
theartisan: how did you get ops in here?
<cbetta>
kevinprince he had since start
<kevinprince>
lol ok
<kevinprince>
no chanserv? someone should probably register the chanell
Mab879 has quit [Quit: quit]
gcoderre has joined #rubygems-trust
php_on_rails has joined #rubygems-trust
<php_on_rails>
hai
<php_on_rails>
sup in this chat?
<theartisan>
register away cbetta
<cbetta>
wha?
* cbetta
doesnt feel like he owns this channel
<php_on_rails>
how y'all doing
<whitequark>
I guess drbrain or qrush should register it
<theartisan>
you are more suited to register than i am ;p
<php_on_rails>
sup
<php_on_rails>
hellllooo
<cbetta>
php_on_rails what?
* cbetta
doesnt feel like he owns this channel
<cbetta>
ugh
<cbetta>
damn irc client
<yorickpeterse>
hehe
<php_on_rails>
nothing i am just looking to chat
<php_on_rails>
what y'all into
<yorickpeterse>
I think you're in the wrong channel
<yorickpeterse>
Generic Ruby stuff goes in #ruby-lang
<yorickpeterse>
Generic Rubygems goes in #rubygems
<yorickpeterse>
This channel is specific for the security issues and planning for signing (and such) of Rubygems
<php_on_rails>
yeah that is a bummer i want more info on how they are messed up can u point me into a FAQ
<yorickpeterse>
Did you check the status page?
<yorickpeterse>
It has pretty much all the information
<yorickpeterse>
php_on_rails: you're by far the worst troll ever to join a channel I'm in
<theartisan>
php_on_rails: at least gem has a signing function
<cbetta>
tnx whitequark
<theartisan>
wheres that option in composer / packagist?
<php_on_rails>
WHHHHHAT
<theartisan>
pypi, rubygems, etc all support signing even if nobody uses it
<php_on_rails>
the fartisan
<yorickpeterse>
drbrain: ldk theartisan: just kick the guy, he's no use
<yorickpeterse>
12 year olds are not supposed to be on IRC anyway
<php_on_rails>
do u sign everything with a fart?
<php_on_rails>
yo dick pepe
<kevinprince>
php_on_rails: bye
php_on_rails was kicked from #rubygems-trust by theartisan [is that yo momma calling?]
<yorickpeterse>
Please don't lower yourself to his standards
<theartisan>
but i like to troll
<cbetta>
theartisan dont
<kevinprince>
this is not the place :)
<theartisan>
packagist and composer from the php world have an interesting setup actually, its all installs from git/mercurial/subversion repos
<theartisan>
which delegates most of the risk to github and bitbucket style services
<cbetta>
not sure how that mitagates much theartisan
<theartisan>
harder to sneak code in
<theartisan>
you have to rewrite the sources in the index
<theartisan>
so you need to gain access to the DB it's self on the index, which if the ops people did their job properly having the credentials wont help with.
workmad3 has quit [Ping timeout: 245 seconds]
<raz>
theartisan: i actually like this approach very much, golang does the same thing
<raz>
in essence bundler already supports it, but i think the chances are slim to have that part of bundler improved and dropping rubygems.org altogether ;)
<theartisan>
it has drawbacks though
<theartisan>
infocide
<raz>
after thinking about this whole trust-issue over the past days i'm tempted to believe those drawbacks are simply inherent to any system
<theartisan>
which ruby saw first hand how bad that can be when _why took all his repos down
<raz>
i may be mistaken, but all discussions end up circling around the fact that "if no one actually verifies the gem, then well, the best we can do is look if it originates from about the same direction as the previous version[s]" ;)
<theartisan>
im personally in favour of two layers of protection
<raz>
yea you are right infocide is an issue, but popular gems tend to get mirrored around anyway
<theartisan>
having basic signing so you can verify the package came from the repo
<theartisan>
and also being able to go into strict mode and saying "i only trust these keys"
<raz>
yup, the latter is consensus by now i think
<raz>
the former is still under debate (at least i don't see the benefits)
<theartisan>
there are ways of solving things outside rubygems too
<theartisan>
bundler for instance
<theartisan>
Gemfile.lock could list keys, and bork out if the key is different
<theartisan>
im not really fussed if some developer machines get tanked by rouge gems, but if that code makes it into production thats a problem
<raz>
yup, my main concern remains the central CA as proposed by now. i don't see what benefits it adds, but am all for continuity checks in every shape and form (possibly assisted by "trusted" servers)
<theartisan>
or if the gem install is man-in-the-middled
<theartisan>
that authorizes everyone else, otherwise you have to keep adding keys
<raz>
basically i agree with *storing* the certs somewhere on a first-come first-serve basis
<theartisan>
ubuntu have made some headway in that department, but it would be a PITA to deal with in ruby
<raz>
i just don't see why we need to centrally *generate* those certs
<theartisan>
the thing is, its not really centralised
<raz>
(generate = sign, terminology slip)
<theartisan>
because it would be one cert per index
<raz>
yes, a difference between rubygems and the distro repos is that the latter actually have maintainers for each package
<theartisan>
and by adding the cert you are saying "i trust this index"
<raz>
theartisan: well, that's effectively achieved by trusting the SSL-certificate of rubygems.org
<theartisan>
i can see a future where a more vetted gem index comes into existance, and the really popular gems make their way onto it
<theartisan>
archlinux has a model like that
<theartisan>
AUR -> community -> main repo
<theartisan>
first is a wild west like rubygems, then if something gets enough attention it gets packaged properly, and after enough installs it makes it into the fully vetted repo
<whitequark>
what's "packaged properly"?
<theartisan>
AUR is all source
<Malf>
yeah I'm with you raz on the central generation thing
<theartisan>
its more github than rubygems tbh
<theartisan>
but anyone can put their stuff on it
<theartisan>
community is a binary release
<Malf>
It's not clear at all to me that we need that level of control around signing versus a rubygems.org gpg key that signs project keys
<theartisan>
but the point is more the more popular a package is, the more its vetted, tested, etc and the more trust there is in each progressive repo it moves through
<theartisan>
i have worked with financial companies, who have really strict restrictions on what they can install and from where
<theartisan>
you would have trouble getting gems past some of those restrictions, its actually pretty retarded for the most part
<raz>
Malf: thx :)
<theartisan>
one place was not allowed third party code… reinventing the wheel and making it square ftw...
<theartisan>
but having things like rails, etc in a secure vetted index, and pulling everything else from ruby gems, would make some sense, and there may be enough companies that rely on those libraries to get funding to properly vet each upload
<raz>
i don't think companies requiring that kind of audit use rails :)
<raz>
(at least i hope they don't)
<theartisan>
maybe they dont because they need that kind of audit?
<raz>
rails has deeper issues than trusted installation
* theartisan
only really writes ruby to extend puppet, so is not really clued in as well as real ruby developers ;p
<theartisan>
and occasionally cucumber
<theartisan>
the centralised cert idea is basically a way of saying "i trust this repository" which is what the GPG stuff in linux package managers use them for
<raz>
as said, linux pkg managers are a slightly different use-case
<raz>
there you effectively trust maintainers, not authors
<raz>
(at least in the common distros, e.g. apt)
Antiarc|Nexus has joined #rubygems-trust
<theartisan>
theres no reason ruby could not transition to that model though
Antiarc|Nexus has quit [Client Quit]
<raz>
if rubygems org started assigning a maintainer to every gem then that might work, but i don't think anyone really wants that ;)
Antiarc|Nexus has joined #rubygems-trust
<theartisan>
most distros have a "bring on the crazy, your on your own now" style repo ;p
<raz>
yup, that is what rubygems.org basically is :)
<raz>
imho the goal is to keep it that way and just make it a little harder for a bad person to ruin the whole show
<theartisan>
if you have certs you could have gem.puppetlabs.com
<theartisan>
and that would have its own cert, and serve up only puppet, facter, ruby-shadow
<theartisan>
etc
<theartisan>
i trust puppetlabs not to tank my system, so i add that repo and remove rubygems, then i can be sure things are safe ;p
<raz>
yup we've discussed that in-depth over the past days
<theartisan>
the trouble is that wild west repo
<theartisan>
but, if your really worried about security the author certs give you even more fine grained support
<theartisan>
java has an intresting approch to this actually thinking about it
<theartisan>
each "signer" can sign the files in the jar, and you can decide who you trust from what i understand
<theartisan>
so, if you have a maven repo, that signs everything and modifys the jar file to add its signature
<theartisan>
and the individual developers signatures stay in there too
<theartisan>
and if i run a more vetted repo i can take the jars from an upstream maven, sign them myself, and serve via my own
<theartisan>
you could then have rubygems only accept gems from sources that it has public keys registered for
<theartisan>
so when i register a gem "namespace" i add keys for people allowed to sign the gem
<theartisan>
and anything else is rejected
<theartisan>
anyway, ranting again...
<theartisan>
i should be working...
calmyournerves has joined #rubygems-trust
DonOtreply has joined #rubygems-trust
cbetta is now known as cbetta_afk
alexmreis has quit [Quit: alexmreis]
alexmreis has joined #rubygems-trust
DonOtreply has quit [Quit: Computer has gone to sleep.]
alexmreis has quit [Quit: alexmreis]
justincampbell has joined #rubygems-trust
billdingo is now known as billdingo-afk
Antiarc|Nexus has quit [Read error: Connection reset by peer]
Antiarc|Nexus has joined #rubygems-trust
havenn has quit [Remote host closed the connection]
<kevinprince>
theartisan: java bit different, was discussing that with cbetta_afk offline
<theartisan>
in what way?
* theartisan
has a model in his head buy too much work on at the moment to sketch it out...
<kevinprince>
well you compile to JVM machine code and can distrubte that signed
<kevinprince>
not just raw source
<theartisan>
you can still tamper with things in the jar files, those are just zips, and there are plenty of projects to decomple java
<kevinprince>
truw
<theartisan>
the signing mechanism is what intrests me though, the idea of multiple signers
<theartisan>
you could use the signatures in a way similar to git/mercuiral SaaS works too, and only allow pushes signed with specific pre shared keys on a per gem basis
<theartisan>
if you seperate out the signing from the index as everyone agrees needs to be done, you then make sure that gems can only be pushed by allowed users, so no random gems getting into the index, and then you have the indexes key to say they verify that gem was pushed by someone authorized, and that it comes from the index
<theartisan>
you can even drop the authentication stuff on pushing gems then as you just check the signature once you have it.
<theartisan>
sign with author cert -> push gem -> validate signature -> sign with index cert -> make publicly availible
locks has left #rubygems-trust [#rubygems-trust]
DonOtreply has joined #rubygems-trust
craigmcnamara has joined #rubygems-trust
cbetta_afk is now known as cbetta
DonOtreply has quit [Quit: Computer has gone to sleep.]
<raz>
yup, let's keep the discussion on that ticket i'd say
<raz>
alternatively we could use the rubygems mailing list (cheald has posted his initial proposal there already), but imho github is a slightly friendlier interface. it's just important we keep it in one place and don't scatter it across three :/
Perceptes has joined #rubygems-trust
<raz>
dstufft: and thanks for chiming in, i agree with the point you raise :)
<theartisan>
i dont want to clutter up the existing ticket with a different approch
<dstufft>
theartisan: commented
<dstufft>
theartisan: FWIW you're is really close to my total plan for the Python side of this problem (I'm not a ruby guy, i've been working on solving similar issues in Python for the past year or so on and off)
jfelchner has quit [Ping timeout: 264 seconds]
havenn has joined #rubygems-trust
* theartisan
is a python dev too
<theartisan>
i want a model that would work all over, gems, npms, eggs, etc
<theartisan>
retrieving a key from key servers is not too hard to implement so i suspect the key distribution bit could just use the same infrastructure that gpg uses
<theartisan>
then use the RSA support in openssl to generate a hmac
jfelchner has joined #rubygems-trust
<theartisan>
im also not particually concerned with automatic revocation stuff, this is not a problem for linux distros, so why is it a problem here?
<theartisan>
but if the keys are distributed via the gpg infrastructure the same mechanism can be used.
<dstufft>
Automatic revocation is a nice feature. I don't think it's mandatory, but one thing that favors having it in RubyGems over Linux is that you have a much smaller attack surface
calmyournerves has quit [Quit: Leaving.]
<dstufft>
e.g. there are far fewer people/machines to secure to keep the Debian repo key safe than there is to keep all the indiivdual rubygem keys safe
<theartisan>
i get that say the ubuntu keys need never see a network connected machine so are easier to secure
calmyournerves_ has joined #rubygems-trust
<theartisan>
it should be down to the authors to keep their keys safe
<theartisan>
rubygems.org just needs to keep its own key safe
<theartisan>
fwiw this is mostly stolen from my crude understanding of how maven does things
<dstufft>
Half the problem is there's no clearly defined threat model here
<workmad3>
theartisan: if rubygems.org is trusting the author's key as a way to identify the provenence of a gem though, then when an author's key is compromised, provenence can be faked
<workmad3>
theartisan: unless that key can be revoked
<workmad3>
I guess that's different from automatic revokation though
<theartisan>
then you pull the key from the list of authorized keys
<theartisan>
and delete that build
<theartisan>
and appologise profoundly to your users for being an idiot
<theartisan>
the nice thing about using RSA keys is they have passphrases
<theartisan>
so even if someone gets the key its still somewhat secure
<workmad3>
theartisan: are you an idiot if you lost your credentials because you released a gem on the day someone exploited a 0-day in your OS and stole your passphrase and keys?
craigmcnamara has quit [Quit: craigmcnamara]
<theartisan>
either
<theartisan>
:)
<theartisan>
keeping ssh keys secure is not a new concept, we have been doing it for years.
<theartisan>
these keys would be much the same
jeer has joined #rubygems-trust
<raggi>
is chris heald here?
<raggi>
Antiarc: is that you?
<raz>
i think he is
<raz>
but i don't know if he's here :)
<dstufft>
github -> irc name mix mash :V
<raz>
heh
<raz>
yea
havenn has quit [Remote host closed the connection]
* dstufft
makes this easy, dstufft everywheres
<raz>
raggi: would be nice if you could use my github name on the ticket, so people don't get confused who you're replying to
<raggi>
well his irc username field is "chris" so
<raggi>
raz: i wasn't sure exactly who you were
<raggi>
and honestly, ML is a better place for all this
havenn has joined #rubygems-trust
<raggi>
but i'm not going to push this around more
<raz>
i don't care either way, we should just try to agree on one place
<raggi>
right now, i'm running out of patience for circling arugments
<raz>
i chose the ticket because there was already some discussion.. but don't mind moving to the ml if that's preferred
<raggi>
i want to see more full proposals
<workmad3>
theartisan: I agree, I'm just pointing out that also planning for a key being compromised isn't something to gloss over and when it happens call the author an idiot doesn't help
<raggi>
not just paragraphs
<raggi>
as only full proposals are worth discussing
<raz>
raggi: the proposal is there, we are discussing it.
<raz>
i pretty much agree with his proposal, just minus the CA
<raggi>
wow
<raggi>
i mean, i'm really glad someone took the time to put somethign together
<raggi>
and it's a reasonable starting point
<raggi>
but there are lots of missing points and things we need to validate
<raz>
isn't that the point of discussing it on github or ml?
<raz>
not sure what you're after now
<raz>
i'd also volunteer to write some code (as time permits and if desired), but i think we need to agree on a direction first
<raggi>
i'm trying to balance being open to community impact (staying in here, for example), and just leaving before i get angry and start either getting rude or ragequit
<raggi>
raz: if you have ot put that provisor on it, then seriously, just back down a bit
<raggi>
raz: because that provisor means you can't put time into it
<raz>
i frankly don't understand the rage, sorry
havenn has quit [Ping timeout: 252 seconds]
<raz>
if you want me to shut up then i will, i'm just putting my time here hoping to help coming up with a sane solution
<theartisan>
workmad3: tbh if someone steals my keys im going to be more worried about my servers :)
<raggi>
because so far, you haven't learned anything, and i keep getting drawn into the same loops wiht you
<raz>
raggi: have you considered that your opinion of the issue may not be fully authoritative?
<raggi>
i'm getting pissed at myself for not just /ignoring, but i also don't really want to do that
<raggi>
raz: i know it isn't, but i'm learning
<raz>
i mean, if you are convinced you are right, why have all this discussion at all?
<raggi>
raz: repeating yourself is not persuading me
<raz>
?
Antiarc|Nexus has quit [Read error: Connection reset by peer]
<raz>
well, i've stated my point in the ticket, it's your turn i guess
<raz>
no idea why this has to get emotional
<raggi>
i've been talking about *process* being important
<raggi>
over and over and over again
justincampbell has quit [Ping timeout: 245 seconds]
<theartisan>
now now children
<raggi>
and you haven't solved *any* of the process problems in anything you've said
<raggi>
see, this is what i was afraid of
<raz>
raggi: i've asked a simple question: which problem does the CA solve
<raz>
if that is somehow wrong.. then sorry..
Antiarc|Nexus has joined #rubygems-trust
<raggi>
raz: and i gave you an answer, and you said "i don't understand" followed by repeating yourself
<raz>
you claimed it helps with validation, i've explained why it doesn't
<raz>
hm. i'll read your answer again.
<raz>
well, your key point seems to be "you need to be well connected for a timely recovery"
<raz>
is that right?
<raggi>
it depends what you mean by recovery, but sort of
<raggi>
if it was to help with what just happened
<raggi>
we have to be *completely connected*
<raz>
i'm sorry but i really just don't understand what that means in the CA context and how exactly the CA aids it
<raggi>
because a CA countersignature is completely connected
<raz>
connected to what? as i understood so far it's supposed to be fully automatic, anyone can get one?
<raggi>
every gem
<dstufft>
raz: FWIW the purpose of a CA (in general) is to delegate the authority to decide who to trust to a central (or select few) set of people so that end users don't have to make that decision for each and every certificate. I don't think that's particularly feasable in the topic of a repo like RubyGems because there's very little automated means to determine that A is able to sign for B
<raggi>
we can validate every gem against just the CA pubkey
Antiarc|Nexus has quit [Client Quit]
<raz>
raggi: i explained in my response why you can't
<raz>
or rather, why that doesn't help you much
<Antiarc>
Hey folks. Back from running the kids around.
<raggi>
hey Antiarc, thanks again for putting this together
<Antiarc>
Raz, I'm outlining the CA need as I see it :)
<raz>
Antiarc: great :)
<Antiarc>
raggi: My pleasure. Please continue to tear it apart!
<raz>
dstufft: yup, it seems we two agree. perhaps we are wrong, but well.. i'm not getting it so far.
<raz>
raggi: perhaps i should have phrased it simpler: if you verify all gems for having the automatic CA signature - you can just as well only check if they are self-signed. since *anyone* can get a CA-sig without any barriers, there is no difference.
<theartisan>
the CA comes in because trusting each individual gem author is too much of a PITA
<dstufft>
theartisan: Except the CA can't verify trust
<raggi>
raz: with regard to your middle paragraph: CAs don't generate key_ids, they sign certs
<theartisan>
but, maybe the sollution is to find another way to solve that problem
<raggi>
but this is really minor
<dstufft>
How does the CA know if ABC can sign for the prorject XYZ
<raggi>
raz: the history that they signed certs is critical, and you're right that it's the bit that matters for recovery
<raggi>
raz: but that's just it, it's critical for recovery
<Antiarc>
The CA doesn't exist to verify that you have the rights to upload project XYZ
<raggi>
Antiarc: no, but the signing history does :)
<Antiarc>
The CA exists a) as a single point of trust for end users, and b) as a measure of identity verification to ensure that dhh@37signals.com controls the dhh@37signals.com email address.
<dstufft>
It verifies you have the right to sign for it, otherwise you have a very large misunderstanding of what a CA does
<raz>
raggi: yes. and as said in my response: that history is unrelated to the CA.
<raggi>
Antiarc: and the siging history can be consumed by rubygems.org, not served by
<Antiarc>
raggi: Exactly. You have the epoch issue, but the rest of it is solved from thereon out.
<raz>
you don't need the huge amounts of effort to maintain a CA when you're really after continuity (history)
<theartisan>
see, im starting to think that trusting gem authors is not going to work
<Antiarc>
Signing history would have to be separate from rubygems.org for the system to maintain integrity
<raggi>
raz: where do we get the history from in a random countersign system?
<raggi>
and which history should we (as in rubygems.org) trust?
<raz>
raggi: as i understood it, it is specified in the proposal as first-come-first-serve. where is difference between the automated CA registering dhh@37s, and DHH doing that himself?
<dstufft>
You don't need a CA to keep a history of signatures
<raggi>
if i get two different .gem files, wiht two different signatures that have two different chains, neither of which are connected to anyone at rubygems.org, what do we trust?
<raz>
raggi: your concerns are valid (which should we trust etc.). i'm just saying this is all *independent* of the CA question.
<raggi>
i don't follow
<dstufft>
A CA's "only" purpose is to delgate the decision of who to trust to someone who is going to be more thorough than your average user
<dstufft>
It's not to validate after the fact
<raz>
a CA only says "you can trust this, because..."
<dstufft>
You want an append only log that is mirrored for that
<raz>
and the "because", in the current specification, is simply not useful
<Antiarc>
dstufft: Think of it less as a CA and more as just needing to have a cert to anchor the trust chain.
<raz>
"you can trust this because he sent an automated e-mail at one point"
<raz>
s/sent/received/
<dstufft>
Antiarc: A cert to anchor the trust chain doesn't work if you don't have a reason to trust the author is valid for that person
<raggi>
Antiarc: exactly
<Antiarc>
Conflating this root cert signing with SSL certs is the wrong way to think about it.
<dstufft>
You have a fundamental misunderstanding of what a trust chain signifies
* raz
ducks (let's keep it friendly please)
<raggi>
dstufft: no, our goal is not to validate all authors
<raggi>
dstufft: it's to validate valid repeat authorship
<raz>
raggi: how exactly does the CA signature validate repeat authorship
<raz>
?
<dstufft>
That's not what a CA does
<raggi>
raz: the history does
<Antiarc>
The trust chain by itself isn't all that useful. The trust chain plus trust history is.
<raz>
yes.. that's the point. it's not what a CA does.
<theartisan>
you can validate repeat authorship with self signed certs
<dstufft>
E.g. have rubygems.org write to a git repo on each push the new key and the signature, Have other people mirror that
<raz>
raggi: a CA is a *very* complicated way if all you want is to store a history of key ids.
<dstufft>
Now you have an effectively append only log
<dstufft>
that anyone can mirror
<dstufft>
One that the attacker cannot modify the history for without it being obvious
<raggi>
raz: but you have to validate the log
<raz>
raggi: that problem does not change, CA or not
<raggi>
you use a key to validate the log
<raz>
i mean, it makes sense to have an authoritative root key somewhere, that can decide things (like a revoke-list)
<raggi>
that key is a form of a trust root
<raz>
but it doesn't have to be in the form of a CA
<raz>
raggi: yes, we're on the same page now i think
<dstufft>
raggi: What is your threat model
<raz>
raggi: it's only that you somehow want to implement this as a CA, which is not really related to logging
<raz>
raggi: i mean.. at the risk of circling again, it's in the proposal. he came up with the "chain history server" to tackle this exact problem - in addition to the CA.
<raggi>
to be clear, i'm not married to a CA
<raggi>
but a model with some central control
<raz>
oof
<raggi>
is important
<raz>
hehe ah ok
<dstufft>
Central control of what specifically
<raz>
well, central control is a rather blurry term
<dstufft>
IS there a threat model defined?
<raz>
there is already some control by the very nature of everything terminating on rubygems.org
<raz>
but i agree, a "master-key" might not hurt
* raz
wonders why everyone uses his irc nick on github
<Antiarc>
I'm not married to a "CA", I'm just married to the idea of some root cert that users can trust.
<raggi>
Antiarc: well, that and that we can replace once, fast, if we need to
<Antiarc>
A CA-like pubkey signing system flowed out of that because you need some way to grow the trust tree.
<raggi>
assume that every key in the system will be breached at some point
<Antiarc>
(and because that's how x509 already works, so there are no wheels to invent)
<theartisan>
dstufft: i think the problem is people are trying to come up with a perfect solution protected from every potential attack vector that could ever be perceived, as apposed to good enough.
<dstufft>
theartisan: Their is no perfect solution
<dstufft>
THere
<dstufft>
grammar ftl
<Antiarc>
I haven't at all tried to solve the "authentication" issue. I think that trying to solve authentication in this context is a fool's errand.
<theartisan>
dstufft: i know that :)
<Antiarc>
What you want to solve is identity, and let the rest flow from that.
<raggi>
dstufft: nothing documented re threat model
<Antiarc>
I'm of the opinion that email ownership is good enough for these purposes.
<theartisan>
creating an email is easy enough
<raggi>
we require emails today, that's fine :)
<dstufft>
If you don't have a threat model making proposals is a waste of time
<dstufft>
I mean I know the threat model that I outlined for PyPI/Crate.io and I'm happy to write that up.
<dstufft>
theartisan: looking
calmyournerves_ has quit [Quit: Leaving.]
<raggi>
could you point me at those
<dstufft>
raggi: I don't have them public atm, but gimme a minute
<theartisan>
it sums up to prevent a MiM attack, verify author of a gem, and be distributed
<raggi>
theartisan: how helpful
<workmad3>
I'd guess the central issue is gem provenence
<workmad3>
being able to prove that gem X is the same one that author Y created, and rubygems received, indexed and pushed out to mirrors
<dstufft>
raggi: Since RubyGems is basically the same as PyPI i'll write up my threat model and s/pypi/rubygems/ :)
<raggi>
dstufft: please, fi you could just post the pypi model so i could read it
calmyournerves has joined #rubygems-trust
alexmreis has quit [Quit: alexmreis]
<raz>
argh
* raz
just used the "x" to abort editing.. which deleted the comment
* raz
facepalm
<raz>
did anyone get a notification e-mail of my last comment that i could copy/paste from?
<raggi>
Antiarc: so, if we're signing user keys, we don't need to declare the chain in a gemspec
havenn has joined #rubygems-trust
<raggi>
Antiarc: i'm not sure if we want to declare sign key locations in gemspecs at all
<raggi>
Antiarc: the author email should do - we can search in known locations for keys wiht that name, and allow command line override
<raggi>
Antiarc: as we're relying on a signing history for gem<->author association
<raggi>
Antiarc: we don't need to remove authors on handover etc
<raggi>
Antiarc: each author gets authorized against a .gem, we simply check for revocations
<raggi>
if there is an authorization and no revocations, proceeed
<Antiarc>
raggi: I just ate, so my brain is rebelling and demanding sleep. Give me a moment to process that. :)
<raggi>
Antiarc: no problem :)
<raggi>
Antiarc: regarding countersigning wiht a project key, i'm not sure we need to do that
<Antiarc>
Yeah, what you're saying makes sense. I do want the ability to de-auth a key from a project, though, because of the situation where I started a project with my personal key, then later want to add collaborators without giving them authority on all my personal projects signed by that key
<raggi>
right, that's revocation
<Antiarc>
So I would sign a removal request for my key, and an addition request for a new project key, which would then sign project members' keys
<raggi>
my biggest concern wiht all of the proposals and discussions so far is the revocation model
<Antiarc>
Well, it's revocation from the history
<raggi>
as revocation for https is kinda easy
<raggi>
and services, etc
<Antiarc>
Which is slightly different from revocation from the general trust chain
<raggi>
revocation models for permanent data is harder
<raggi>
as you want to revoke after a date
<raggi>
or really in this case "after a release"
<Antiarc>
Yeah. I proposed downloading revocation lists on every gem network op, and you could maybe check the local revocation lists on every gem op
<raggi>
so, for example, charlie released 1.0.0 and 1.0.1, but he cannot release after 1.0.1
<Antiarc>
Not perfect, but there's not really any good way to do it if you aren't running a daemon
<raggi>
we also will sometimes want to do:
<raggi>
charlie released 1.0.1, but it was abusive
<raggi>
so we yank 1.0.1
<raggi>
and revoke his key from the whole trust mdoel
<raggi>
and he can push nothing new
<Antiarc>
Right
<raggi>
but anythign we didn't yank, is ok
<Antiarc>
The current revocation would yank anything that he signed, even the "okay" stuff
<raggi>
right, we want to be mroe flexible than that i think
<Antiarc>
I'm not sure what the right solution there is.
<raggi>
and that's really not easy
<raggi>
me neither
<Antiarc>
My first instinct is to tell project maintainers to re-sign anything that was signed by Charlie
<raggi>
it might be easier to manage it temporally
<theartisan>
isnt revoking 1.0.1 just as easily fixed by removing from index?
<raggi>
but that still has issues
<raggi>
as it can hit multiple gems
<Antiarc>
theartisan: You want to be able to have rubygems offer to remove it from local indexes, too
<raggi>
but maybe that would be an acceptable design constraint
<raggi>
Antiarc: if we want to resign published gems, the signing has to be outside the .gem file
<Antiarc>
So that I, as a gem consumer, is notified "yo, you have malware, uninstall it and don't allow Charlie to install anything else"
<raggi>
Antiarc: otherwise file integrity systems cannot validate things, adn we're back to single point of validation
<Antiarc>
I still say we just put authors' phone numbers in the gemspec and use Twilio to call them for audio confirmation during install.
<raggi>
Antiarc: that also breaks HTTP and mirroring really badly
<Antiarc>
Screw all this hi-falutin' security stuff :|
<theartisan>
Antiarc: see, why would i not want to allow charlie to do anything else? he might also have a very amusing troll.gem
<raggi>
Antiarc: WAGWAN RUDEBWOY, GOTS A GEM INSTALL FO YA SHIT
<workmad3>
Antiarc: pfft, gem authors should just hand out cds of their gems manually
<theartisan>
i just dont want him doing anything in specific gems
<Antiarc>
theartisan: The idea there is that Charlie added some bad code and is considered a security risk bad enough to lose his privileges.
<theartisan>
this feels more like a problem of authorization and access control than a web of trust
<theartisan>
i think its being over complecated
<theartisan>
take a look at the notes i threw in ticket #4 and let me know what problem it doesn't solve
<raggi>
Antiarc: that would mean i'd have received over 1 million phonecalls in 2013
<raggi>
that's 22 calls per minute
<raggi>
:'(
<Antiarc>
raggi: Well, that's your fault for being so useful now, isn't it?
* raggi
throws some toys out the pram
<raggi>
still
<raggi>
if i made it a paid number
kseifried has joined #rubygems-trust
<raggi>
i'd be loaded
<raggi>
screw it
<raggi>
push that shit
<kseifried>
drbrain: ping, you awake?
<Antiarc>
theartisan: In your proposal, if I pwn rubygems, I attach my pubkey to your account, I re-sign your manifest with my key (including my backdoor code), and it gets distributed to people, unless I'm missing something.
<raggi>
Antiarc: "wrest control" <3
<Antiarc>
theartisan: Or if I steal your rubygems API key (but not your private key), for example, I could do the same
<theartisan>
Antiarc: thats the same with the current proposal
<theartisan>
you just lock down the key adding stuff
<raggi>
i think it's the same everywhere, in every proposal, if all keys are stolen
<raggi>
but
<Antiarc>
Not at all; the current proposal entirely separates the key management from the distribution platform
<raggi>
the model should deal with immediate revocation
<raggi>
i.e. damage limitation
<Antiarc>
Principle of least responsibility.
<raz>
so looks like we have arrived at "the CA proves that a key belongs to an e-mail address"
<kseifried>
I was wondering is there a mailing list/some more formal place the discussion of rubygems signing is taking place?
<Antiarc>
raz: I've been saying that for a couple of days now :P
<theartisan>
i dont see why we care about the email address
<Antiarc>
kseifried: I posted a copy of that to the rubygems-developers list and the rubygems.org google group at qrush's suggestion, as well.
<raz>
Antiarc: my point remains, that seems a hell of a lot of work for something that.. solves what? :)
<raggi>
Antiarc: so, somewhat practical question, probably not really for the model, but we're close to implementation detail with the deaddrop part of the proposal
<theartisan>
"good enough"
<raggi>
Antiarc: if the client needs history, in order to validate authors, and we're deaddropping responses
<kseifried>
raz: thanks, one thing I'm hoping to do is have SST do a design review to ensure whatever you guys pick is secure, do you know whom would be best to talk to that about?
<raggi>
Antiarc: how can we be sure the distribution server has the keys available for the client before the user installs something
<raggi>
Antiarc: (think mirrors, and the CAP problem)
<raggi>
Antiarc: we have a number of options, i think we should just propose one
<raz>
kseifried: not sure tbh, i'm not yet clear about the decision process myself.
<raz>
anyone know how is calling the final shots on this?
<raz>
raggi?
<kseifried>
because the rubygems signing problem is something Red Hat has a little experience with and we'd like to help =)
<raggi>
raz: probably "the rubygems team"
<Antiarc>
I presume it would be the rubygems-developers and rubygems.org team.
<raggi>
raz: i will certainly provide feedback by reading everything - i have signoff from my higher up at google to use time to get this done
<kseifried>
my other concern at this point is also PyPI/Hackage/etc. :P
<raz>
kseifried: it would actually be great (i think) to get some people on the case who have actually done it before.
<theartisan>
the problem that needs to be solved is ensuring that the gem installed is the same gem that was sent to rubygems, and being able to lock down an install to a select group of trusted authors.
<kseifried>
raz: yeah hence me poking SST/etc
<raggi>
raz: but i've been largely disconnected from rubygems for the last two years (been too busy)
<raggi>
raz: so i'm hardly "an authority"
<kseifried>
raz: basically this is something I need fixed or my life will be very bad =)
<raggi>
raz: honestly though, a proposal will get some traction in the community
<Antiarc>
raggi: A deaddrop with a return confirmation before the gem goes into the public index seems like it should do it, but that means giving up A in CP
<raggi>
raz: and be implemented
<raz>
kseifried: hehe.. welcome to the boat ;)
<raggi>
Antiarc: right, that's probably fine
<Antiarc>
We just have to be sure that we keep the systems as dis-entangled as possible
<raz>
kseifried: well, if anyone from your side wants to chime in, i guess either the ML or the ticket would be a good place
<Antiarc>
Too much contact and you open up pivot opportunities
<raz>
kseifried: we're basically in "open for proposals and tear them apart" stage
<kseifried>
raz: ok. like I said the challenge will be getting SST team time, they're busy guys
<raggi>
Antiarc: we could also say, in the event of a C failure, where the gem arrives before the author key, the client warns (loudly), and gives the user an option
<raggi>
Antiarc: as this /may/ eradicate certain DoS vectors
<raggi>
Antiarc: along with a /small/ risk that we havent' eradicated anyway
<Antiarc>
raggi: In my mental model, each of the 3 systems (rubygems, CA, chain history) would be administered by different people with different keypairs, for example
<raggi>
right, exactly
<raz>
kseifried: yep. perhaps keep a tab on the ticket - if something crystalizes as a favorite it will likely be mentioned there
<kseifried>
raggi: failing open like that easily means attackers DoS and clients say "yes ok, just work damnit!"
<raggi>
so one may be offline for distribution separately
<Antiarc>
raggi: Yeah, I'm fine with eventually consistent as long as Rubygems is loud and tells people "try again in 5m inutes"
<raggi>
kseifried: i udnerstnad, but we're already (And always) vulnerable to key theft
<Antiarc>
DoS is mitigable via standard HA redundancy for each of the pieces.
<Antiarc>
Not solvable, of course.
<raggi>
kseifried: so it's not a whole lot better
<Antiarc>
But mitigable.
<raggi>
kseifried: and there will always be a "do it anyway" option
<raz>
Antiarc: all these things you casually mention there entail quite a serious workload for a bunch of volunteers ;)
<raggi>
kseifried: even if it's just for disconnected clients
<Antiarc>
raz: I'm happy to be one of them.
Perceptes has quit [Quit: Leaving.]
<kseifried>
depends what exactly you want signing to accomplish, also key theft can be dealt with in a variuety of ways to mitigate it
<Antiarc>
This is a serious job, it's going to take serious work.
<Antiarc>
No real way around that.
<raz>
Antiarc: ok, booked for the next 10 years :)
<raggi>
kseifried: i mean, i wouldn't make it "(y/n)"
<theartisan>
or do away with any central piece and theres nothing to DoS
<raz>
Antiarc: well, that's the gist of my argument: let's try to keep the infrastructure as simple as possible, because that's a huge problem if its own.
<raggi>
kseifried: i would prefer to make it "--i-know-what-the-fuck-im-doing-and-i-am-suitably-afraid"
<raz>
of*
<raggi>
kseifried: you get the idea
<Antiarc>
raggi: +1 for that flag
<kseifried>
one thing I'm not clear on is the focus, is it so sign gems so that from rubygems.org -> client is secure, or also including the developer in the chain? or both?
<Antiarc>
Both
<Antiarc>
You basically have to trust the initial publication of the gem
<theartisan>
kseifried: for some reason people want to solve every problem at once
<Antiarc>
But anything beyond that should be verifiable.
<raz>
we are not out to fix rubygems, we are out to fix cryptography!
<kseifried>
theartisan: dude... people are insane so I always ask the basic questions because I have been surprised :P
* raz
ducks
<theartisan>
kseifried: the intial plan was to solve rubygems -> client and that being able to verify author would be a nice bonus
<raggi>
kseifried: also please remember that git gems are unsigned, and so bundler needs a native bypass
<Malf>
kseifried: I'm not clear on the focus either. Seems like that's the first question that should have been answered.
<raggi>
kseifried: i mean, if bundler expects pgp signed git tags, then great
<theartisan>
but, that it should work on other gem servers too
<raggi>
kseifried: but i think rack is the only ruby project doing that
<Antiarc>
kseifried: That is a very good point.
<raggi>
kseifried: and i only tag releases
havenn has quit [Read error: Connection reset by peer]
<kseifried>
so does a Gem validly signed say 2013-01-01 by a cert expiring 2013-01-02, what happens after that? we treat the version signed at that date as valid forever, etc?
alexmreis has joined #rubygems-trust
<raggi>
yeah, this is similar to the revocation problem
<kseifried>
so my first comment would be you guys are working on solutions for a problem that is not fully defined yet :P
havenn has joined #rubygems-trust
<raggi>
kseifried: keep it coming
<Malf>
Of course the problem there is that no two people want quite the same thing.
<theartisan>
kseifried: dstufft is looking to fix that with the threat model defined for pypi
<kseifried>
raggi: oh I got a dozen of them, and then SST will probably poke more
<raggi>
:)
<theartisan>
hes writing it up properly with rubygems as a context instead
<raggi>
kseifried: i can poke some holes in models, but i'm not an expert, i want as much validation help as possible
<kseifried>
is there a mailing list or something with discussion and logging of such? I'm old fashioned perhaps but doing this via a ticket on github seems painful
<raggi>
i don't know why he's writing it up now
<theartisan>
that will help, there was a problem defined initially but it was all done in irc and not everyone was there for it
<kseifried>
raggi: you will hate me then =)
<raggi>
but yeah
<raggi>
kseifried: oh i agree, i'm happy to have the discussions on the ML
deus_rex has joined #rubygems-trust
<kseifried>
which one is the official for this? I should sign up
<raggi>
kseifried: i think it'll end up there, once the masses get bored
<raggi>
kseifried: none of this is official yet, i've been reluctant to take it on, but i get the feeling i'm going to need to
<kseifried>
the other thing I'm doing this weekend is seeing who else @redhat has time/wants to help
<kseifried>
raggi, : I know
<raggi>
kseifried: as is normal for resource limited volunteer orgs
<kseifried>
raggi, : the good news is red hat will have unofficial resources to give this
<raggi>
kseifried: those who actually do, rather than preach, basically win
<Antiarc>
And cross-posted to rubygems-developers@rubyforge.org for the client end of things.
<raggi>
kseifried: :)
<raggi>
kseifried: i've got sign off to use some google resources too, but i don't know who i can get, and how much, yet
<kseifried>
raggi: unfortunately this mostly lands in my mess to deal with. ahh the joys
samkottler has quit [Remote host closed the connection]
<raggi>
kseifried: it'll depend on need
* raz
is looking forward to redhat-rubygems :)
<raggi>
kseifried: i'll at least have some time available
<raggi>
kseifried: ^5, i know exactly how you feel
<theartisan>
RHEL doesnt have a rubygems package so its all good right? :)
<kseifried>
theartisan, : uhhh
<kseifried>
we ship it in several cloud products now
* theartisan
was just trolling
<kseifried>
CloudForms, OpenShift Online/Enterprise and ManageIQ
<kseifried>
but thankfully not in RHEL
<raggi>
yeah, google "doesn't use ruby" too
<raggi>
but, you know, bigcorps use everything
<raggi>
first thing tim bray did in response to my internal ML post was reply with "gem list -r | grep google" `i think we have plenty of interest in this`
<kseifried>
basically in 95+ we had Perl powering .com, and for cloud the winner is Ruby/Rails/gems
<kseifried>
and like any great hunk of software usage has sort of cneaked in and now it';s mission critical for everyone :P
samkottler has joined #rubygems-trust
alexmreis has quit [Quit: alexmreis]
samkottler has quit [Changing host]
samkottler has joined #rubygems-trust
<raz>
kseifried: how does yum handle this anyway? :)
<raz>
i know they have signing, but haven't looked deeper into it
<theartisan>
it concats a signature with a zip file
<raz>
and chained to a maintainer/root-cert?
<theartisan>
yum does not validate the author
<theartisan>
only the repo
<raz>
sounds like we're aiming higher than yum then
<theartisan>
similar to apt
deus_rex has quit [Ping timeout: 244 seconds]
<theartisan>
raz: see my earlier comments about solving all problems at once
<raz>
theartisan: hey, i'm the one arguing for the smaller solution ;)
<theartisan>
the initial goals of the project were to ensure gem installation was safe from man in the middle attacks
<samkottler>
which is what repo-based verification does
<samkottler>
:)
<theartisan>
that the gems on mirrors and sites could be verified to be the ones uploaded to rubygems
<raz>
theartisan: how boring. it didn't even take an hour to creep out of that baby-scope.
<raz>
;P
<Malf>
lol
<theartisan>
that it would be nice to be able to narrow the trust from rubygems to individual authors, but thats just a nice to have
havenn has quit [Remote host closed the connection]
<raz>
theartisan: yup that's the point where the camps started splitting (and afaik still are)
<Antiarc>
fwiw, an x509 chain is easily trustable on a user level
<theartisan>
and that whatever sollution is implemented, it should work relying on pure ruby and the existing dependencies of rubygems and ruby itself
<raz>
theartisan: that one is consensus currently i think
<Antiarc>
I'm actually of the opinion that the critical pieces should be built in non-ruby.
<raz>
Antiarc: the whole discussion hinges on different definitions of "trust" :)
<theartisan>
but drbrain mentioned there was some scope to a minimal change to ruby-core's depencencies if absolutely needed
<raz>
differing*
<Antiarc>
Not because I dislike ruby, but because it means that the discovery of a hole in <tool/framework/language/whatever> doesn't mean a compromise of the entire system.
<Malf>
right
<theartisan>
Antiarc: see, thats not going to get accepted into rubygems apparently
<Antiarc>
theartisan: The rubygems client piece would still have to be ruby
<raz>
hm, i'm not sure i understand how that would help?
<theartisan>
initial idea was to mimic apt
<Antiarc>
But things like a root cert signing mechanism and the cert history server could be non-ruby easily.
<theartisan>
gpg keys
<theartisan>
set of trusted ones
havenn has joined #rubygems-trust
<raz>
ah
<Antiarc>
right, but Evan shot down GPG a while ago
* raz
now understands
<Antiarc>
(for the rubygems client)
<theartisan>
but gpg is not availible everywhere
<theartisan>
windows and macs
<Malf>
well it is available there
<Malf>
but it's a non-zero effort to get it installed
<raz>
theartisan: amusingly we could probably use apt-verbatim if we really wanted. way overkill, but it doesn't get much more battle-tested ;)
<theartisan>
so then it moved to x509 as that was easier to implement client side
<Antiarc>
(and x509 signing is already in place in rubygems)
<theartisan>
as apposed to building a security audited gpg library in pure ruby.
<Malf>
I do question the notion that every client needs to be verifying everything all the time. Having all clients verifying doesn't seem to improve things much over just having the few that actually care verifying and counting on them to report issues.
<theartisan>
and from there things have creeped
<havenn>
theartisan: Neither GPG nor OpenSSL are installed on Windows by default, right?
<raz>
i demand my gems to be verified by Matz himself, on every installation
<Malf>
lol
<theartisan>
havenn: no, but theres a openssl thing for windows
<theartisan>
and you need it for rubygems to work anyway
<havenn>
theartisan: theres a gpg install for windows as well
<havenn>
theartisan: just pointing out the gpg/openssl availability is pretty similar
<theartisan>
havenn: it was all about adding dependencies, openssl is already present
<Malf>
you need it for rubygems anyway so it can download from https sites or?
<havenn>
theartisan: indeed
<raz>
i'm fairly optimistic the current scope creep will shrinky rapidly anyway as soon as someone starts an actual implementation and realizes what kind of work that is
<Malf>
lol
<Malf>
true
<theartisan>
i think https was the reason yes
<Malf>
I'm mostly concerned that will then turn into little to nothing happening so the few of us in here are all stuck rolling our own in-house solutions
<Malf>
where we have to manually sign stuff internally to keep tabs on it
<raz>
well, if all else fails i will try to lobby for my initial idea of "simply make the current signing mechanism mandatory" again
<Malf>
except for the precious few folks like raggi that at least provide some level of signing already
<Malf>
yeah
<raz>
i still think that's better than nothing, and a 70% solution is better than nothing
<theartisan>
one of the original requirements was that the setup be something that can be setup for local gemservers and such too
<theartisan>
which the CA stuff is going to blow away as its getting complicated :)
<dstufft>
raggi: raz Sorry I had a mini emergency here. I should note that I'm not a security expert. I'm an engineer on the security team @ Work and I work with a PhD and a some experts. I haven't yet had a chance to have them read over this thread model FWIW so take it with a grain of salt. But this is what I had sorted out for PyPI so far: https://gist.github.com/ed41838e6eab2ea47e1c
<raz>
dstufft: thanks!
<dstufft>
reading the backlog too the apt system isn't particularly useful for RubyGems as you can get a similar level of security just by enforcing SSL
<dstufft>
and DNSSEC
<raz>
dstufft: not quite, i think a large part of the apt-model is preventing mirror corruption
<raz>
s/large part/main concern/
<dstufft>
raggi: Does rubygems have mirrors? I didn't think it did
<dstufft>
er
<dstufft>
raz
<dstufft>
tab complete fail
<raz>
no, but as i understood it there is interest to go that way in the future
<theartisan>
dstufft: that looks to be about the same as what we started with originally
<dstufft>
but yes if you implement mirrors the apt system does provide a useful win for mirror safety
<raz>
if only to take that bandwidth bill off the rubygems volunteers
<raz>
lol, i like the _why example
<kseifried>
raz: brb, sec
<dstufft>
raz: Even as a Python guy _why is the best example I know of someone who published a lot of good stuff without any real identity beyond _why :)
<theartisan>
unfortunalty there was a great deal of discussion before the bot joined
<raz>
dstufft: i use tons of software with little idea about the people behind it. and i don't see why that should change (as you write, it's not possible to verify someones credibility in a meaningful way anyway)
davidfstr has joined #rubygems-trust
<raz>
theartisan: most of it was repetitive. i think the github ticket sums up the status quite well
<dstufft>
raz yea I don't think you need to know who X person is in the real world to use their software
davidfstr has left #rubygems-trust [#rubygems-trust]
<theartisan>
and of you google / redhat guys know more about how the java jar / maven signing works?
<dstufft>
urgh I have notes somewhere of how that works
<dstufft>
explained to me by a a friend who uses it extensively
<dstufft>
let me see if I can find those notes, they might be on my other computer
<theartisan>
dstufft: thats was the main inspiration behind my proposal
<theartisan>
and if thats where the pypi thinking was heading, then it seems like there must be something in it
<Malf>
It always seemed a little weird/inconsistent to me because it seems like there's X509 signing for JARs and a maven plugin to do that yet some of the bigger maven repos, like sonatype, explicitly require pgp signing instead
<theartisan>
it seems to resolve around the idea that multiple keys can sign a jar, and if one of them is trustworthy you just go with it
<dstufft>
theartisan: Note: I'm not affialted with PyPI, I run a mirror off PyPI that also mirrors metadata and such hat i'd like someday to replace PyPI with but i'm external to the system
<theartisan>
dstufft: well, i ment your index stuff
<dstufft>
theartisan: I have a rough draft of my ideas for PyPI too, though it's only a rough draft and doesn't include all of the reasons why I rejected a traditional CA and such too
<Malf>
"jarsigner uses key and certificate information from a keystore to generate digital signatures for JAR files. A keystore is a database of private keys and their associated X.509 certificate chains authenticating the corresponding public keys. The keytool utility is used to create and administer keystores."
alexmreis_ has joined #rubygems-trust
<Malf>
So it leaves folks from the outside, like myself, a little confused about what's what in that world
<theartisan>
the model as i understand it though, is i sign my jar, and the repo woulld also sign it, and if either me or the repos keys are trusted the jar gets installed
<dstufft>
I should note I think it's more usual for projects to setup their own Maven repos than for Ruby/Python having a central Repo
<theartisan>
i may have that completely wrong
<theartisan>
dstufft: there are multiple ruby indexes, just not the size of rubygems, and project specific ones exist for internal gems
<Malf>
part of that proposal remind me of the timeline servers from EFF's soverign keys proposal to mitigate some of the problems in the CA space today
<Malf>
s/remind/reminds/
* theartisan
isnt sure the multiple keys thing is entirely needed
<theartisan>
dstufft: how does the installer validate the package against the repo?
<dstufft>
theartisan: Multiple key thing came from a guy in the tor project wanting that ability
<theartisan>
it would be nice to have the multiple signing though, protects against a single rouge dev nicely
<dstufft>
theartisan: What do you mean "validate the package against the repo". The trust file contains all the valid keys for that package. (The trust file is only needed if you want multiple keys really, if you stick to 1 key per project you can toss it out). The system would use a local database of Project: Valid Key, The question is how to bootstrap that list in a way that is friendly to the user.
<dstufft>
The "Reasonably Secure" option would just prompt the user and trust the first key it finds and use that to bootstrap the trust for that particular project.
<dstufft>
it's basically SSH but for distributions
<tarcieri>
and repeat that for N gems
<tarcieri>
on M servers
<theartisan>
ah
<theartisan>
i get it now
<tarcieri>
you want people to validate N*M random numbers?
<tarcieri>
seeeeeeeeeeeeeeeems bad
<theartisan>
so the need for central certs was basically the "how do we get users to authorize a gazillion keys"
<theartisan>
your trying to solve it in the client, as apposed to infrastructure
<dstufft>
People aren't going to validate them, they'll jsut implictly accept it. But that's ok because the vast bulk of time your system is fine (see how long Rubygems/PyPI has operated without a breach).
<dstufft>
FWIW it's also similar to how Deiban etc bootstrap trust
<dstufft>
you download the CD key which contains the root key
<dstufft>
er cd iso
<theartisan>
yeah, and add anything extra
<dstufft>
bootstrapping intial trust securely is near impossible over the internet
<theartisan>
but the issue there becomes that debian distribute a huge amount of packages and fewer extras are needed
<dstufft>
I can't parse that statement, what do you mean?
<theartisan>
so the debian repos contain most of the packages you will need, then you add a few extras for the left over stuff
<dstufft>
Ah, but how do you verify the main debian repo
<dstufft>
the apt key that came baked into your CD ISO right?
<dstufft>
which you went to their server and downloaded without verificaiton :)
<Malf>
right
<dstufft>
if the debian.org server was compromised when you downloaded that ISO you would have a comrpromised trust root
<Malf>
perhaps you ran some checksums on the download, asked for someone else to verify a key on IRC in #debian perhaps
<Malf>
but even that's more effort than I expect from most
<dstufft>
But it's "ok" but the vast majority of the time the debian.org server is not compromised
rafaelfranca has quit [Ping timeout: 245 seconds]
<theartisan>
yeah, its more the UX issue of adding certs
<dstufft>
just like the vast mjaority of the time the RubyGems.org server isn't, nor is the PyPI
<dstufft>
The "hole" here is someone installing a gem for the first time (on that computer) after rubygems has been compromised and before it's been discovered (and shutoff)
<dstufft>
which is a similar whole that Debian has w/ their baked in CD key
<dstufft>
The UX would literally be "This is the first time we've seen this key for this project, do you want to accept it y/N",
<dstufft>
99% of people will jsut hti yes
<dstufft>
and that's fine because the vast bulk of time hitting yes is the right thing, and when it isn't, other people who already hit yes will be installing that gem for the 2nd, 3rd, 4th time and they'll get an error message saying "Hey this signature doensn't match, i'm aborting"
<dstufft>
you get herd protection
<theartisan>
my personal thoughts were to just trust the repo to do the right thing
<dstufft>
What do you mean trust the repo to do the right thing? Unsure what that translates into
<theartisan>
it pushes more on rubygems but i dont see that as a problem
<theartisan>
so having the repo ensure the package its getting is from teh right person and just signing it to say "this was uploaded by someone from that project"
<theartisan>
and then trust the repo to work
<tarcieri>
dstufft: that's terrible UX, just saying
<tarcieri>
dstufft: I'd call it unacceptably bad
<theartisan>
if thats not good enough then add the individual keys
<theartisan>
tarcieri: its not that bad
<tarcieri>
it's pretty bad
<theartisan>
terrible ux would be having to go fetch all those keys out of bounds
<tarcieri>
out of band?
<theartisan>
which is why the apt model was shot down
<theartisan>
that you would have to go do things outside of the install command to make things work
<dstufft>
theartisan: THat's basically the situation you're at now
<dstufft>
trusting the repo
<theartisan>
e.g. gem cert --add <cert> for every author
<dstufft>
that doesn't protect you if the repo itself has been compromised
<theartisan>
the thing is, for the most part thats ok
<dstufft>
tarcieri: It's not an ideal ux, but it's not terrible, and it's one pretty much every programming is going to be familar with via SSH.
<theartisan>
as long as the repo is sending the gems it had uploaded
<theartisan>
the problem then becomes a case of keeping the signing cert safe
<tarcieri>
dstufft: why are you even bothering to prompt the user for unknown certificates at that point?
<theartisan>
tarcieri: because if your building things for a bank you will go vet all those certs
<dstufft>
tarcieri: Because they are unknown? If you just implictly accept them there is no difference between a trusted distribution and an unknown distribution
<tarcieri>
do you really expect some sort of due diligence on their part?
<dstufft>
No, I exept them to hit Y
<tarcieri>
or do you expect them to blindly accept every certificate
<dstufft>
I mean ideally they'll verify them
<tarcieri>
so you expect them to hit Y
<dstufft>
but they'll hit Y
<tarcieri>
why are you prompting them?
<tarcieri>
you're getting 0 real trust out of this system
<dstufft>
Because no sane security person will tell you to treat unknown and trusted distributions the same?
<theartisan>
tarcieri: as i said, SOME people will vet them, and those people are generally the ones who will be most hurt by a compromise
<tarcieri>
dstufft: as a "security person" myself, I think that entire approach is complete bullshit
<tarcieri>
dstufft: you've already given up on actually authenticating the certificates
<tarcieri>
just hit Y
<dstufft>
tarcieri: What are your credentials please.
<tarcieri>
dstufft: I'm 303 bro
<tarcieri>
lol
<dstufft>
tarcieri: The security guys who I pointed to your post laughed FWIW
<tarcieri>
cool story bro
<pencil>
what if the user was prompted to copy-paste the key-fingerprint?
<tarcieri>
but hey, carry on with your security theater
<dstufft>
Man whatever. I don't really care if Ruby decides you're the coolest kid on the street and lets you run a CA, when it gets hacked I'll be happy that i'm not a rubyist.
<tarcieri>
lol
<pencil>
stop crying...
<dstufft>
Your entire premise is that _you_ want to run a CA
<tarcieri>
dstufft: or RubyCentral
<tarcieri>
read my post... harder
<dstufft>
tarcieri: And how do you plan on validating trust in your CA
<dstufft>
How do you plan on validating that XYZ is authorized for ABC
<tarcieri>
something similar to the Freenode Groups model
<tarcieri>
which, granted, did not scale
<dstufft>
So no one can push a gem until they go through a process which did not scale in the past
<tarcieri>
I think the approach I'm suggesting probably won't work simply because there aren't enough volunteers interested
<tarcieri>
all the poisoning of the well that's been going on here hasn't been helping
<dstufft>
is a CA theortically better? Yes absolutely. The problem is between theory and practicality. Theortically you'll have enough informatin to validate that so and so can release xyz, theoretically you'll set up a secure system that won't get hacked. pratically you'll be man power starved. Which will result in people not getting certs for a long period of time, which will result in the security on the box getting laxer
<dstufft>
and laxer until it gets owned and then *everyone* is vulnerable.
<tarcieri>
thanks for repeating what I just said
<tarcieri>
that really clears stuff up
alexmreis has quit [Quit: alexmreis]
serge has joined #rubygems-trust
<havenn>
Is there a canonical place for storing gem-private_key.pem?
<havenn>
Would it be? ~/.ssh/
<tarcieri>
havenn: somewhere in ~/.gem would probably make more sense
<theartisan>
i would prefer ~/.ssh
<tarcieri>
o_O
<tarcieri>
what does it have to do with SSH?
<theartisan>
nothing really but thats a secure folder
<havenn>
tarcieri: I've got other files ending with .pem in there >.>
<theartisan>
and things start getting broken when its not
<tarcieri>
encrypt your .pem
<dstufft>
Ew don't put it in .ssh
<tarcieri>
that will keep it a lot more secure than file permissions
<tarcieri>
and yeah, it just doesn't belong in .ssh
<tarcieri>
it's not ssh-related
<havenn>
tarcieri: just unencrypt for gem building?
<tarcieri>
confirm
<theartisan>
i have a habbit of leaving all my keys in .ssh as i know i have to not do retarded stuff in that folder.
<theartisan>
like accidentally deleting it
<whitequark>
what about gpg keys?..
<kseifried>
raz: ping you still around?
cbetta has left #rubygems-trust ["["Textual IRC Client: www.textualapp.com"]"]
<havenn>
If RubyGems `gem cert --build ...` instructions were updated with recommendation of where to put .pem files, the need to encrypt/unencrypt them, and how to get them listed on (not yet existing) CA - I for one would jump at signing my gems (not that anyone uses them so kinda moot point but...)
<havenn>
tarcieri: Would it be viable for `gem cert --build` to query for a password and encrypt the file, then `gem build` decrypt it temporarily? Or is that the gem authors domain/responsibility?
<theartisan>
havenn: that doesnt matter, the fact you know when heroku installs your gem, it IS your gem is the problem thats to be solved
<tarcieri>
havenn: I think ideally it'd prompt you for your password at the time of gem signing and decrypt the key solely for that purpose
<havenn>
theartisan: Hence my desire to have encrypted private-key be the default, so we have a modicum of certainty that what appears to be my gem is from me (whoever me is, I know I'm me!!)
<tarcieri>
havenn: have you watched Ben's talk? (from the topic)
<tarcieri>
havenn: he has a gem that steals your ~/.gem/credentials
<tarcieri>
encrypting them... seems good?
<tarcieri>
lol
<theartisan>
all private keys should be encrypted by a passphrase anyway.
<havenn>
tarcieri: I have to rewatch the talk, I missed that!
<Antiarc>
.gem/credentials aren't private keys
<tarcieri>
.gem/credentials aren't at present
<tarcieri>
Antiarc: doesn't matter, they're a capability and should be stored encrypted
<Antiarc>
tarcieri: I absolutely agree, just clarifying that they aren't keys
<havenn>
Is it sane to set the default location for storing the encrypted gem-.pems to be ~/.gem/ folder itself then? A subfolder?
<tarcieri>
havenn: could do something like ~/.gem/private
<Antiarc>
I'm using ~/.gem/trust
<theartisan>
subfolder
<theartisan>
as you may have multiple key pairs and will want to not clutter up main folder
<havenn>
And `credentials` file should also go in the private/ or trust/ folder?
<havenn>
Or is that truly public?
<whitequark>
don't forget marking it as 0600, as ssh does
<whitequark>
both credentials and private key, preferably
<whitequark>
gpg refuses to work if the permissions on key material aren't tight enough
<tarcieri>
havenn: personally I'd put ~/.gem/credentials in ~/.gem/private and encrypt it with a passphrase
<havenn>
tarcieri: That seems to be a nice potential default.
<theartisan>
whitequark: so does ssh :)
mephux has quit [Excess Flood]
mephux has joined #rubygems-trust
workmad3 has joined #rubygems-trust
<raggi>
tarcieri: yeah, it's not critical detail yet, but i don't see why the standard distribution should allow empty passphrases for keys at all. I'd rather we only implement an OTP unpacking code path and nothing else
<tarcieri>
raggi: encrypted keys/creds ftw
<raggi>
right
<raggi>
tarcieri: i'm alarmed at how many people use weak encryption for ssh keys too
<tarcieri>
heh yeah
<raggi>
ssh-keygen still has shitty defaults afaik
<theartisan>
tbh, if people want to be idiots, let them.
<tarcieri>
unfortunately SSH lags behind the state-of-the-art quite a bit
<tarcieri>
theartisan: I like removing sharp edges from cryptosystems wherever possible
<raggi>
well, fairly recent versions, even up to maybe 2 years ago (uncertain) defaulted to 3des
<raggi>
i mean, it's an OTP, so it's not as important
<tarcieri>
still not as bad as MS-CHAPv2
<raggi>
but still
<tarcieri>
MS-CHAPv2 wanted to do 3DES
<theartisan>
hpk is a really simple protocol right?
<tarcieri>
but
<raggi>
you have better shit available
<tarcieri>
they were confused
<tarcieri>
lol
<whitequark>
tarcieri: rbnacl is a problem
<tarcieri>
instead of 3DES, they did... 3 independent DES keys
<tarcieri>
whitequark: why?
<whitequark>
tarcieri: well, unless you get it into the mainline, complete with vendored nacl
<tarcieri>
whitequark: I'm not suggesting using it for the stock RubyGems cert stuff
<whitequark>
tarcieri: oh.
<tarcieri>
whitequark: also libsodium is kind of a PITA to install right now
<tarcieri>
RbNaCl is definitely "eager early adopter" crypto stuff ;)
<namelessjon>
But hey, we actually have most of it implemented now. And libsodium installs very easily on archlinux, at least
<tarcieri>
yeah def
<tarcieri>
I plan on using it to rewrite keyspace's crypto
<whitequark>
tarcieri: btw as we're talking about PKI, can you enlighten me? an RSA signature is just a hash encrypted with the secret (as opposed to the public) key?
<tarcieri>
whitequark: I think I was wrong in my blog post... RSASIG is more than that, I think
<tarcieri>
I dunno I haven't bothered learning about it because there's Ed25519 ;)