<raz>
theartisan: there's actually not much wrong with it
<raz>
it lacks only a single letter :)
<raz>
(trust-wise that is)
<theartisan>
raz: its slowly conditioning people to willingly run scripts in their console without checking them.
<theartisan>
thats a bad thing
<raz>
theartisan: as opposed to running opaque installers on their console without checking them?
<raz>
the above mechanism at least makes it very easy to *do* check if i want
* theartisan
is tempted to create one of those scripts that does an obfuscated `sudo rm -rf /`
<raz>
really, it's not a bad thing when you think it through
<theartisan>
yes it is
<theartisan>
its as stupid as downloading random tarbals and running ./configure in them
<raz>
what's the alternative then?
<theartisan>
apt-get install <package>
<raz>
sure. that works for ~50% of the software the everyone needs.
<raz>
the other half, we just should not install? :)
<theartisan>
for varing values of apt-get
<raz>
so you're basically asking for every package to be reviewed by a trusted third party
<raz>
i think we had that debate in the context of rubygems :)
<theartisan>
no, im expecting every package to be reviewed by a trusted party, first, third or otherwise
<raz>
it's a noble goal, but ultimately leads to a debian-repository (with lots of trusted and stable but outdated packages)
<raz>
still a noble goal, now try to reconcile it with reality :)
<raz>
you did install your browser via apt-get, right? ;)
<theartisan>
no, it was installed from apples repo ;p
<raz>
well, but at least you read the entire source code before actually running it
<raz>
i understand, i do the same, but it's not reasonable to expect all users to do that
<raz>
in fact i still have the last few thousand pages of diff from the last update on my kindle :P
<theartisan>
theres a difference between trusting vendors, and your first interaction being the running of a script that you often cant read off the internet
<theartisan>
have you seen the chef one?
<raz>
don't get me started on chef
<raz>
that thing is broken in every possible way and just needs to die
<raz>
anyway, how did we slide into this debate ;)
<theartisan>
someone mentioned it earlier
<theartisan>
and i was feeling ranty because it started snowing outside.
<raz>
it probably deserves a wikipedia-page by now, given how often it comes up
<theartisan>
i have no intrest in the opinions of developers who thought it would be a good idea to release a framework that exposed the backend mongo db to anyone with a browser console.
<raz>
yes, meteor is terrible, but that post goes to show even those people have their bright moments
<raz>
his assessment of 'curl | sh' is coherent
<raz>
i was in fact surprised to see such a well-reasoned argument from that particular direction
jstr has quit [Quit: Computer has gone to sleep.]
<raz>
(it also serves as a reminder how meaningless "credentials" are and that you should always look at the argument at hand)
billdingo-afk is now known as billdingo
workmad3 has joined #rubygems-trust
geal has joined #rubygems-trust
geal has quit [Read error: Connection reset by peer]
geal_ has joined #rubygems-trust
geal_ has quit [Ping timeout: 240 seconds]
geal has joined #rubygems-trust
qmx|away is now known as qmx
geal has quit [Ping timeout: 252 seconds]
geal has joined #rubygems-trust
geal has quit [Ping timeout: 252 seconds]
bfleischer has joined #rubygems-trust
bfleischer has quit [Quit: bfleischer]
billdingo is now known as billdingo-afk
geal has joined #rubygems-trust
qmx is now known as qmx|away
geal has quit [Ping timeout: 245 seconds]
ereslibre_laptop is now known as ereslibre
_kgo_ has joined #rubygems-trust
<_kgo_>
From that ycombinator link above, the meteor dev assumes that because the transport layer (https) is secured, you couldn't possibly get a compromised file.
<_kgo_>
The problem with a curl install is that you need to examine/audit the entire codebase every time you install.
_kgo_ has quit [Client Quit]
<raz>
that problem exists with every install method though
<raz>
it's a circular argument :)
<theartisan>
not if you download once and package
<raz>
you still have that problem at "download once"
<raz>
it's not going away and really, it's not that hard to grasp, is it? ;)
<theartisan>
download once, check, package
<theartisan>
better?
<raz>
if you rely on "check" then what does the install method matter?
<raz>
you can do that with any method, and the curl method actually makes it much easier than most others
bfleischer has joined #rubygems-trust
samkottler_ has joined #rubygems-trust
theartisan has quit [Ping timeout: 276 seconds]
samkottler has quit [Ping timeout: 276 seconds]
samkottler_ has quit [Changing host]
samkottler_ has joined #rubygems-trust
qmx|away is now known as qmx
billdingo-afk is now known as billdingo
theartisan has joined #rubygems-trust
geal has joined #rubygems-trust
samkottler_ is now known as samkottler
geal has quit [Ping timeout: 240 seconds]
havenwood has joined #rubygems-trust
geal has joined #rubygems-trust
<dstufft>
raz: I think the assumption is that once it's been checked the packaging tools will verify it's always the same download
<raz>
dstufft: well, that's not what the discussion was about :)
<raz>
if you can rely on some sort of "check" the whole problem just got a whole lot easier
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubygems-trust
qmx is now known as qmx|lunch
geal has quit [Ping timeout: 255 seconds]
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubygems-trust
havenwood has quit [Ping timeout: 244 seconds]
<raz>
dstufft: perhaps rubygems could piggyback that
<dstufft>
raz: Dunno :) It was mentioned in the parallel discussion in the Python threads trying to achieve the same thing (the authors are also Python guys so they've chimed in too) Figured i'd show it over here incase Ruby found it useful
<raz>
well, i didn't read anything yet.. just from a glance it looks like they've been thinking about it for a bit ;)
<raz>
it would definitely be nice if some sort of standard would emerge
qmx|lunch is now known as qmx
workmad3 has quit [Ping timeout: 255 seconds]
qmx is now known as qmx|brb
havenwood has joined #rubygems-trust
lmarburger has quit []
lmarburger has joined #rubygems-trust
qmx|brb is now known as qmx
billdingo is now known as billdingo-afk
billdingo-afk is now known as billdingo
drbrain has quit [Remote host closed the connection]
jstr has joined #rubygems-trust
jballanc has left #rubygems-trust [#rubygems-trust]
<raggi>
so i'm looking for folks to get on the comment list too, ideally folks who have a dog in the game (e.g. security folks from large vendors/user groups/open source teams), etc
<theartisan>
raggi: is it worth adding rubygems and rubygems.org to the definitions for any non ruby people?
workmad3 has joined #rubygems-trust
<theartisan>
i initially conflated the two in my head, i can see it being the same for others.
<dstufft>
:V
<dstufft>
There's a difference? :/
<raggi>
theartisan: good point
<raggi>
dstufft: yes, very much so
<theartisan>
dstufft: like eggs and pip
<theartisan>
vs pypi
<dstufft>
Suddenly the interchanging of rubygems and rubygems.org in the document you linked makes so much more sense
<theartisan>
maybe definitions should be near the start?
* dstufft
swears he's gonna learn this ruby thing one of these days
<theartisan>
dstufft: its not that hard :)
<dstufft>
raggi: btw one of the guys behind that TUF thing has been somewhat contributing in the related threads on the Python mailing lists. Although the bulk of those threads are people arguing over various implementations w/o a doc like this
<dstufft>
theartisan: :) I'm sure. It's a matter of sitting down and doing it
<dstufft>
and not being "ARGH THIS IS DIFFERENT THEN WHAT I KNOW, GOING BACK TO PYTHON"
<theartisan>
as a python dev, i was able to write really bad ruby straight off the bat with the ruby docs at hand
<theartisan>
then again, i switch languages frequently depending on who's paying the most and what the team needs so i might have had an easier ride.
<raggi>
dstufft: yeah, not surprised about that, that's pretty much all we've had here too so far, just x509 vs pgp
<theartisan>
is it worth suggesting a joint effort with the python community?
<theartisan>
more eyes vs serving two masters
<dstufft>
someone did contact the FSF and was told by some volunteer there that we could bundle GPG w/o infecting the rest of the code with GPL
<dstufft>
Though none of the PSF lawyers have been asked to verify that yet
<raggi>
theartisan: yes, certainly worthwhile, our trust model issues are identical
<theartisan>
dstufft: you have swing there right?
<dstufft>
Yea that's why I joined up here, mostly to see if I could steal stuff for Python, and try to cross information where I can
* theartisan
hasn't used the python mailing lists in an age
<dstufft>
theartisan: Well I got friends who got swing :) I'm not so important myself Most of my work is external to the central stuff because I got fed up with the Politics of a few members, but The security stuff is being pushed through by a few friends of mine
<dstufft>
Nick Coghlan is one of them who commented on that google doc about sharing information
<dstufft>
oh you guys posted that to your mailing lists, Ima goahead and do it to the Python ones and mention we should try and work together since our problems are basically the same minus language
<raggi>
yep
<theartisan>
once this docs finished the implementation details can diverge
<raggi>
and honestly, if one product goes with openssl backed and the other pgp backed, it really makes no difference
<dstufft>
ya
<raggi>
it's the model that matters much much more
<dstufft>
I said as much when people were arguing over GPG vs Something else, that unless we can use the GPG trust model (we can't!) then the actual signing tech is pretty boring thing to argue over
<raggi>
right
<raggi>
it's actually irrelevant, this tuf stuff looks important though, i need to read it all
<raggi>
initial scan of the front page and head of the paper says "this is the prior art i was looking for", but the devils always in teh details
* theartisan
predicts npm being the hardest sell
<raggi>
npm can do what it wants really, but by the time RG and Pypi have come up wiht something workable, they'd be unwise to try and invent yet another solution
<geal>
they'll reimplement GPG in JS!
<theartisan>
raggi, i was thinking hardest sell that it needs to do something
<dstufft>
epsecially if we can abstract out the details and document it in a language agnostic way
<raggi>
haha
<dstufft>
node.js is further a long then PyPI is :(
<tarcieri>
raggi: really doubt that will stop them from inventing something new
<dstufft>
They have a valid SSL cert and everything!
<raggi>
right, that's not a goal right now, but something that we might do after
* theartisan
is a node developer.
<raggi>
tarcieri: we should put some threads in the design, just to troll them
<dstufft>
theartisan: I installed a node once, does that count?
<tarcieri>
lol raggi
<theartisan>
dstufft: no, but help yourself to a cookie anyway.
<raggi>
heh, so TUF is a library
<raggi>
o0
<dstufft>
Written in Python I think yea, they have/had an example PyPI up with it, though I don't think they were using the actual PyPI code
<raggi>
yeah, i mean, we're at best going to end up implementing the spec
DonOtreply has quit [Quit: Computer has gone to sleep.]
<dstufft>
What you mean Ruby doesn't want packaging tools written in python? ;)
<raggi>
rubygems depending on python seems wrong
<raggi>
hehe
<theartisan>
we could use the ruby code in npm, node depending on ruby, depending on python
<theartisan>
see just how suicidal we can make the worlds sysadmins
<dstufft>
need to add some Perl and Haskell in there
<raggi>
nah, obscure autotools directives that aren't on all platforms
<raggi>
interesting, so TUF is quorum based
* raggi
reads on
<theartisan>
i keep pondering about packagist and pear in the php space
<raggi>
theartisan: they're in the same place
<raggi>
theartisan: basically everyone is
<raggi>
there are minor differences in ssl support for distribution, and levels of signing support, but model wise, everyone has similar holes
<theartisan>
raggi, they dont really have a package format for the packagist/composer stuff though, is all repo checkouts
<raggi>
theartisan: right, go basically does that too
<dstufft>
The coming of age of the language specific packaging systems
<raggi>
dstufft: confirm
<theartisan>
which will make signing harder right?
<raggi>
theartisan: well, you could apply a restriction taht says only signed tags / signed commits
<raggi>
theartisan: which might work ok with git, in some ways, as it ensures the whole history
<dstufft>
or sign a bit of data that contains a sha that gets installed
<dstufft>
outside of git
<raggi>
theartisan: but even then, i wouldn't trust a signed commit any more than a signed gem, in the arbitrary
<raggi>
theartisan: and the transport system, revocation model, and pubkey distribution are still important
<dstufft>
but yea, actually signing things is the least interesting part of the whole discussion
<dstufft>
you can always find _something_ to sign
<theartisan>
php has phar's but their a bit retarded so nobody uses them :)
<dstufft>
hrm
<dstufft>
Think my message to the python mailing lists got caught by some sort of spam filter, guess i'll need to go bother the mailman admins
<dstufft>
wanted to show off the awesome doc you guys made :)
<raggi>
dstufft: if there are specific people it's worth my talking to, please put them in touch
<raggi>
i don't know anything about the python community, so i wouldn't know who's who
<theartisan>
raggi, google must still have GvR's number, even though he jumped ship right?
<theartisan>
:)
<dstufft>
You're unlikely to get GvR to care much tbh, he mostly ignores packaging
<dstufft>
most likely response will be for him to trust what the folks he trusts who do care have to say
<raggi>
theartisan: yeah probably
sj26 has joined #rubygems-trust
<theartisan>
the one potential problem i see ahead is moving a solution from one language through language holy wars to others, the smart people will be receptive but for every one of them there will be a bunch of idiots chiming in on the conversation going "wtf ruby sucks." :(
<dstufft>
that's ok, Python sucks too
<dstufft>
;)
<raggi>
i have a place for those people, it's my ignore list.
<raggi>
"Timestamp role"
<raggi>
hmm
* raggi
strokes beard
<dstufft>
Supposidly the TUF stuff is supposed to allow you to be as simple as 1 key per project (single developer libraries, simple use case) and let you split up the roles so that you can require multiple people to sign off (timestamp role and such)
<raggi>
i'm halfway through the spec
<raggi>
it looks good so far, although i have mounting concern about size of implementation
<raggi>
i'm swinging toward doing a spike os far though, and see what it's like
<raggi>
i had considered the timestamp role as i was going through the requirements doc, as time is an obvious component that isn't well resolved in other systems. their approach is interesting
<raggi>
not that novel, but if it is proposed to work, maybe worth trying (being not novel isn't a bad thing)
<raggi>
interesting, so this spec seems pretty good, although it may get kinda metadata heavy in short order
workmad3 has quit [Ping timeout: 256 seconds]
<dstufft>
raggi: That's good to know :) I looked at it briefly awhile ago, but foolishly dismissed it becuase I was still operating under the thought that PyPI could be removed from the trust equation all together, although i've since come around that as long as PyPI _is_ the central authority for who owns what name, that actually doing that is probably impossible ;)
<raggi>
right
<raggi>
we have namespace authorities, that's part of the problem
<raggi>
TUF does address that, which is good, also the fnmatch style delegation seems good
<raz>
may want to consider getting rid of that authority java-style
<raz>
although that's a longterm-goal
<raggi>
not 100% on the use of canonical json, but that's totally fine, they have a lot of metadata
<dstufft>
Namespace authority? e.g. Bob owns rails.* ?
<raggi>
yes
<raz>
com.37signals.rails
<dstufft>
ah intersting, hows that work out for you guys? There was some chatter about adding that to PyPI, although it was only a bit of chatter
<raggi>
dstufft: you mean anyone can publish to any namespace in pypi?
<raggi>
i.e. i could publish wsgi
<raggi>
or w/e
<dstufft>
raggi: you could publish to django.foo or something like that
<raggi>
oh right
<dstufft>
as long as someone else doesn't have django.foo already
<raggi>
yeah, so what i mean by namespace isn't rails.*
<raggi>
it's `rails` (any version)
<dstufft>
ah
<raggi>
it's acutally name-version-platform, and you get access to name with any version and platform
<dstufft>
gotcha, so you can give only certain people the ability to release rails for a particular platform or such?
<raggi>
no, just "rails" in general
<raggi>
with this system, it would be possible to say "for these versions and these platforms"
<raggi>
which is interesting, but certainly not a requirement right now
<dstufft>
ah ok
<raggi>
might make sense for binary gems though, as they're more "scary" for most users, being that most users are going to have serious trouble disassembling and reading them
<dstufft>
well it's good to have something flexible too, I might make an automated builder and give it a restricted ability to upload binaries
<raz>
hmm nice
<raz>
require 'foo.bar' doesn't choke
<raggi>
so there was mention early on in the spec about thandy and tor
<raggi>
but then the technical aspects in the spec didn't discuss that at all
<raggi>
time to rtfs
<raz>
just move to java-style package naming then and you can unload the entire problem onto dns
<dstufft>
One of the Tor guys was attributed in the the white papers
<dstufft>
raggi: DNS has a different trust model ;)
<dstufft>
er
<dstufft>
raz
<dstufft>
fucking tab complete
qmx is now known as qmx|away
<dstufft>
Techincally you could just use code signing certs from the CA's, you trust less people that way then you do assuming dNS
<dstufft>
and to actually use DNS you'd need to use DNSSEC
<raz>
dstufft: sure, but it kills most flies with one stone, namespace, public key lookup etc.
<dstufft>
since it's trivial to hijack DNS otherwise
<raz>
if your network is MITMed you're screwed in any model either way
<raz>
unless you have *some* key preloaded (e.g. the rubygems.org ssl key)
workmad3 has joined #rubygems-trust
<dstufft>
If you're going to trust DNS w/o DNSSEC you might as well just not use it at all, it'd be like just using HTTP
<raz>
the pkey still has to match the pkg signature
<raz>
anyway, i'll see what you're coming up with ;)
<dstufft>
moxie did an interesting talk (although it was about SSL certificates) about attempting to get rid of the CA's, and how one of the ideas is pushing it ito DNS
<raz>
CA's are largely worthless since you can't normally trust one that is not your own
<theartisan>
because dns poisoning is never a problem.
<dstufft>
theartisan: sarcastic or not? ;)
<raz>
i meant in the context of gem signing
<theartisan>
im english, everything i say is sarcastic
<raz>
but we've had that discussion over and over, no need to roll it up yet again ;)
<raggi>
lol
<raz>
the internets are distributed and should be treated that way :)
<raz>
definitely makes sense, as usual adoption is the problem
<raz>
personally i believe in "i'll trust what i trusted last time" ;)
<raz>
and i wish browsers supported that more eagerly
<raz>
alternatively i'd settle for "10 million people trust this cert for google.com"
<raz>
but that's a lot harder to implement :)
<dstufft>
:0
<dstufft>
convergence has a firefox plugin that turns off the CA trust list and switches to using convergence, I thought about trying it out for a bit but I don't use firefox and my willingly to try it out didn't include switching borwsers
* theartisan
operates on a belief that 99% of the worlds population are idiots, so 10 million people trusting something does not inspire much from him.
<raz>
theartisan: it only translates to "google probably served this cert most of the time, so under the premise that google is not mitm'ed for most people most of the time..."
<raz>
might not work so well when you're in china, i'll admit :)
<raz>
i guess sometime soon someone will roll something interesting based on the bitcoin blockchain model