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