Mailing List Archive

> > developers of open source software OWES nothing to the
> > users.
>
> May I quote that?

feel free but anyway by now your audience is dropping by the minute.

> > but for now: BE GONE ALREADY.
>
> Forget it.

then don't be surprised if you end up speaking to yourself. piece of
mind is but one click away... quite easy to achieve with good filters.

so long

*click*


--
gentoo-security@gentoo.org mailing list

Den,

when you send carbon copies of a private e-mail exchange to
the mailing list out of the sudden, then please make sure
you don't forget to provide the proper context in your
quotes so that the readers know what it is about. Let me
help you with that:

> Den writes:
>
> > Peter Simons wrote:
>
> >> Fixing a vulnerability that threatens your user's
> >> machines without me having to bitch and moan for _days_
> >> would be fair, too, and you don't do it either.
>
> > developers of open source software OWES nothing to the
> > users.
>
> May I quote that?

Because otherwise it would look as if I had said something I
did not.

No need to apologize. Accidents happen.

Peter


--
gentoo-security@gentoo.org mailing list

On Tue, Nov 09, 2004 at 09:05:41PM -0500, Denis Roy wrote:
> > not prompted the beginning of a new initiative in signing the tree
>
> because that was already underway. I very much doubt that it'll speed
> up the progress made on that initiative, because the main limiting
> factor is time. No matter what is said here, it's not going to make
> anybody go out and quit their jobs in order to get tree signing
> implemented quicker.

The problem with phrasing it this way is that it implies there is only
one way to address this issue. It may be true that Gentoo has decided
on only one way to address the issue, but there are other ways to do it.

The current development effort that is underway is not one that can be
implemented overnight, but there is a solution that manages to satisfy
the core needs of this thread that can be implemented overnight.

The requirements are:

* admin access on the main Gentoo server
* a cron job
* a GPG key on the server
* a script to do the heavy lifting

Of those items, only the script can be written by us normal users,
in order to help out in the Open Source way. The people with admin
access to the main Gentoo server do not appear willing to install such
a script, even if someone else writes it. (And I'm sure Peter would
jump at the chance to write it, and practically has already, and I'd
definitely be willing to help.)

I asked this before, and saw no response, so maybe it was missed in the
pile of messages. I'll ask again:

If someone posted a working and self-tested script to this mailing
list, would Gentoo admins be willing to install it, provided it
passed the peer review on this list? (i.e. contained no glaring bugs)

If the answer was yes, this thread would be over.

- Chris


--
gentoo-security@gentoo.org mailing list

Finally, a message I can fully agree with.

As there is a quick and dirty solution to improve the situation -- even
with the understanding that it is not the "best" or "ideal" solution --
I would encourage the gentoo devs to implement it. It really doesn't
seem like rocket science.

I do consider it a significant problem that I cannot accurately verify
that everything in my portage tree came from a trusted source. Agreed,
MOTM attacks are not common. However, it would seem important to have
some sort of "audit trail" to verify that portage is what it's supposed
to be. Not only is this good proactive security, but it might also
prove useful in tracking the source of some security problem.

An interim signing solution, as mentioned already in this list, would
provide at least a mechanism (maybe not a great one, but one
nonetheless) by which a user can verify that the files downloaded to his
gentoo machine are those the developers intended to distribute.

I trust the devs implicitly, but I do not trust, nor can I control, most
of the points between them and me.

I think ultimately the existing plan, to implement full gpg signing of
each file in portage, is definitely the way to go. In the meantime,
while the infrastructure is laid for the superior, longterm proposal,
why not spend an hour to provide an interim, if not ideal, solution?

Devs, what have you to lose by helping us do this? I don't think I
understand the resistance, outside of the emotional reaction triggered
by this thread's initiator.


My $.02.


-C-




Chris Frey wrote:

