On Jun 25, 2008, at 5:55 PM, Tim Mooney wrote:

> In regard to: Re: rpm3 package still exist, devzero2000 said (at  
> 10:56pm on...:
>
>> I can sign the document i wrote. I can sign document, written by  
>> other, on
>> which i have control, can update, verify the quality or, almost, i  
>> have
>> trust. If i have to sign document,  which i have paid and not have  
>> control,
>> weel, i am crazy or silly. It is as i have to sign m$ software.  
>> Only for
>> distribute it.
>>
>> So the digital signature became a joke. And i not like this.
>
> I'm not saying you're wrong, but look at it this way:  any time you  
> accept
> a package (whether it's an RPM on Linux or a "setup.exe" on  
> Windows) from
> a vendor and you install it on your system, you're placing a  
> significant
> amount of trust in that vendor.
>
> If you sign a package for distribution via your software distribution
> mechanism (maybe it's yum, maybe it's Red Hat Satellite, maybe it's
> something different), you're not say that you wrote the software  
> and that
> you vouch for the quality of the software: you're saying that you  
> obtained
> the software from the vendor.  You're vouching for its provenance, not
> its quality.
>
> By vouching for its provenance, you can now easily distribute this
> software via your software distribution method to whatever systems  
> should
> have it.  If "whatever systems should have it" == 10,000 systems,  
> isn't
> it better to distribute it easily via your software distribution  
> method
> than to do it the hard way?  Either way, the software gets  
> installed on
> the system.  You're in no worse position by having signed it for
> internal distribution than you are if you hadn't.
>
> There's also no danger that some third party might see your  
> signature on
> an RPM and take that as a sign that you're vouching for the quality of
> the software, because all of the vendors that we're talking about  
> as part
> of this discussion, that are still using rpm 3.0.x, have legal
> restrictions on redistributing the software you've obtained from them.
>

The above is one of the sanest descriptions of the usage of
digital signatures in software distribution I've ever read.

I (being puckishly provocative ;-) would take the analysis one
step further:
     Even the "provenance" semantic you've attached to the
     digital signature verification could/should be abandoned.

All that's really necessary is a strong guarantee of *.rpm package
integrity when distributing OSS software, whether its through RHN  
Satellite
or any other means.

Sure there are "branding" semantics that can be read into the
existence of an "official" vendor signature.

And you are absolutely correct that resigning (with locally known key)
indicates "provenance", not anything else.

But all that is needed for reliable software distribution is an  
"untampered"
integrity guarantee. The algorithm parameters associated with DSA/RSA
signing provide a very strong guarantee of "untampered", and that's all
that is needed for reliable software distribution. Other issues, like  
"provenance",
and/or "branding", can be tied to a package being distributed through  
other
means.

FWIW, I've thought seriously about teaching rpmbuild to automagically
sign every package that is built. What would be ideal (imho) is a zero
knowledge proof that a package is untampered since build.

The algorithm I've been watching for years (it is patented afaik, but  
patents
eventually expire) is Feige-Fiat-Shamir described in section 11.4 of
the "Handbook of Applied Cryptography". A randomly generated pubkey
distributed with the package likely (imho) provides a sufficiently  
strong
guarantee for software distribution, certainly arguably stronger than
no signature at all as is currently commonly practiced.

If anyone has other clueful suggestions for a candidate signing  
algorithm that
could be automatically applied to *.rpm packages, I'm more than  
willing to listen.

But even a randomly generated RSA/DSA key-pair, with pubkey in the
*.rpm package, is perhaps a stronger "untampered" guarantee. than no
signature at all. Sure you can tear apart a *.rpm package  
maliciously, and
reconstruct with malware added and Yet Another randomly generated
pubkey included. Does that really matter? The *.rpm package is still
"untampered" since the malware was included, which is all that is
needed for the distribution pipe.

(aside) Clearly, if you are distributing modified packages with  
included malware,
you should most definitely ensure that cannot happen through other means
than "trust" of a automatically signed *.rpm package. Well, duh!

Note that a randomly generated pubkey certainly does not preclude  
signing
with other algorithms like DSA/RSA, and/or with other attached  
"provenance"
and "branding" semantics attached to the verification of the digital  
signature.

But all that is needed for software distribution is a strong  
guarantee of "untampered".

73 de Jeff