At 12:39 PM 1/7/2002 +0900, Rich Kilmer wrote:
> > From: Dan Sugalski [mailto:dan / sidhe.org]
> > At 11:48 AM 1/7/2002 +0900, Rich Kilmer wrote:
> > >Right and the way to address this is to have a public/private
> > encryption key
> > >pair that signs the stored RubyGem/code a la Java Jar signing.
> >
> > I'm not entirely sure that this would be sufficient.
> >
> > No, that's not true. I'm entirely sure it's not sufficient. I can
> > think of
> > many, many ways to crock this. You're counting on the remote keyserver
>
>I did not say anything about a remote keyserver.  I said to have a Gem(Jar)
>cryptographically signed through the process of generating a public/private
>key pair (as a library developer) and then generating a SHA hash of the Gem
>and encrypting the SHA with the private key.  You then upload the Gem with
>the SHA/public key as a bundle to validate that it was in fact not changed
>and from the public keys owner.

That does the end-user no good, though. One of the ways to attack this sort 
of setup is to co-opt things such that the user never contacts your host. 
Another is to steal the key either from your system or from the developer 
and to upload a properly signed kit that's dangerous.

>   Now, the method by which I download the
>public keys of developers I "trust" is definately an issue but there are
>emerging systems that are being developed to [help] solve this problem in a
>distributed (rather than centralized) fashion that fall under the name
>"reputation networks".

While there might ultimately be some way to do this, as the network stands 
now the methods are insufficient. Unverified DNS is a huge danger here.

> > being trustworthy (they aren't), DNS being trustworthy (it
> > isn't), that the
> > signing entity is trustworthy (they aren't), and that the source you're
> > fetching is safe to use sight unseen (it isn't).
> >
> > Someone could poison your DNS cache. The remote repository can be
> > compromised.   The keyserver can be compromised. A proxy in the middle of
> > the transaction can be compromised or poisoned. The person providing the
> > code can be less trustworthy than you think they are.
> >
> > Yeah, these are all potential issues when installing any chunk of
> > code from
> > the net, but at least with a manual install you have a chance to check
> > things out even if you choose not to. With automagic loading, you
> > take all
>
>So, for every file you download, source or binary do you check it line for
>line to verify that it does nothing wrong and has not been compromised?

On production machines I manage? Generally yes, I do. It does limit the 
number of kits that get installed. If I've reason to believe that the 
remote host hasn't been compromised and

>Security is based more on perception than reality.

Nope, that turns out not to be the case. Security's based on trust and 
trustworthiness. Anything outside reasonable physical control needs to be 
held to a higher level of trust, and there's a lot in the loop that's 
inherently untrustworthy.

>But hey, if we want to go secure how about this:
>
>Start a central site/group to issue (physical) hardware cryptographic tokens
>(for a fee $$) like the Dallas Semiconductor iButton
>(http://www.ibutton.com/ibuttons/java.html) and have those hardware tokens
>sign the Gems.  That way each would contain a x.509 certificate that was
>signed by the central (known) autority (public key).  So, unless the
>physical device was stolen (and the PIN known to the person who stole it) it
>could not be used to sign code.

Nope, not secure. Yes, the central server could have reasonable guarantees 
that the archives it has came from who it's said to come from.

Also, for this to work the code potentially needs to be downloaded every 
time it's used. (Yes, there are cache options here, but you'd want 
per-user, or potentially per-process caches) That is a much larger window 
of vulnerability--if an attacker knew you did this, it'd be reasonably 
simple to watch and intercept attempts. One-shot installs have a much 
smaller window.

I'm not saying don't do this. What I am saying is that there are a number 
of potential vulnerabilities that you can't close, and a few you introduce. 
It's something that needs to be considered very carefully before 
implementing, and a feature that probably ought to be off by default.

> > the potential checks out of the process. (FWIW, I considered this and
> > discarded it for parrot. It's the sort of thing I'd not allow to be
> > installed on a system I administered)
> >
> > > > -----Original Message-----
> > > > From: Dan Sugalski [mailto:dan / sidhe.org]
> > > > Sent: Sunday, January 06, 2002 9:38 PM
> > > > To: ruby-talk ML
> > > > Subject: [ruby-talk:30401] Re: snippet exchange (was: Re: Re:
> > chomp for
> > > > arrays?)
> > > >
> > > >
> > > > At 06:31 AM 1/7/2002 +0900, Mark Hahn wrote:
> > > >
> > > > >A daydream of mine is a "super-require" that if the file was not
> > > > found, the
> > > > >loader would go to a central place on the web and load it
> > (sort of like
> > > > >marimba).  I don't tend to use other people's modules just
> > > > because I'm too
> > > > >lazy to find and install them.
> > > >
> > > > That's a rather dangerous thing to implement. There are an
> > awful lot of
> > > > security issues there...


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan / sidhe.org                         have teddy bears and even
                                      teddy bears get drunk