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
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
On 8/12/04 11:19 PM, "James Britt" <jamesUNDERBARb@neurogami.com> wrote:
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 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
Richard, aside of all that RubyGems security/design flaws flame, I want to thank you and Tom
for that feature. I'm releasing a third Gem via RubyForge, and it's really a time-saving thingy.
Thanks guys, great job.
On Friday 13 August 2004 11:26, 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.
--
sdmitry -=- Dmitry V. Sabanin
MuraveyLabs.
Spam Here -> postmaster@sco.com
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
---------------------------
--- James Britt <jamesUNDERBARb@neurogami.com> wrote:
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
Richard, aside of all that RubyGems security/design
flaws flame, I want to thank you and Tom
for that feature. I'm releasing a third Gem via
RubyForge, and it's really a time-saving thingy.
Thanks guys, great job.--
sdmitry -=- Dmitry V. Sabanin
MuraveyLabs.
Spam Here -> postmaster@sco.com
Flame? no critique, you don't care about your
security. I do. Theres a difference. Easiness over
security is a bad design. Someone is going to end up
making an example. I just hope nothing happens as bad
as ruby-lang.org crack attack.
----------------------------------
-- 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
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
On 8/12/04 11:50 PM, "David Ross" <drossruby@yahoo.com> 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 /`
---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
------------------------------ James Britt <jamesUNDERBARb@neurogami.com> wrote:
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
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.
James
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
On Fri, 13 Aug 2004 12:50:50 +0900, David Ross <drossruby@yahoo.com> wrote:
`rm -rf /`
---------------------------
David Ross
Phone: 865.539.3798
Email: drossruby [at] yahoo.com
------------------------------ James Britt <jamesUNDERBARb@neurogami.com> wrote:
> 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
Oh, sorry.. I do care. But the fact that I care means that I prefer to check
the code I use by myself. AFAIK, RubyGems is not auto-updating packages
from net without my control, so I always have a choice to install package or not.
<flame>
P.S. I'm not going to discuss this, this thread reminds me an old argument of
proprietary software fans that's always used against open source.
If you think that RubyGems, RPA or Ruby offends security of your server,
just rm -Rf it.
Anyway, the most secure server is the one without network interface and even so,
someone can throw it out of the window.
</flame>
Let's stop this thread. I've mailed Rich to say thankyou and you came here with
same things that you already said zillion times before.
On Sunday 15 August 2004 14:39, David Ross wrote:
> Richard, aside of all that RubyGems security/design
> flaws flame, I want to thank you and Tom
> for that feature. I'm releasing a third Gem via
> RubyForge, and it's really a time-saving thingy.
> Thanks guys, great job.
>
> --
> sdmitry -=- Dmitry V. Sabanin
> MuraveyLabs.
> Spam Here -> postmaster@sco.comFlame? no critique, you don't care about your
security. I do. Theres a difference. Easiness over
security is a bad design. Someone is going to end up
making an example. I just hope nothing happens as bad
as ruby-lang.org crack attack.
--
sdmitry -=- Dmitry V. Sabanin
MuraveyLabs.
Spam Here -> postmaster@sco.com
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: drossruby@ruby-lang.org
-------------------------------------------
--- Richard Kilmer <rich@infoether.com> wrote:
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
On 8/12/04 11:50 PM, "David Ross" > <drossruby@yahoo.com> 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 /`
>
> ---------------------------
> David Ross
> Phone: 865.539.3798
> Email: drossruby [at] yahoo.com
> ---------------------------
>
> --- James Britt <jamesUNDERBARb@neurogami.com>
wrote:
>
>> 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
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
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.
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
--- James Britt <jamesUNDERBARb@neurogami.com> 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.James
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
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
--- Chad Fowler <chadfowler@gmail.com> wrote:
On Fri, 13 Aug 2004 12:50:50 +0900, David Ross > <drossruby@yahoo.com> 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.
>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
> ---------------------------
>
>
>
> --- James Britt <jamesUNDERBARb@neurogami.com>
wrote:
>
> > 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
<BIGSNIP/>
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?
On Fri, 13 Aug 2004 13:31:58 +0900, David Ross <drossruby@yahoo.com> wrote:
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
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?
On Fri, 13 Aug 2004 13:37:45 +0900, David Ross <drossruby@yahoo.com> wrote:
--- Chad Fowler <chadfowler@gmail.com> wrote:
> On Fri, 13 Aug 2004 12:50:50 +0900, David Ross > > <drossruby@yahoo.com> 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.
> >
>
> 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
> > ---------------------------
> >
> >
> >
> > --- James Britt <jamesUNDERBARb@neurogami.com>
> wrote:
> >
> > > 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
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
On 8/13/04 12:31 AM, "David Ross" <drossruby@yahoo.com> wrote:
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.
David Ross wrote:
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.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
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.
On Fri, Aug 13, 2004 at 01:33:44PM +0900, Sean O'Dell wrote:
I like what I read about RPA, although I would prefer if it had an aging
process as I described; sort of Debian-ish.
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com