RubyForge project and gem distriubtion

[James Britt]

I seem to recall a mention at some point that if a project on rubyforge
had a gem package, then it would automagically be available through the
rubyforge gem server.

How does this work? I have a project, I've assembled a gem for it, but
I don't know what I need to do in my project to make that gem
available through the gem server.

Does the assembled gem file go in some special dir? Does the gem have
be added as an "officially released" download file?


Thanks,


James

 

[Richard Kilmer]

Release the file like you would any file (in the Files tab). RubyForge
picks them up and puts them in the repo, and they are (within an hour for
now) available for remote download.

-rich

 

[James Britt]

Release the file like you would any file (in the Files tab). RubyForge
picks them up and puts them in the repo, and they are (within an hour for
now) available for remote download.

Excellent! Thanks.


James

 

[David Ross]

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 /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------

Excellent! Thanks.


James

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

 

[Richard Kilmer]

Should we remove your rubyforge account now?

If someone does that, its traced to their project, and their identity. What
stops someone from putting `rm -rf /` in ANY ruby library? Have you read
every line of every ruby library and c extension in ruby to verify that
those commands are not present. Does a packager check every line of C code
in a native extension to make sure that those lines are not present? There
is a point where trust is assumed...the question is at what point. Not
saying that QA is bad, just that autonomy is not bad either...it scales
really well.

-rich

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 /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------

Excellent! Thanks.


James

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

 

[James Britt]

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

 

[Chad Fowler]

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.

This is not a design flaw. It's an add-on feature for RubyForge. It
has nothing to do with design of RubyGems or RubyForge. RubyGems'
no-controlled approach is very reminiscent of, say, the way RAA works.
Or the Web, for that matter. If you want to inspect a gem before you
install it, it's very much like any other packaging system: download
the gem, unpack it, look through it, see that it's OK, install it.
The remote repository is a convenience but not at all a necessity.
For the vast majority, it makes things easier. For the few that
aren't comfortable with it, you have an easy option of not using
auto-installation.

There's nothing stopping someone from putting a QA'd, controlled
repository together with RubyGems. Just not on my priority list.
Anyone's free to do it if they feel it's valuable, though.

Chad

`rm -rf /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------

Excellent! Thanks.


James

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

 

[David Ross]

Heh, I didn't say I was going to do it. I was thinking
what happened with ruby-lang.org being hacked. What
really stops someone from violently attacking more
than just one computer?

Finding thier identity is irrelavent.

For Example:

Joe PeelHacker decides he wants to screw over the ruby
community. So, he gets a handful of http proxies, and
uses a proxy chain to anonymously create a new
project, create files, and create a gem.

Okay, right now he has accomplished pretty much
everything he needs to do to start attacking. He
releases a gem. It gets copied over without being
looked at by a QA team. Ok, fine.


Assuming the person is installing the RubyGem on
*nix(includes MacOSX as well, its Darwin based) via
root, or running it on Microsoft Windows.The gem
contains 3 programs, a script, a nix version script
that creates a user and alerts the attacker via irc,
and there is a windows trojan that the attacker
created that is also a worm. Okay, the trojan is new,
so Antivirus programs will not detect it. AV programs
perform by the database engine of known viruses.
Norton Bloodhound doesn't pick it up either.

Okay, this attacker just screwed over not only one
server, but the whole community of Rubyland.

Is this pretty clear now? This scenario would work
perfectly. There is nothing to stop someone from
attacking. Its an open security problem.


-------------------------------------------
David Ross
Phone: 865.539.3798
Email: (e-mail address removed)
-------------------------------------------

Should we remove your rubyforge account now?

If someone does that, its traced to their project,
and their identity. What
stops someone from putting `rm -rf /` in ANY ruby
library? Have you read
every line of every ruby library and c extension in
ruby to verify that
those commands are not present. Does a packager
check every line of C code
in a native extension to make sure that those lines
are not present? There
is a point where trust is assumed...the question is
at what point. Not
saying that QA is bad, just that autonomy is not bad
either...it scales
really well.

-rich

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 /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------

Richard Kilmer wrote:

Release the file like you would any file (in the
Files tab). RubyForge
picks them up and puts them in the repo, and they
are (within an hour for
now) available for remote download.


Excellent! Thanks.


James

-rich

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

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

 

[Sean O'Dell]

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

 

[David Ross]

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

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

 

[Chad Fowler]

Is this pretty clear now? This scenario would work
perfectly. There is nothing to stop someone from
attacking. Its an open security problem.

Did you read Rich's email before responding?

 

[David Ross]

hmm. Okay, not design flaw, security flaw. I always
seem to use wrong words. Since I keep calling it a
security problem, it shouldn't be called a design
problem.

People who download shouldn't have to be cautious as
to look at the code. It should be up to someone else.
Similar to what debian package QA. --David Ross

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.

This is not a design flaw. It's an add-on feature
for RubyForge. It
has nothing to do with design of RubyGems or
RubyForge. RubyGems'
no-controlled approach is very reminiscent of, say,
the way RAA works.
Or the Web, for that matter. If you want to
inspect a gem before you
install it, it's very much like any other packaging
system: download
the gem, unpack it, look through it, see that it's
OK, install it.
The remote repository is a convenience but not at
all a necessity.
For the vast majority, it makes things easier. For
the few that
aren't comfortable with it, you have an easy option
of not using
auto-installation.

There's nothing stopping someone from putting a
QA'd, controlled
repository together with RubyGems. Just not on my
priority list.
Anyone's free to do it if they feel it's valuable,
though.

Chad

`rm -rf /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------

