Re: [SLE] Digitally signed rpms?
The way this would work is as follows: There is some fine, reliable, company staffed by honest people, e.g., SuSE. SuSE would distribute a CA certificate with their CD. That way we are pretty darn sure we don't accept some impersonator's CA certificate. This CA certificate would already be installed into YAST. When rpms are installed, YAST would check to see if they are properly signed and unaltered. Binary RPMs could even be bound to their related source by hashing the source and including the hash in the binary rpm before signing it.
Sounds good, is good. It's actually built into rpm. I can personally acknowledge that Red Hat has made use of this feature since RH 4.0. What I do not understand is why SuSE completely ignores this. I pointed that out / suggested that 6 days ago on the suse-security list, but there was no followup/reply from anyone at all. Instead, SuSE publishes MD5 checksums for their updated rpms. Those checksums are also on the CD of the distribution. Needless to say, due to human error the checksums published do not always match the ones of the actual rpm. As you don't really know which is which, the whole thing kind of turns into a farce. If SuSE signed the rpms before releasing them, the human error would be avoided (unless someone used a wrong signature - something Red Hat has not managed in versions 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0). Volker -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Volker Kuhlmann wrote:
The way this would work is as follows: There is some fine, reliable, company staffed by honest people, e.g., SuSE. SuSE would distribute a CA certificate with their CD. That way we are pretty darn sure we don't accept some impersonator's CA certificate. This CA certificate would already be installed into YAST. When rpms are installed, YAST would check to see if they are properly signed and unaltered. Binary RPMs could even be bound to their related source by hashing the source and including the hash in the binary rpm before signing it.
Sounds good, is good. It's actually built into rpm. I can personally acknowledge that Red Hat has made use of this feature since RH 4.0.
What I do not understand is why SuSE completely ignores this. I pointed that out / suggested that 6 days ago on the suse-security list, but there was no followup/reply from anyone at all.
Instead, SuSE publishes MD5 checksums for their updated rpms. Those checksums are also on the CD of the distribution. Needless to say, due to human error the checksums published do not always match the ones of the actual rpm. As you don't really know which is which, the whole thing kind of turns into a farce.
If SuSE signed the rpms before releasing them, the human error would be avoided (unless someone used a wrong signature - something Red Hat has not managed in versions 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0).
Volker
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Volker, I took a closer look at the SuSE ftp site. Indeed there is a list of MD5 sums. I don't have a clue how to use them. I also don't have very solid assurance they are from a reliable source. If Jolly Roger's pirate site was able to trick me into thinking I was at SuSE's ftp site, they could stick up RPMs with MD5s that match their malicious code. I could hash the downloaded RPMs and compare them to the MD5s and all would look correct. My experience with PKI is that one of the biggest obsticles to implementing it is intellectual. To take the analogy of building security, if a person is charged with the physical security of a building he must not only understand locks, alarms, detection devices, and etc., he must also understand the structural design of buildings almost as well as an archetectural engineer. With computers the challenge is even greater. One must understand the intracies of PKI and SSL, as well as the mechanisims of, in the case of the discussion at hand, YAST and RPMs. Not to mention TLS and ftp over TLS. Add to this complexity the need to make such a security service easy for the consummer to use, and the need to educate the consummer about the importance of such a service. This is not something that is all that easy to implement. In the last 6 or so months I posted something on this list about the importance of PKI. The only response I received was someone asking me 'what is PKI?' I normally don't say RTFM. Well, if anybody reading this is asking themselves "what is PKI?". RTFWP ;-) http://www.opengroup.org/security/l2-pki.htm Steve -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
participants (2)
-
hattons＠cpkwebser5.ncr.disa.mil -
kuhlmav＠elec.canterbury.ac.nz