>On Tue, Nov 09, 2004 at 09:05:41PM -0500, Denis Roy wrote:
>
>
>>>not prompted the beginning of a new initiative in signing the tree
>>>
>>>
>>because that was already underway. I very much doubt that it'll speed
>>up the progress made on that initiative, because the main limiting
>>factor is time. No matter what is said here, it's not going to make
>>anybody go out and quit their jobs in order to get tree signing
>>implemented quicker.
>>
>>
>
>The problem with phrasing it this way is that it implies there is only
>one way to address this issue. It may be true that Gentoo has decided
>on only one way to address the issue, but there are other ways to do it.
>
>The current development effort that is underway is not one that can be
>implemented overnight, but there is a solution that manages to satisfy
>the core needs of this thread that can be implemented overnight.
>
>The requirements are:
>
> * admin access on the main Gentoo server
> * a cron job
> * a GPG key on the server
> * a script to do the heavy lifting
>
>Of those items, only the script can be written by us normal users,
>in order to help out in the Open Source way. The people with admin
>access to the main Gentoo server do not appear willing to install such
>a script, even if someone else writes it. (And I'm sure Peter would
>jump at the chance to write it, and practically has already, and I'd
>definitely be willing to help.)
>
>I asked this before, and saw no response, so maybe it was missed in the
>pile of messages. I'll ask again:
>
> If someone posted a working and self-tested script to this mailing
> list, would Gentoo admins be willing to install it, provided it
> passed the peer review on this list? (i.e. contained no glaring bugs)
>
>If the answer was yes, this thread would be over.
>
>- Chris
>
>
>--
>gentoo-security@gentoo.org mailing list
>
>
>

On Wednesday 10 November 2004 13:35, Chris Frey wrote:
> On Tue, Nov 09, 2004 at 09:05:41PM -0500, Denis Roy wrote:
> > > not prompted the beginning of a new initiative in signing the tree
> >
> > because that was already underway. I very much doubt that it'll speed
> > up the progress made on that initiative, because the main limiting
> > factor is time. No matter what is said here, it's not going to make
> > anybody go out and quit their jobs in order to get tree signing
> > implemented quicker.
>
> The problem with phrasing it this way is that it implies there is only
> one way to address this issue. It may be true that Gentoo has decided
> on only one way to address the issue, but there are other ways to do it.

A large part of the 1.5 years was spent discussing the best solution - threads
not unsimilar to this one. Even to the end, there were still people bringing
up the point that signing doesn't protect against wayward developers. Even
so, after reveiwing all the points a decision was reached because most agreed
that something needed to be done.

> The current development effort that is underway is not one that can be
> implemented overnight, but there is a solution that manages to satisfy
> the core needs of this thread that can be implemented overnight.

I would advise everybody to read through aforementioned discussions in the
archives of gentoo-dev@gentoo.org before persuing this. Something that
appears so simple as this on the surface still has a number of sharp edges.
The infrastructure team would have to do some careful planning and possibly
restructing of job control on the master rsync and cvs servers. The portage
team would need to implement support for verifying the signature is valid.
Whoever else would have to plan and implement distribution of this
all-powerful key.

But it doesn't stop there. Following this would be plan of action for the case
that the all-powerful key is compromised. Then there is also the up to six
month transition period between this solution and the solution that is
currently being implemented. That also requires careful planning and
implementation. So.. adding this simple solution now actually more than
doubles the amount of work that needs to be done down the track.

Regards,
Jason Stubbs

--
gentoo-security@gentoo.org mailing list

On Wednesday 10 November 2004 13:53, Chris Haumesser wrote:
> I trust the devs implicitly, but I do not trust, nor can I control, most
> of the points between them and me.

Why not just take out those points in between?

GENTOO_MIRRORS="http://gentoo.osuosl.org" emerge-webrsync

The mirror should be whatever is listed first in /etc/make.globals, but that
line right there guarantees you that you are getting the latest daily
snapshot of the master rsync mirror from the master distfiles mirror.

Regards,
Jason Stubbs

--
gentoo-security@gentoo.org mailing list

Why not just take out those points in between? GENTOO_MIRRORS=http://gentoo.osuosl.org"]"http://gentoo.osuosl.org" emerge-webrsync

Huh? How does this protect me from a potential MITM attack at my ISP, or on my neighbor's insecure wireless network, which my laptop is currently attached to? A simple traceroute shows sixteen hops between me and gentoo.osuosl.org. That's sixteen potential opportunities for nastiness.

How can I even be sure that I am connecting to gentoo.osuosl.org, when rsync is completely anonymous, with no ssl, no certificate chain, nothing to verify the server's identity other than its rsync banner???

I might care less about about verifying the integrity of my portage tree, if I could at least be more certain of what server I'm connecting to! Having neither assurance is a bit unsettling on a production machine.

