RubyForge project and gem distriubtion

ruby-talk
41

That's fine; just don't single RubyGems out as any
more or less
dangerous than anything else you might run as root
(or non-root, for
that matter, if you value your home directory)
without having examined
every line of code. I fully understand that there's
no point saying
this to you; I really just want to chime in with
Dave and others in
the hope of decreasing the chance that anyone will
take your points at
face value.

In my world, everything is insecure. There is a little
guy sitting in the office going "omg omg omg, don't
get h4x0r3d" that is a very paranoid person.
  

idee fixe for you, without technical basis and

idee fixe? Explain please.

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

Security tip: you might want to check the From
header too.

Thats ok. this isn't my main email account. :slight_smile:

At least I can get Ebay fraud emails. I always report
the server.

···

--- "David A. Black" <dblack@wobblini.net> wrote:

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

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

42

> 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

[...]

You don't need to run as root, only if you want to install in a system-wide
repository. Actually, RubyGems runs just great installed by a user, in
their own directories, with no r00t access at all. Its all a question of
what the target user/developer wants to do.

[...]

gem install --install-dir ~/mygems fxruby

That's not too arduous :wink:

Please read http://ruby-talk.com/blade/109119\.
This is an issue you can solve easily.

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

I don't advocate ignoring it. I advocate in NOT giving a false sense of
security.

Where's the false sense of security in

  "anyone with a brain could get malicious code into any package available
   on the planet"

:-))) (sorry, I just find Alex' words too funny in this context :slight_smile:

···

On Fri, Aug 13, 2004 at 09:20:04PM +0900, Richard Kilmer wrote:

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

43

> No motive. I for one don't want to run RubyGems as
> root on a server which has several customers with
> credit card numbers, and then get rooted just because
> someone releases a really bad gem.

I hope you wouldn't "just install" a gem "for fun" on such a box. Such
a box should only contain software that is really needed for it to do
its job and nothing more. And for all the software that you install on
it, it would be wise to take software that has proven itself to be
good, stable and secure. If you can get that software 'signed', from a
trusted source then i think it's reasonable to assume that it's
'secure', if it has been in use for some time and there are no known
security problems with it.

If you just go out and install the 5-minutes-ago-released new gem that
seems to be cool, although you actually haven't tried it on a test box
first for some time, then yeah, you might run into some serious
problems some day...

(afaik, RubyGems won't act on its own and install gems; so even if
someone releases a malicious gem, then you still have to manually
install it before it can be a security threat, right?)

Of course, but you'd be irresponsible to run _any_ open source
installed as root on such a box. I hope that you don't.

Hmm... it might also be irresponsible to run closed source code on it
that might contain backdoors...

All Gems does is remove one step from downloading the library and
saying "ruby install.rb" Gems isn't anything to do with your worries.
The installation of open source software (any software) is inherently
dangerous, and there's ultimately no solution apart from community
vigilance.

I agree with that, gems just makes it easier to get the software.
People who will install gems just like that, would probably also
download the software just like that. Gems doesn't have any security
problems that weren't there already.

I'm surprised by people here claiming to be concerned about security
who have their Ruby installation in /usr/local. If you are concerned
about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
DIRECTORY. That's just common sense (and again is nothing to do with
Gems). Move your Ruby to a directory tree writable by you, and you'll
no longer need to be root to install any Ruby code: Gem, RPA, or random
download.

Yeah, a little bit of common sense would already help a lot. The more
important the box of course, the more security measures you should
take, and the more paranoid you should be.

Ruben

···

At Fri, 13 Aug 2004 21:23:00 +0900, Dave Thomas wrote:

On Aug 13, 2004, at 7:15, David Ross wrote:

44

I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.

With the highest respect, Dave:
...
"How do you get to be a great musician? It helps to know the theory,
and to understand the mechanics of your instrument. It helps to have
talent. But ultimately, greatness comes practicing; applying the
theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and
talent help. But the great athletes spend hours and hours every day,
practicing. "
...
(from: Pragmatic Bookshelf: By Developers, For Developers)

No comments.

···

--
--- vruz

45

[...]

I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and
could have used Gems as the distribution mechanism.

I thought I read somewhere that Gems will be using something similar
to what RPA's RPS packages offer now. Beyond that, though, there are
philosophical differences between the package managers that I don't
think are simply resolvable by reusing the distribution mechanism. I
think that both philosophies are right for certain cases and neither
case is right for other cases.