Richard Kilmer wrote:

Release the file like you would any file (in the
Files tab). RubyForge
picks them up and puts them in the repo, and they
are (within an hour for
now) available for remote download.


Excellent! Thanks.


James

-rich

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

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

 

[David Ross]

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

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

 

[Chad Fowler]

hmm. Okay, not design flaw, security flaw. I always
seem to use wrong words. Since I keep calling it a
security problem, it shouldn't be called a design
problem.

People who download shouldn't have to be cautious as
to look at the code. It should be up to someone else.
Similar to what debian package QA. --David Ross

So, this is the equivalent of having two release streams: the
"normal" one, which the open source community generally follows and
then the special ones like Debian (and now RPA). That makes sense.
That's the way the open source community has done it for years.
Where's the huge security flaw?

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.

This is not a design flaw. It's an add-on feature
for RubyForge. It
has nothing to do with design of RubyGems or
RubyForge. RubyGems'
no-controlled approach is very reminiscent of, say,
the way RAA works.
Or the Web, for that matter. If you want to
inspect a gem before you
install it, it's very much like any other packaging
system: download
the gem, unpack it, look through it, see that it's
OK, install it.
The remote repository is a convenience but not at
all a necessity.
For the vast majority, it makes things easier. For
the few that
aren't comfortable with it, you have an easy option
of not using
auto-installation.

There's nothing stopping someone from putting a
QA'd, controlled
repository together with RubyGems. Just not on my
priority list.
Anyone's free to do it if they feel it's valuable,
though.

Chad

`rm -rf /`

---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
---------------------------




Richard Kilmer wrote:

Release the file like you would any file (in the
Files tab). RubyForge
picks them up and puts them in the repo, and they
are (within an hour for
now) available for remote download.


Excellent! Thanks.


James

-rich








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

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

 

[David Ross]

I did, they wouldn't catch it immediately

Free r00t access to computers, oh boy!

--David Ross

On Fri, 13 Aug 2004 13:31:58 +0900, David Ross



Did you read Rich's email before responding?

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

 

[Richard Kilmer]

OK...so you want to bet I can write malicious Ruby code that a QA person
would not find? I mean really, QA is fine, 'this appears to work well...no
obvious flaws' but it is NOT security. It quite silly to equate the two.

That is, unless the QA team wants to _legally guarantee_ the code they are
approving...now that is quite another matter entirely ;-)

-rich

 

[Jim Weirich]

Joe PeelHacker decides he wants to screw over the ruby
community. So, he gets a handful of http proxies, and
uses a proxy chain to anonymously create a new
project, create files, and create a gem.

Okay, right now he has accomplished pretty much
everything he needs to do to start attacking. He
releases a gem. It gets copied over without being
looked at by a QA team. Ok, fine.

[... attack scenario elided ...]

A question about your scenario that wasn't clear to me: Was the attack
implemented the install code run as the root user? Or was it
implemented in the application code run as a normal user?

Both attack scenarios are available to tarballs available on RubyForge
today, so this is a situation that is real today. It has little to do
with RubyGems.

At least with RubyGems, the former attach scenarios is not available for
only gem code is run during the installation. The attacker gets no
opportunity to run as root.

 

[Mauricio Fernández]

At least with RubyGems, the former attach scenarios is not available for
only gem code is run during the installation. The attacker gets no
opportunity to run as root.

IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.

 

[Mauricio Fernández]

I like what I read about RPA, although I would prefer if it had an aging
process as I described; sort of Debian-ish.

Debian is a major source of inspiration; keep in mind that RPA is in
the initial stages and I'm looking for help to make it grow
In time, a process like the one you describe could be carried out, it
just needs more resources than I have access to at the moment.

 

[Alexander Kellett]

[ummm wish i could get send hooks to change my from addr]

anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.

even this isn't enough. but its closer at least.

root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.

ignoring the problem and hoping people will just
forgot it was ever brought up ain't gonna help.

Alex