From: David Ross <drossruby@...>
Date: 2004-08-13T13:40:31+09:00
Subject: Re: RubyForge project and gem distriubtion

Batsman said it was in the plans after a 0.3 release.
Not sure what he is going to do about that. He
currently needs people to help. --David Ross

--- Sean O'Dell <sean@celsoft.com> wrote:

> On Thursday 12 August 2004 21:09, James Britt 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.
> 
> What's the difference between relying on a
> third-party designated to look out 
> for security flaws and simply crossing your fingers
> hoping the author hasn't 
> gone insane?  To me, the difference is vast.
> 
> A security process is definitely needed.
> 
> Doing it sort of like Debian does would work. 
> Maintainers check over packages 
> for obvious problems: malicious code, dependencies,
> etc.  If a package passes 
> a basic check, they put it into an "unstable"
> repository.  After a couple 
> weeks, if no ugly reports come in, move it to
> "testing."  After a much longer 
> period of time and after review, move it into
> "stable."  Most people should 
> use "stable."  People wanting to get very up-to-date
> packages with only 
> slight risk can use the "testing" repository. 
> People who are really trusting 
> or just like living on the bleeding edge can use
> "unstable" packages.  Maybe 
> there can be a fourth type for packages that authors
> upload but which haven't 
> been checked yet.  Call it the "volatile."
> 
> RubyGems would be classified as "volatile"
> currently.
> 
> I like what I read about RPA, although I would
> prefer if it had an aging 
> process as I described; sort of Debian-ish.
> 
> 	Sean O'Dell
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail