Weekly Edition
Return to the Distributions page
| ||||||||||||||||
Build Service Repositories Get New GPG Keys
You wonder why zypper or YaST do ask you to accept new keys for some repositories atm ? Please read this mail in this case. The repositories on opensuse.org below the http://download.opensuse.org/repositories/ directory get currently new GPG keys which are used to sign the repository meta data and the packages. The reason behind this is to increase the security for you and your system. Repositories inside of this directory are created by the openSUSE build service packagers. Everybody can go to http://build.opensuse.org and get at least an own home:<login> project where you can build and publish packages. But also all other projects have different owners, this means people who have write permissions there. As a consequence of this openess of the build service, users should have the possibility to decide whom to trust and whom not. This is easy possible by adding or not adding/removing repositories. However, rpm and package managers do use gpg keys to support users in this approach. These tools use them to verify that a certain repository and each package does indeed come from a certain person or group. In the past, all build service repositories were signed with the same key. This means that a user was able to allow or disallow repositories, but the the tools did not help or even checked this. This approach was therefore not save against attacks. We use from now on own keys per top-level project. Users can decide to accept certain keys or not. Packagers will get an API interface to manage these keys in near future to some degree. These keys are auto generated by the build service and report to come from KDE OBS Project <KDE@build.opensuse.org> or home:adrianSuSE OBS Project <home:adrianSuSE@build.opensuse.org> for example. In case you are not sure, if you can trust a certain project, you should log into the build service via http://build.opensuse.org and look at the list of persons who are part of this project. (Yes, a system which makes this more transparent for the End User is in our plan). I hope this helps adrian PS: There was a bug, which caused failures when using rpm checking a signature. This will be solved by rebuilding these packages. YaST and zypper are using gpg and had never this problem. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de ------------------------------------------------------- -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-announce+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-announce+help@opensuse.org (Log in to post comments)
Trusted Key Publication Posted Jan 28, 2008 8:24 UTC (Mon) by AnswerGuy (guest, #1256) [Link] I would love to see distribution maintainers (like Novell, Red Hat, Debian and Canonical and most importantly KERNEL.ORG) engage with noted Linux publications (like LWN, Linux Journal, and Linux Magazine) to agree on a system of trusted GPG key publications. This would be one printed page in each regular issue (where applicable) and one page on each of the associated web sites which would have the list of GPG key fingerprints for each of the distributions. Naturally I would encourage management all around to meet (with selected representatives from the security and crypto communities --- perhaps asking Bruce Schneier to advise) and establish the protocols for authorization (how announces key changes in each organization, how are changes in designate communicated, etc) and validation of the keys. If we did that with the main organizational keys of software and perhaps some hardware companies then that can be a distributed verifiable basis for established the root trust. Currently we use rather tenuous trust associated with a cloud of CA (certificate authorities) --- and we are most trusting the public keys embedded in our browsers, which were downloaded from sites or installed via CDs whose identities are largely onconfirmed (and in most cases whose identities are well nigh on impossible for a mere mortal user to confirm except by trusting the same embedded SSL CA certs that we already untrustworthy. (Yes, I know about trusting trust issues --- the first generation of systems using my proposed scheme would, of course, be untrusted and could theoretically already be compromised in a way that could maintain a chain of compromise through any number of generations and wide varieties of contortions and machinations; but it would still be better to start somewhere). Under the scheme I propose normal (albeit savvy) users could cross check a purported key in recent issues of two or three publications (and check to see that such keys are, in fact, signed by a suitable number of publications and other respected organizations within the community --- cross checking *those* signatures against the fingerprints published by their creators). (I particularly like printed magazines for this purpose because such tangibles are easy for people to understand and evaluate and surprisingly difficult to forge in any meaningful way). JimD
|
||||||||||||||||