Feature changed by: Stakanov Schufter (stakanov) Feature #312047, revision 12 Title: make repo keys available on project's web site via SSL Buildservice: Unconfirmed Priority Requester: Desirable Requested by: John McInnes (jamjamjamjam) Partner organization: openSUSE.org Description: I was thinking of a way to get repo keys to users in a secure fashion, so they can have some measure of trust, instead of just blindly accepting/importing new keys when installing software. Personally, before accepting a key, I will usually try to google it by ID or fingerprint, search various gpg key servers, ask on a mailing list or newsgroup for 3rd party verification, etc... its a pain in the ***. So I see that the buildservice provides a https interface to project pages. It would be a nice feature to provide the project repo keys there. At least show ID and fingerprint. Discussion: #1: Narayansamy S (vazhavandan) (2011-11-15 12:33:42) we need this for atleast comunity repos #2: tosiara tosiara (tosiara) (2011-11-20 16:33:47) currently without openSUSE public key it's not possible to verify distribution ISO. it's better to have official source than searching for the key on third-party servers #3: Carlo Chiavatore (stakanov) (2011-11-20 17:16:11) Since years I am trying to convince O.P.s coming from the windows world to adopt a safe behavior during program install, to use software only from trusted sources and to use Gpg encryption in their email exchange. And then, every time the same situation, users are instructed to "just ignore and click away" the fingerprint info of the keys of the repos. This is really counterproductive and is mining the heard of a work of educating users for a better and safer behavior. Please make this available. It will highlight the competitive advantage of the repo system and of openSUSE as a security aware and oriented distribution. Thank you. #4: Carlo Chiavatore (stakanov) (2011-11-20 17:16:55) Since years I am trying to convince O.P.s coming from the windows world to adopt a safe behavior during program install, to use software only from trusted sources and to use Gpg encryption in their email exchange. And then, every time the same situation, users are instructed to "just ignore and click away" the fingerprint info of the keys of the repos. This is really counterproductive and is mining the heart of a work of educating users for a better and safer behavior. Please make this available. It will highlight the competitive advantage of the repo system and of openSUSE as a security aware and oriented distribution. Thank you. #5: Ned Ulbricht (ned_ulbricht) (2012-02-11 11:44:55) The security properties of the HTTPS PKI infrastructure are less than desirable. For the latest example, see Mozilla 724929 - Remove Trustwave Certificate(s) from trusted root certificates https://bugzilla.mozilla.org/show_bug.cgi?id=724929 (https://bugzilla.mozilla.org/show_bug.cgi?id=724929) In general, though, I do agree that openSUSE should distribute repo keys to users with as much assurance as reasonably practicable. + #6: Stakanov Schufter (stakanov) (2012-02-18 09:47:20) (reply to #5) + Correct, there are the optimists of CAcert that think they can overcome + this (see FOSEM "trust the root of evil?"), but the case you cited is + absolutely eloquent. That leaves us with the problem of where to create + a register of repo keys and I think that an https page, is better then + the current situation (that is: nothing). IMO one ideal means is + printed media. While books are too rare and need too long to come out, + promotional DVDs could bear inside the cover the current repo keys for + reference. This would come not really at a big additional cost AFAIK + (but of course I can be wrong). It could also be an asset to convince + journals (paper edition) to reserve a footnote reporting the + fingerprints when i.e. giving an article on a new release. As this + would be also an educational effect, they may be willing to do so. At + FOSDEM and other presences of openSUSE a flier with official set of + ID/fingerprints could be offered. But I am afraid about the cost factor + involved. For all these reasons (especially cost) HTTPS continues to be + in my eyes a quite desirable alternative (easy to update, safer than + just clicking away and at the end one step in the right direction). -- openSUSE Feature: https://features.opensuse.org/312047