Well there is an answer of having a QA team.

As far as the "what if the central server is hacked",
thats why you have a local server, and a central
server where people can connect to. That way the
server can perform security check for changes. --David
Ross

--- James Britt <jamesUNDERBARb / neurogami.com> wrote:

> David Ross wrote:
> 
> > Heres food for thought..
> > 
> > What stops someone who has a registered project on
> > RubyForge to abuse Gems? A constructive criticism
> in
> > major design flaw. This is why a central
> repository
> > where there is a QA team is good. They can look at
> > code.
> > 
> > `rm -rf /` :)
> > 
> 
> Possible, perhaps.  Maybe in unit test code.  I
> believe that the code 
> you are installing, though, is not what is executed
> by the installation 
> process.
> 
> But that was why I had wondered, here on ruby-talk a
> little while ago, 
> if there might be a way to have a potential
> installation screened by 
> some sort of "sanity check" code, something that
> checks for possibly 
> troublesome code.
> 
> Any code you install, however you do it, might have
> "issues."  This is 
> not specific to gems.  I believe that this is bigger
> issue with 
> home-grown install.rb scripts; using gems should
> make things less risky, 
> as the mere installation shouldn't cause damage.
> 
> Presumably, you don't install something unless you
> trust the source.
> 
> How would one know that some central repository
> hadn't been hacked?
> 
> Either way, you need to pay attention and not assume
> that someone else 
> is looking out for your best interests.  Might be
> better not to fall 
> into the habit of thinking that code has already
> been vetted.
> 
> I don't see this as a major design flaw.  I tend to
> think that reliance 
> on a third-party to always do the right thing is a
> design flaw.
> 
> 
> James
> 
> 
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail