security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 12:04 PM, Arno Hautala wrote:

> On Mon, Apr 18, 2011 at 11:34, Jeff Johnson <n3npq at mac.com> wrote:
>> 
>> You asked what other systems are in use. I replied. If you
>> don't like what is implemented, all I can say is
>>        Patches cheerfully accepted.
> 
> I asked what systems are in use in order to investigate options for MacPorts.
> I'm pointing out an issue that I see with this example.
> 

And I replied and your objections were both read and noted.

>> What is the connection between a "web server" and "package management"?
>> There are serious differences in the implementations and usage cases
>> and risk factors involved. You cannot just reason that all "content delivery"
>> is the same.
> 
> You mentioned non-repudiable signing as used by RedHat to be similar
> to "self-signed host certs". I assumed this to be an analogy to web
> servers. So I offered a critique of that analogy.
> 

I described a non-repudiable signature scheme in use by RPM, not
by Red Hat, which is in fact more interested in "branding"
as represented by an "official" signing key.

There are no XSS threats in most cases for "package management"
because the delivery is usually from static content on mirrors,
not from some dynamic store. Even if "packages" are delivered from
a "web server" the attack is against the server, not the
sausages delivered by the server. The sausages (in the scheme I described)
WILL continue to have a public key and a signature that can be verified
no matter what other exploits there are. So I'm not sure the analogy
to a "web server" is meaningful or useful to "package management".

>> Not even close to the point if you think more bits in a hash
>> is more "secure".
> 
> It's at least part of the goal (re: larger hash space, lower chance of
> collision).
> 

I do not read your thoughts. Say what you mean as precisely as possible.

>> A trusted 3rd party registrar for pubkeys as well as including the pubkey
>> in signed content (to avoid DoS attacks preventing pubkey retrieval) is
>> the basis for the "trust".
> 
> I fail to see how trust is achieved from using single use key pairs.
> Also, you hadn't previously mention anything about a 3rd party
> registrar. If the single use keys are also signed by that 3rd party,
> you're back to the issue of who to trust.
> 

I'm not responsible for your, or anyone else's, opinion of
how trust is achieved. I have described a mechansim only.
Don't do that if you don't "trust" what is implemented in RPM.

> These are critiques of the system as presented to be in use by RedHat
> and how that might direct MacPorts.
> 

Again, I have _NOT_ been associated with Red Hat for years, and I
described what is implemented in RPM, not what Red Hat does:
	Pay more for increased security.
based on faith is one of you available "trust" choices always.

> Personally, for trusting the build system, I'm leaning towards
> supporting a system that robo-signs packages as they're built.

What do you think I just described if not a system that "rob-signs"
packages as they are built, exactly what Jordan has said.

> It might be nice to track ports back to their submitters with key
> signing, but it's probably more trouble than it's worth right now. And
> there's still the VCS history and Trac.
> 

Binary "package management" (and by inference projects
like MacPorts) cannot be responsible for all possible exploits.
That simply isn't feasible.

> A leaked robo-key can always be revoked and nothing in effective
> security is ever ideal.

And a generated keypair with the private key discarded and
the public key registered with time stamp differs ... how?

> Even PGP key signing could be improved by tracing DNA back to most
> recent common ancestor.
> 

Improved how? Explicitly please, I have little time to
have web-of-trust explained Yet Again. In fact the OpenPGP
model is superior and isn't widely used, X.509 certs (and
other digital signatures like ssh) are more widely used in
the "real world" than PGP.

Not that the mathematics gives a h00t how the big numbers are
represented. Hey lets use "base 37" qaternions for public keys
with i18n encoding in XML, noone will ever figger _THAT_ representation
in the next century, even the qubits don't do proper encoding!

Just in case: That's a math joke.

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/87857794/attachment-0001.bin>