RPA's concept of cleanly interworking versions as a "release" seems
completely incompatible with RubyGems total version anarchy. At the
same time, the ability to install any version at any time --
accepting the risks involved -- is an advantage of RubyGems at the
moment. I like the ability to say "use release version 5" and get
known versions of libraries that work together nicely (at least in
theory), but also want the ability to say "use release version 5,
but use version 7 of this package".

Neither RubyGems nor RPA solves the problem ideally -- both teams
know my feelings on this :slight_smile:

I do like the distinction that Mauricio has made between RPA and
RubyGems. RubyGems, to be completely useful, has to be The Standard.
Ideally, it will also be incorporated into the core of Ruby --
hopefully eliminating the need for require_gem. (I still don't like
the idea of requiring the gem name, rather than the gem's nominal
require statement -- e.g., diff-lcs rather than diff/lcs.) RPA, on
the other hand, since it works on entire "libraries", doesn't need
to be the standard. Both approaches have merit, and while I hope
that something can be done to integrate both approaches as I don't
*really* want to have to have both on my computer as a user, I don't
have an issue with doing that for the moment.

-austin

···

On Fri, 13 Aug 2004 21:14:25 +0900, Dave Thomas <dave@pragprog.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

46

Yes. I might add that, the more someone tells me
that I should be happy
to let someone else look after my best interests,
the more suspicious I
become of them.

Wow, you must be suspicious of all developers then,
they all look after your best interest. :wink:

Actually, its not really a matter to be suspicious
about. Its just a way to let someone else maintain and
deal with crap. I have seen quite a few very
improperly coded ruby libraries out there. One of the
steps in Batsman's next near phase is to get a QA
team. Examining code, giving rating on how it might be
improperly coded.

A very good example of bad ruby code would be
Raimo(AIM library). No offense, but the college kid
who wrote it can't code worth a damn :). I was shocked
when I read the code, I was even more shocked to know
that the author of raimbo ( aim raim bot using raimo )
just copied the code. (raimo) There were ';'s after
each line, there was some spaghetti code. It was
*horrible*. This is the type of QA besides 'security'
that needs to be handled.

So, I'd like to thank Mr. Ross for reminding me that
people who
download must be cautious, and look at the code. It
cannot be up to
someone else.

I have to disagree, other people seem to do well
looking at other code. Debian's QA team does a good
job of backporting (updated patches etc) the debian
pacakges. So, it can be left up to someone else. This
is the best way, like it or not.

···

James

------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: dross [at] yahoo [dot] com
------------------------------------

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

47

Another good point: changing /usr/local to be writable by the install user would also solve the problem. Of source there would still be the nee for root access if installing suid programs, but...

Cheers

Dave

···

On Aug 13, 2004, at 7:32, ts wrote:

> I'm surprised by people here claiming to be concerned about security
> who have their Ruby installation in /usr/local. If you are concerned
> about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
> DIRECTORY.

How do you know that /usr/local is owned by root ?

48

> idee fixe for you, without technical basis and

idee fixe? Explain please.