The portage team would need to implement support for verifying the signature is valid.

No, they /need/ not, and should not. I would be _thrilled_ to just get a signature with my tree, that I can manually verify by firing up gpg. No portage support is necessary for this interim solution. We all know something better is in the works for portage.

Work on portage should absolutely focus on the better, long-term, previously agreed-upon solution.

If the devs can just sign the tree, I can verify that my portage is what the devs intended me to have, and the devs can continue working on the more polished approach. Work on the best solution moves forward, while those of us with heightened security needs (today!) can be more confident of the integrity of our portage trees.

The infrastructure team would have to do some careful planning and possibly restructing of job control on the master rsync and cvs servers.

While there is surely some work in the area of job control, it has been pointed out already that the proposed solution is not terribly resource intensive. So unless gentoo's infrastructure is already severely stretched to the max (is it? how do i know?), I can't see how this is a huge obstacle. Is there an admin who can weigh in with an informed answer on this? Too much speculation on this point, not enough fact.

Following this would be plan of action for the case that the all-powerful key is compromised.

Key management/security/policy is an issue that will need to be addressed regardless of the mechanics of any signing process, so I don't see how that is a blocker to this proposal. The idea of a master key is equally applicable (and optional) to both the proposal on this list, and the one currently under development.

Then there is also the up to six month transition period between this solution and the solution that is currently being implemented.

If portage support for this temporary hack is not implemented, there is clearly no six month transition period. Just that one day, those of us who have been manually verifying the signature will no longer need to do so.


I must be misunderstanding something, because I still fail to see what is so terribly difficult or impractical about merely generating a signature file. Hell, this could already be done and implemented in the time we've all wasted on this stupid thread.

No one is trying to derail or criticize or block the current implementation. We just want some basic assurances (now, today) that the scripts we're downloading are legitimately from the gentoo devs, who we trust. As it stands, we can verify neither the identity of the rsync server, nor the integrity of the portage tree we're downloading. That is indeed a problem. And it's one we can mitigate now, even if the best solution is still a ways off.


Cheers,


-C-




Jason Stubbs wrote:

On Wednesday 10 November 2004 13:53, Chris Haumesser wrote:

I trust the devs implicitly, but I do not trust, nor can I control, most of the points between them and me.

Why not just take out those points in between? GENTOO_MIRRORS=http://gentoo.osuosl.org"]"http://gentoo.osuosl.org" emerge-webrsync The mirror should be whatever is listed first in /etc/make.globals, but that line right there guarantees you that you are getting the latest daily snapshot of the master rsync mirror from the master distfiles mirror. Regards, Jason Stubbs -- gentoo-security@gentoo.org mailing list

-- gentoo-security@gentoo.org mailing list

Sorry for the html. Here's a more legible version of my last post:

>Why not just take out those points in between?
>
>GENTOO_MIRRORS="http://gentoo.osuosl.org" emerge-webrsync
>
>

Huh? How does this protect me from a potential MITM attack at my ISP, or
on my neighbor's insecure wireless network, which my laptop is currently
attached to? A simple traceroute shows sixteen hops between me and
gentoo.osuosl.org. That's sixteen potential opportunities for nastiness.

How can I even be sure that I am connecting to gentoo.osuosl.org, when
rsync is completely anonymous, with no ssl, no certificate chain,
nothing to verify the server's identity other than its rsync banner???

I might care less about about verifying the integrity of my portage
tree, if I could at least be more certain of what server I'm connecting
to! Having neither assurance is a bit unsettling on a production machine.

>The portage
>team would need to implement support for verifying the signature is valid.
>
No, they /need/ not, and should not. I would be _thrilled_ to just get a
signature with my tree, that I can manually verify by firing up gpg. No
portage support is necessary for this interim solution. We all know
something better is in the works for portage.

Work on portage should absolutely focus on the better, long-term,
previously agreed-upon solution.

If the devs can just sign the tree, I can verify that my portage is what
the devs intended me to have, and the devs can continue working on the
more polished approach. Work on the best solution moves forward, while
those of us with heightened security needs (today!) can be more
confident of the integrity of our portage trees.

>The infrastructure team would have to do some careful planning and possibly
>restructing of job control on the master rsync and cvs servers.
>
While there is surely some work in the area of job control, it has been
pointed out already that the proposed solution is not terribly resource
intensive. So unless gentoo's infrastructure is already severely
stretched to the max (is it? how do i know?), I can't see how this is a
huge obstacle. Is there an admin who can weigh in with an informed
answer on this? Too much speculation on this point, not enough fact.

>Following this would be plan of action for the case
>that the all-powerful key is compromised.
>
Key management/security/policy is an issue that will need to be
addressed regardless of the mechanics of any signing process, so I don't
see how that is a blocker to this proposal. The idea of a master key is
equally applicable (and optional) to both the proposal on this list, and
the one currently under development.

> Then there is also the up to six
>month transition period between this solution and the solution that is
>currently being implemented.
>
If portage support for this temporary hack is not implemented, there is
clearly no six month transition period. Just that one day, those of us
who have been manually verifying the signature will no longer need to do so.


I must be misunderstanding something, because I still fail to see what
is so terribly difficult or impractical about merely generating a
signature file. Hell, this could already be done and implemented in the
time we've all wasted on this stupid thread.

No one is trying to derail or criticize or block the current
implementation. We just want some basic assurances (now, today) that the
scripts we're downloading are legitimately from the gentoo devs, who we
trust. As it stands, we can verify neither the identity of the rsync
server, nor the integrity of the portage tree we're downloading. That is
indeed a problem. And it's one we can mitigate now, even if the best
solution is still a ways off.


Cheers,


-C-

On Tue, 09 Nov 2004 23:04:39 -0800
Chris Haumesser <ch@awry.ws> wrote:

> > Then there is also the up to six
> >month transition period between this solution and the solution that
> >is currently being implemented.
> >
> If portage support for this temporary hack is not implemented, there
> is clearly no six month transition period. Just that one day, those of
> us who have been manually verifying the signature will no longer need
> to do so.

Well, verifying the signature only shows you that noone has modified the
file containing the hashes, you still have to verify that the hashes
match the actual files and I really doubt that you want to do that
manually for ~100000 files.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

Chris Haumesser wrote:

> No, they /need/ not, and should not. I would be _thrilled_ to just
> get a signature with my tree, that I can manually verify by firing up
> gpg. No portage support is necessary for this interim solution. We
> all know something better is in the works for portage.
Mhmm, in that case you will not be able to use portage to get the
portage tree (at least it would not reasonable) because emerge executes
some code from the tree during emerge sync as somebody wrote here two
days ago. If you do not verify the signature + hashes before that, it is
completely senseless to do it all.
And as Marius mentioned you need a solution for checking 100000 hashes
(not just the gpg signature of the file containing the hashes). Somebody
has to write that, even if you don't patch portage.

> While there is surely some work in the area of job control, it has
> been pointed out already that the proposed solution is not terribly
> resource intensive. So unless gentoo's infrastructure is already
> severely stretched to the max (is it? how do i know?), I can't see
> how this is a huge obstacle. Is there an admin who can weigh in with
> an informed answer on this? Too much speculation on this point, not
> enough fact.
I am not a developer and I am basically repeating what people already
mentioned during the last 2 days.
You have to create the hashes and the signature everytime somebody
commits something to tree and you have to take care, that nobody syncs
during that time. So, a simple cronjob (as suggested several times) is
not sufficient. As far as I perceived, some patch to repoman (?) would
be necessary. Certainly those hashes have to be created incrementally to
reduce load and calculation time which also adds some complexicity.

> Key management/security/policy is an issue that will need to be
> addressed regardless of the mechanics of any signing process, so I
> don't see how that is a blocker to this proposal. The idea of a
> master key is equally applicable (and optional) to both the proposal
> on this list, and the one currently under development.
But the PKI and public key policy for Gentoo have not been developed yet
(AFAIK). And that is crucial for even a quick solution as a signature
without defined key policy (and management) is really not worth much.

Of course, all these issues can be solved, but not by the way...

My 2 Eurocents...
Dominik


--
gentoo-security@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 10 Nov 2004, Antoine Martin wrote:

> 2) To all those saying that code should be submitted, we do not have
> access to the rsync servers needed to code 5 lines of bash.

Can't you start your own rsync server just for testing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)

iD8DBQFBkg2/fLPhlaxNQk0RAjuBAJ0WSErpthi5NCEx/AoMsd6e5xaLLgCePJ8v
L+hjOLMHr3ofnwUQvrhtodU=
=8+7G
-----END PGP SIGNATURE-----


--
gentoo-security@gentoo.org mailing list

> > The current development effort that is underway is not one that can be
> > implemented overnight, but there is a solution that manages to satisfy
> > the core needs of this thread that can be implemented overnight.
I second that.

To reply to a few other threads:
1) This is no disrespect to the gentoo devs (kudos here) or the other,
better solution that is in the works. Just a band-aid we would rather
have now.
2) To all those saying that code should be submitted, we do not have
access to the rsync servers needed to code 5 lines of bash.

> I would advise everybody to read through aforementioned discussions in the
> archives of gentoo-dev@gentoo.org before persuing this. Something that
> appears so simple as this on the surface still has a number of sharp edges.
> The infrastructure team would have to do some careful planning and possibly
> restructing of job control on the master rsync and cvs servers. The portage
> team would need to implement support for verifying the signature is valid.
> Whoever else would have to plan and implement distribution of this
> all-powerful key.
I think we all admit it may take some time, but we are talking about the
quick and dirty solution as a stop-gap measure, nothing else.
And if the better solution takes more than 1.5years to roll out, backup
plans are just common sense - not criticism.

> But it doesn't stop there. Following this would be plan of action for the case
> that the all-powerful key is compromised. Then there is also the up to six
> month transition period between this solution and the solution that is
> currently being implemented. That also requires careful planning and
> implementation. So.. adding this simple solution now actually more than
> doubles the amount of work that needs to be done down the track.
Would you care to expand on that?

I is just a cron job and a script, how would that double the amount of
work in the future?!?

Antoine


--
gentoo-security@gentoo.org mailing list

On Wed, Nov 10, 2004 at 12:54:44PM +0000, Antoine Martin wrote:
> I think we all admit it may take some time, but we are talking about the
> quick and dirty solution as a stop-gap measure, nothing else.
> And if the better solution takes more than 1.5years to roll out, backup
> plans are just common sense - not criticism.
>
>
> I is just a cron job and a script, how would that double the amount of
> work in the future?!?

I really don't see how this is greatly improving security.
A cronjob, that is AUTOMATICALLY signing everything it get's
wouldn't make me happy.

Security, is not only signation and cryptography.
When it comes to signation, I have to trust every point
in the process, and I don't trust cronjobs and "in memory"
passphrases, or even worse unprotected private keys.

regards klaus


--
gentoo-security@gentoo.org mailing list

> On Wed, 10 Nov 2004, Antoine Martin wrote:
>
> > 2) To all those saying that code should be submitted, we do not have
> > access to the rsync servers needed to code 5 lines of bash.
>
> Can't you start your own rsync server just for testing?
Sure I can,
but I have been told on this list that the code would have to play nice
with all sorts of other things I do not know/have. So there is little
point in that, is there?


--
gentoo-security@gentoo.org mailing list

epistula illius Klaus Wagner profluit verbis:
> [...]
> Security, is not only signation and cryptography.
> When it comes to signation, I have to trust every point
> in the process, and I don't trust cronjobs and "in memory"
> passphrases, or even worse unprotected private keys.
>
> regards klaus

Full ACK. Some people pointed this out before (more or less specific). But
it's no use discussing the everlasting myth of "partial security" and
"substituting" trust here. The main purpose of those initiating threads
_seems_ to be something completely different.

Greets - Andy

--
Andreas Waschbuesch, GAUniversity KG MA FNZ FK01
eMail: awaschb@gwdg.de

Nobody really knows what happiness is, until they're married.
And then it's too late.

On Wed, 2004-11-10 at 13:55 +0100, Klaus Wagner wrote:
> On Wed, Nov 10, 2004 at 12:54:44PM +0000, Antoine Martin wrote:
> > I think we all admit it may take some time, but we are talking about the
> > quick and dirty solution as a stop-gap measure, nothing else.
> > And if the better solution takes more than 1.5years to roll out, backup
> > plans are just common sense - not criticism.
> >
> >
> > I is just a cron job and a script, how would that double the amount of
> > work in the future?!?
>
> I really don't see how this is greatly improving security.
> A cronjob, that is AUTOMATICALLY signing everything it get's
> wouldn't make me happy.
>
> Security, is not only signation and cryptography.
> When it comes to signation, I have to trust every point
> in the process, and I don't trust cronjobs and "in memory"
> passphrases, or even worse unprotected private keys.
Sure, I agree with you. This is would not solve *all* problems.

