Mailing List Archive

Bart wrote:
> *snip
>
> In the end, computers are a tool to make things you want to do work as
> simply as they can. You'll notice most people don't do what's technically
> possible, but what's *simple*. Laziness, Impatience, Hubris, anyone?:)
>
> I agree that this should be a supported client feature - but it isn't.
> Whatever the reason is, it's not going to be resolved, for now it
> clashes with people's intuition, and in many cases will probably make
> people work at something that could be automatic.
>
> *snip

For reference: http://www.faqs.org/rfcs/rfc2369.html

I agree. Let's screw trying to design and use standards. Every client
should pick and choose how to implement their features so that we can
patchwork all our solutions onto the back-end servers.

Sometimes it's best to just make things work, but you have to realize
that there is also a trade-off to doing this. Somewhere and somehow all
these different methods have to converge to get anything done.

It's hard work to implement all these features, but if the effort isn't
made then why should the standards be written at all. We could just ask
Microsoft what they intend to implement and then try to reverse engineer
it. That would be the path of least resistance towards technology uptake.

Andrew

--
gentoo-security@gentoo.org mailing list

On Tue, 09 Nov 2004 00:01:06 -0500, Andrew Joyce <joyce@webcreations.ca> wrote:
> Bart wrote:
> > *snip
> >
> > In the end, computers are a tool to make things you want to do work as
> > simply as they can. You'll notice most people don't do what's technically
> > possible, but what's *simple*. Laziness, Impatience, Hubris, anyone?:)
> >
> > I agree that this should be a supported client feature - but it isn't.
> > Whatever the reason is, it's not going to be resolved, for now it
> > clashes with people's intuition, and in many cases will probably make
> > people work at something that could be automatic.
> >
> > *snip
>
> For reference: http://www.faqs.org/rfcs/rfc2369.html
>
> I agree. Let's screw trying to design and use standards. Every client
> should pick and choose how to implement their features so that we can
> patchwork all our solutions onto the back-end servers.

I know, I know. I pretty much agree, even. I don't really like that email's so
old that's happening anyow. But in this particular case hardly destroys
convention - it arguably adheres to it in this case. And since client support
is -not- going to happen, adding a reply-to is the a hack of least resistance
solution. What exactly is so evil about it anyway?

--Bart

--
gentoo-security@gentoo.org mailing list

On 08 Nov 2004 23:06:26 +0100
Peter Simons <simons@cryp.to> wrote:

<snip>

One point you havn't replied to Peter, that was mentioned towards the begining of the discussion. How do you handle RSYNC_EXCLUDE?

Some people, I wouldn't like to guess how many, not me, do use this feature. You solution would remove this feature from portage, or at least exclude the people who use this feature.

Do you have any comments on that?

Anthony Metcalf writes:

> How do you handle RSYNC_EXCLUDE?

| From: Peter Simons <simons@cryp.to>
| Subject: How to authenticate the portage tree
| Date: 08 Nov 2004 03:41:22 +0100
| Message-ID: <87acttqcz1.fsf_-_@peti.cryp.to>
|
| (1) Run "find /usr/portage -type f | xargs sha1sum -b" on
| the Gentoo main system.
|
| [...]
|
| (5) Missing files in the tree are okay (rsync_excludes),
| files in the tree which do not have a hash are not okay.

Peter


--
gentoo-security@gentoo.org mailing list

On 09 Nov 2004 11:52:30 +0100
Peter Simons <simons@cryp.to> wrote:

So you have a signed list of hashes, of every file in the tree, not a signed hash of the tree? Makes more sense now.

I am not seeing the difference between that though and the signed hashes that are already implemented. The signing needs to work it's way through the system, and the manifest should cover all files to do with the package, i.e. eclasses etc would have their own manifests that get signed.

I do like the idea of a Master Gentoo Key to sign the dev keys.

Anthony Metcalf writes:

> I am not seeing the difference between that though and
> the signed hashes that are already implemented.

You are right, technically, there isn't a difference really.
The only difference is that a signed list of hashes is very
easy to generate, it is very easy to verify, and it needs
only one GPG to do it. The solution Gentoo is aiming for in
the long run, however, is difficult to create, difficult to
verify (without using the Gentoo tools, which you can't use
before you have verified them -- bootstrapping!), and it
will use several dozen GPG keys. So the only difference is
in the complexity.

My proposal is purely aimed at solving a security problem
_right now_, the real solution aims to do much more.

Peter


--
gentoo-security@gentoo.org mailing list

On Monday 08 November 2004 15:00, Hans-Werner Hilse wrote:
> Err... I think this description alone should do it, no need to waste
> your time writing the n-th description of how to set up a transparent
> proxy, setting up BIND and so on... You could write an ebuild
> "hacked-up-rsync-mirror" which does this all, so that all of us
> can do some testing :-)

I know how to do it, I and the other managers know it is an issue, it IS
NOT BEING IGNORED, but it is a manageable risk. In truth, the rsync
mirrors are fairly secure, and if you can't trust your local nameserver
you have bigger issues anyway.

>
> But i doubt that you really manage to hack up my BIND, place a
> transparent proxy in my connection to the net or convince me to use
> your fake mirror. But go on, play... Don't complain here if you're the
> one being laughed at on that mentioned mailing list...

DNS poisoning can be done, and we're working at signing, but people should
accept that changing things big in gentoo is not all that easy.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Monday 08 November 2004 17:14, Thierry Carrez wrote:
> Last, your simple solution means work for the infrastructure team (to
> change the rsync replication process, provide for CPU time to perform
> the digest etc... And the portage team (testing and releasing extra
> functionality controlled by a FEATURE most people won't activate
> because it slows down the emerge sync process). Rephrasing your
> proposal as :
>
> (1) infrastructure scripts to generate signed digest
> (2) portage patches including the FEATURE of glocal verification
> (3) hard data showing the performance hit server-side and client-side
>
> would certainly help us. It's not your job to do an implementation
> proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a
> community distribution. The "Gentoo team" cannot do everything, it
> needs user support. And yes, even posting a small script helps.

You're even forgetting number (4), a single master key is extremely
sensitive to compromise. The biggest risk (that of the master sync server
being compromised) is not being addressed, and your proposal does not
handle the reliable revocation of such a key. And don't forget that the
master key must be passphraseless as signing needs to happen very often.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net