I had to look it up myself, neat word: (er, phrase :slight_smile:
http://dictionary.reference.com/wordoftheday/archive/2001/03/01.html

Regards,

Bill

49

Alexander Kellett wrote:

> I don't understand why the rpa folks had to reinvent the packaging
> wheel here: the service they offer is orthogonal to Gems, and could
> have used Gems as the distribution mechanism.

i must say this is erm. confusing me a tad.

why do we use ruby when c is a working alternative?
why choose one distribution over another? why was
rails written in the first place when other frameworks
were already around? why rewrite vim? why discuss
modifications to ruby when it already works?

I think you missed the point about the orimary functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself on top of webrick, rpa
could have built itself on top of rubygems.

rpa-base has many advantages over gems.
stifling development by making requests for
standardization this early in the game is not
gonna do ruby as a whole any good whatsoever.

Same point as above, rpa could provide those advantage as a layer over
rubygems without having to reinvent the distribution layer.

I don't see how having this discussion stifles development. On the contrary,
I think it is very healthy.

Curt

···

On Fri, Aug 13, 2004 at 09:14:25PM +0900, Dave Thomas wrote:

50

I do like the distinction that Mauricio has made
between RPA and
RubyGems. RubyGems, to be completely useful, has to
be The Standard.
Ideally, it will also be incorporated into the core
of Ruby --
hopefully eliminating the need for require_gem. (I
still don't like
the idea of requiring the gem name, rather than the
gem's nominal
require statement -- e.g., diff-lcs rather than
diff/lcs.) RPA, on
the other hand, since it works on entire
"libraries", doesn't need
to be the standard. Both approaches have merit, and
while I hope
that something can be done to integrate both
approaches as I don't
*really* want to have to have both on my computer as
a user, I don't
have an issue with doing that for the moment.

-austin

They are both too early to even be considered to be a
part of Ruby-core. They are both too young, each are
still unstable. Both are constantly making big
changes. There needs to be more time. Maybe a year or
so?

···

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

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

51

So, with gems you can have multiple versions of a single library installed
at the same time...cool, but maybe not commonly used (on the surface). If
you think in terms of "sets" of versioned gems however, you arrive at the
same 'library' idea, but the 'library' can co-exist with another 'library'.
In other words, if you said I want to use library 'stable' and it mods the
load path with all of the listed gems of a specified version you then
'require' just like to did before, and you get a set of gems that have been
QA'd to work together...there ya go. Oh, and with the same 'set' you could
install it (all) or nothing...so you are guaranteed a base to work from (as
far as use goes).

Simple exammple:

Set 1:
jabber4r-0-7-0
ikko-0-1-0

Set 2:
jabber4r-0-8-0
ikko-0-2-0

With gems you could have one script request Set 1 and another script request
Set 2 on the same machine, at the same time, without a problem. Who defines
the 'sets' is another issue. We don't do the 'set' thing right now, but
really, that is a minor addition.

We don't have version anarchy, we have library author autonomy.

-rich

···

On 8/13/04 10:12 AM, "Austin Ziegler" <halostatue@gmail.com> wrote:

RPA's concept of cleanly interworking versions as a "release" seems
completely incompatible with RubyGems total version anarchy. At the
same time, the ability to install any version at any time --
accepting the risks involved -- is an advantage of RubyGems at the
moment. I like the ability to say "use release version 5" and get
known versions of libraries that work together nicely (at least in
theory), but also want the ability to say "use release version 5,
but use version 7 of this package".

52

But musicians typically don't release their practice sessions.

Cheers

Dave

···

On Aug 13, 2004, at 8:40, vruz wrote:

I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.

"How do you get to be a great musician? It helps to know the theory,
and to understand the mechanics of your instrument. It helps to have
talent. But ultimately, greatness comes practicing; applying the
theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and
talent help. But the great athletes spend hours and hours every day,
practicing. "

53

A very good example of bad ruby code would be
Raimo(AIM library). No offense, but the college kid
who wrote it can't code worth a damn :). I was shocked
when I read the code, I was even more shocked to know
that the author of raimbo ( aim raim bot using raimo )
just copied the code. (raimo) There were ';'s after
each line, there was some spaghetti code. It was
*horrible*.

------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: dross [at] yahoo [dot] com
------------------------------------

Mr. Ross,

   Based soley on your treatment of others in this thread of emails
alone, I would intentionally not use anything from any
packaging/delivery system if you happened to be on an approval
committee for it or even somehow involved in the approval system.

   It's sad to see someone like you taint this community with your
inability to be socially graceful. I've always appreciated the fact
that there are many here who willingly and respectfully help others
through the process of growing into who they can become.

   There's always a gentle and non-inflamatory way of getting a point across.

   While you might have a point, and I might even have agreed to it,
your insensitive methods of delivery have left a bad taste in my mouth
that has soured any valid point of view you might have had.

   Maybe you could bring more change about by being a bit... nicer.

   While you might find offense in what I have said I did not mean any.

   Do you happen to have ... non-horrible code that I can look at to
help me in my process of growth?

   I wasn't able to find any entries on the RAA for 'David Ross', and
Rubyforge had you as project admin for rubycc, but I couldn't find any
source code to look at.

Hoping for respectful help,
-Rich

54

*baffled*

total disagreement on this point.
the primary functionality at this
point is rpa-base itself which is
a direct competitor to the gem
format. and the gem format does
*not* provide everything tht
rpa-base currently provides
from what i understand.

i don't think that this early
in the game any standardisation
should be done whatsoever.

mvg,
Alex

···

On Fri, Aug 13, 2004 at 10:38:42PM +0900, Curt Hibbs wrote:

I think you missed the point about the orimary functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself on top of webrick, rpa
could have built itself on top of rubygems.

--
Ummmmm ... Beeeeeeeeerrr.....

   - Simpson, Homer

55

I think you missed the point about the orimary
functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself
on top of webrick, rpa
could have built itself on top of rubygems.

I have to disagree. Batsman has plans for rpa-base and
how they are packaged. RubyGems would not even follow
the way batsman is going. Also, I suppose rpa-base
could temporarily use rubygems packages, but again,
batsman has a bigger, better vision. He has studied
package managers for the past 6 months. He studied the
mistakes they make, how they could be better, and how
they work. Also to bring to attention. Batsman
generously gave RubyGems part of the package scheme
code. Wasn't that nice of him? :slight_smile:

Same point as above, rpa could provide those
advantage as a layer over
rubygems without having to reinvent the distribution
layer.

The fact that batsman wants a QA like team as what
debian has cancels *any* possibility of this
happening.

I don't see how having this discussion stifles
development. On the contrary,
I think it is very healthy.

I have to agree. As I said on the first email. It is a
constructive critique. I suppose I could have stated
the first email better, "I have to comment on how gem
automation on rubyforge is a security hazard" might
have been better. It could have sounded like I might
have been "trolling." I don't know why every time I
say something wether it be IRC, email, real life.. it
always spins off to take hours to finish.

···

Curt

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

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

56

Same point as above, rpa could provide those advantage as a layer over
rubygems without having to reinvent the distribution layer.

Please count the lines of code Mauricio Fernandez has kindly
provided to the Rubygems project.
(if that's possible, not sure who applied the code on behalf of him,
or under which user account he did that)

Add other patches Mauricio Fernandez has provided to the Rubygems
team, but were (quickly) dismissed, and later reimplemented by
the Rubygems team.

Compare this number to the total lines of code in Ruybgems.

The fact that a given person opts to have a low-profile personality
and tries not to offend a team of professional programmers by
patching a great deal of the code they have wrote, is not IMHO
a valid reason why he should submit himself to the guidelines
and work processes of a given project.

To my knowledge, Rubygems is not a blessed standard as it still claims
to be, and it's a rather uncomfortable practice within an open-source
community when people try to impose something that clearly doesn't
fit their purposes, interests, likes or dislikes.

Believe me I love good engineering, and I hate effort duplication.

But I love free speech more.

57

But musicians typically don't release their practice sessions.
Cheers
Dave

I'm lost, who is the apprentice musician here ?
Who should stop releasing their practice sessions ?

Sorry if my comment didn't seem right to you, Dave, I have
always had a great admiration for you and your work, but I don't
quite follow your line of thought here.

In fact, I quoted your Kata text because it seemed to me like it was
inconsistent with the idea you seem to be suggesting here,
(that the rpa guys should drop their project, or be assimilated by
rubygems)

It's only a matter of opinion on who will play the best tunes in the future.
At the moment, everyone is releasing practice sessions.

I would like to ellaborate more on this, I think my primary concern
is freedom of speech more than strictly technical.

I have some work to do now, I'll think more about this later.

I take the opportunity to thank everyone for the proactive approach
you are taking.

best,
                                    vruz

···

--
--- vruz

58

i think the great ones realize there is nothing else but practice sessions.

regards.

-a

···

On Sat, 14 Aug 2004, Dave Thomas wrote:

But musicians typically don't release their practice sessions.

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================

59

   Based soley on your treatment of others in this
thread of emails
alone, I would intentionally not use anything from
any
packaging/delivery system if you happened to be on
an approval
committee for it or even somehow involved in the
approval system.

I happen to be right on many points, it would be a
great loss for you and others not to use rpa just
because I recommended ideas on what past package
mangers failed in the past, how they could have been
better, and help him with improving existing user to
rpa experience.

   It's sad to see someone like you taint this
community with your
inability to be socially graceful. I've always
appreciated the fact
that there are many here who willingly and
respectfully help others
through the process of growing into who they can
become.

I am aware of my socializing problem :confused: I am not nice
to people over the net for some reason, however I am
nice in person. You are right I could be nicer in my
amils, I could say "horrible" in nicer words. I think
I answered that previous email without thinking how
awful I was calling the raimo and raimbo code.

   There's always a gentle and non-inflamatory way
of getting a point across.

Yes there is I know :slight_smile:

   While you might have a point, and I might even
have agreed to it,
your insensitive methods of delivery have left a bad
taste in my mouth
that has soured any valid point of view you might
have had.

I wouldn't say ideas get soured. More like its more
difficult for people to believe me like in.. the boy
who cried wolf?

   Maybe you could bring more change about by being
a bit... nicer.

I know, I have had past problems with the way I talk
to people.

   While you might find offense in what I have said
I did not mean any.

   Do you happen to have ... non-horrible code that
I can look at to
help me in my process of growth?

errr, like?

   I wasn't able to find any entries on the RAA for
'David Ross', and
Rubyforge had you as project admin for rubycc, but I
couldn't find any
source code to look at.

I really need to change the project name :slight_smile: I have
been reading in to using a compiler. TenDRA has many
nice points. I am sure it could be less difficult to
straight compile code.

···

Hoping for respectful help,
-Rich

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

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

60

> Same point as above, rpa could provide those advantage as a layer over
> rubygems without having to reinvent the distribution layer.

Please count the lines of code Mauricio Fernandez has kindly
provided to the Rubygems project.
(if that's possible, not sure who applied the code on behalf of him,
or under which user account he did that)

I was going to make this point. It's kind of ridiculous to go
counting lines, but Mauricio provided a (not-yet-released) patch to
change the gem format to be tar/gz. That was indeed very helpful and
significant in size.

Add other patches Mauricio Fernandez has provided to the Rubygems
team, but were (quickly) dismissed, and later reimplemented by
the Rubygems team.

I think you're exaggerating here. I know of one patch that was the
subject of literally weeks of debate. What got implemented was based
on Mauricio's proposal but the functionality didn't match what we were
after exactly, so it was implemented from scratch.

Compare this number to the total lines of code in Ruybgems.

We welcome more. As I said, the code we've gotten from rpa-base is
great. We've also had a ton of contributions from many other members
of the community that have vastly improved the RubyGems code and
functionality.

The fact that a given person opts to have a low-profile personality
and tries not to offend a team of professional programmers by
patching a great deal of the code they have wrote, is not IMHO
a valid reason why he should submit himself to the guidelines
and work processes of a given project.

None of us would be offended by patches. A lot of the code in
RubyGems now has been completely refactored/replaced by "new" people
since it was originally created at RubyConf. This is the way open
source works. It's good.

This is not to say that we're always going to agree with every patch
that anyone sends in. It's fairly democratic. If you have an opinion
about something that should change in RubyGems, join the list and
bring it up. We're closing in on feature completion for 1.0, so it's
probably a good time.

To my knowledge, Rubygems is not a blessed standard as it still claims
to be, and it's a rather uncomfortable practice within an open-source
community when people try to impose something that clearly doesn't
fit their purposes, interests, likes or dislikes.

RubyGems was created to fill a huge hole in the community: a
"standard" way to package, publish, discover, install, uninstall, and
manage Ruby libraries. The lack thereof has been a common complaint
since I started using Ruby years ago (and probably before then). A
group of us at last year's RubyConf decided enough was enough and we
were going to do something about it.

As for the use of the word "standard", this is the project's goal.
Whether it be defacto or blessed, the Ruby community (particularly new
users) needs a "standard" way to find and install libraries. That
doesn't mean there can't be other ways. It also doesn't mean the
standard can't change. Redhat users can use rpm/yum, which comes on
with their OS, or they can switch to apt-get/dpkg. If *one* of these
packaging systems doesn't become at least a defacto standard, it
wasn't worth our effort.

Believe me I love good engineering, and I hate effort duplication.

But I love free speech more.

Me too. I don't think anyone's trying to suppress it here.

It would be interesting for Mauricio to chime in here. Whenever I
speak to him about RPA, he affirms that RPA and RubyGems are not meant
to compete. Most of the posts in this thread are about competition.
I feel like there is room for both. RubyGems is meant to be an
augmentation of RAA, with a great deal of freedom. RPA is a
replacement for RAA, with a stringent QA and release process. Not
only is there room for both, but I think they can feed each other
nicely (in code sharing, process improvement, and overall quality
improvement).

Chad

···

On Fri, 13 Aug 2004 23:00:25 +0900, vruz <horacio.lopez@gmail.com> wrote: