[Rubygems-developers] RubyForge Security/Release question

Chad Fowler chad at chadfowler.com
Mon Mar 15 11:33:07 EST 2004

On Mon, 15 Mar 2004, Richard Kilmer wrote:

# All,
# I have a script that can run that will check all the files released on 
# RubyForge (gForge) and when it finds a .gem file it is copied into the 
# gems repository.  The problem is this.  Any project can release a file 
# with any gem name.  So, if I wanted to break the Rake project I could 
# (under Jabber4r) release a file/gem named: rake-0.2.1.gem which would 
# then be copied over the existing rake-0.2.1.gem in the global repo.  Of 
# course, we would know who released that file (project/user) and could 
# hammer them, but that is after the fact.  Anyone have an idea on how we 
# could solve this?  Limiting the person who could release a gem of some 
# known name?

One idea would be to have the script collect a list of new gem releases 
and have it alert an approver.  The approver could somehow flag that it is 
OK or not OK by reviewing it.  If we could get it to remember which ones 
were OK, it could automatically let them through next time.  It would be a 
rubyforge project -> gem name mapping.  Now that I've typed this, it looks 
a lot like your paragraph below, only not using email and not tied to 
individuals.  My thought is that if it was ever ok to distribute the 
rubyjdwp gem from the rubyjdwp project, it should *always* be OK.  Of 
course, that examples brings up the obvious point that any gem that 
directly matches the project's name could just be passed through.

We could also experiment with trust.  How likely is it that someone is 
going to break this rule and clobber another gem?  We could just let it 
run as is and see if it breaks (perhaps reviewing the activity for a 


More information about the Rubygems-developers mailing list