But it would solve the problem that this thread started on, which is to
trust all the hops between your box and the gentoo servers. Which is a
greater risk than a compromised gentoo server.


--
gentoo-security@gentoo.org mailing list

On Wed, 10 Nov 2004 13:26:26 +0000
Antoine Martin <antoine@nagafix.co.uk> wrote:

> Sure, I agree with you. This is would not solve *all* problems.
>
> But it would solve the problem that this thread started on, which is to
> trust all the hops between your box and the gentoo servers. Which is a
> greater risk than a compromised gentoo server.

The point, as many people have said, is that the "simple solution" is not as simple as it looks. The changes necessary to allow having up to date hashes of all the files, the file contining the hashes signed, and the checking of the file, and the hashes, *before* any remote info is run, would add significat develpoment time, prolonging the time for the *better* solution. Not to mention the processing would add a lot of overhead.

Like to guess how long it would take to compile a list of hashes for the 100,000+ files in portage on my 450MHz server?

Yes there is a problem, yes there is a fix, the fix is on it's way, be patient.

On Wed, 10 Nov 2004 14:03:07 +0000
Antoine Martin <antoine@nagafix.co.uk> wrote:

> I think someone already tried it on this list, a few minutes IIRC.

real 10m39.694s
user 1m11.500s
sys 2m5.833s

That would make my emerge sync 1/3 longer, and create:

-rw-r--r-- 1 nevyn users 7.6M Nov 10 14:51 portage_md5_sums.txt

That is just to create the hashes, and that 7.6M file would have to be added to the portage tree.

*That* isn't even the point though. The point is the work that would have to be done by the devs on a range of systems, and the increased load that would be put on the servers.

You think it would be worth it to have the "band-aid" in a few weeks and the compleate fix in 6 months? I'd rather wait for the compleate fix in the knowledge that I am getting the best alternative sooner.

Let us agree to disagree, after the dev's have made there choice as is their perogative.

On Wed, 2004-11-10 at 13:31 +0000, Anthony Metcalf wrote:
> On Wed, 10 Nov 2004 13:26:26 +0000
> Antoine Martin <antoine@nagafix.co.uk> wrote:
>
> > Sure, I agree with you. This is would not solve *all* problems.
> >
> > But it would solve the problem that this thread started on, which is to
> > trust all the hops between your box and the gentoo servers. Which is a
> > greater risk than a compromised gentoo server.
>
> The point, as many people have said, is that the "simple solution" is not as simple as it looks. The changes necessary to allow having up to date hashes of all the files, the file contining the hashes signed, and the checking of the file, and the hashes, *before* any remote info is run, would add significat develpoment time, prolonging the time for the *better* solution. Not to mention the processing would add a lot of overhead.
I think this was mentioned before, but the few who would like to check
these signatures would probably not mind having out of date hashes, and
having to resync if they need to emerge that particular package -
assuming it got changed just when they last synced. Or am I missing
something?

> Like to guess how long it would take to compile a list of hashes for the 100,000+ files in portage on my 450MHz server?
I think someone already tried it on this list, a few minutes IIRC.

> Yes there is a problem, yes there is a fix, the fix is on it's way, be patient.
No disrespect, but if it has taken more than 1.5 years already - and I
have not seen any release schedule, why not at least consider a
temporary fix?


--
gentoo-security@gentoo.org mailing list

This *is* dragging on a bit.

Can we all agree on one thing?

That Gentoo devs signing their ebuilds with individual keys would at least
make it possible to develop a framework that could take use of that, whatever
form that framework takes?


Key distribution, and key verification aside, at least signing ebuilds would
help, and couldn't possible hinder?


--

Random russian saying: Working sweat spices your food.

jabber: jcalum@umtstrial.co.uk
pgp: http://gk.umtstrial.co.uk/~calum/keys.php
Linux 2.6.7-hardened-r7 14:02:22 up 52 days, 3:06, 1 user, load average: 2.44,
2.44, 2.12

--
gentoo-security@gentoo.org mailing list