Re: Secrecy and user trust

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Bill Davidsen" <davidsen@xxxxxxx>
Sent: Friday, 2008, September 05 06:59


Jeff Spaleta wrote:

If you want to be security paranoid concerning the validity of the new
key when it becomes available.. go right ahead.. be paranoid about it.
 But if you need 3rd parties to sign off on the key before you use it,
then you should already have been talking to 3rd parties about doing
it for the last Fedora key. Talk to the 3rd parties.. get them to
agree to sign the new key and put the detached signatures somewhere
public.

This is a (hopefully) one-time problem, and therefore it probably doesn't need a perfect, automated, runs-by-itelf solution. And my assumption has been that some people at other repositories do personally know and interact with official people in the Fedora project, and that there is an out-of-band way to pass information to the people at some other repository. Given the nature of the problem, that could mean carrying a CD a hundred miles to meet with someone who is personally known to you from a presentation, etc, etc. It need not be pretty, let's assume that this is a one-time problem.

The the other repository creates an RPM, containing not the key, but the RPM created by Fedora, signed appropriately, which in turn contains the new key, and distributes an RPM which installs an RPM, which rpm (the program) now knows how to handle. So instead of signing a key, they create and sign an RPM which itself contains an RPM, which can be manually installed by the cautious.

Does that satisfy the technical issues you raised? It's what I had in mind initially, when I proposed a secure means of distributing the information. I know it's ugly, but it's a one night stand.

Psssst - come over here in the corner while I whisper in your ear about
companies like Verisign. That WOULD solve the problem. It would also
violate the Open Source concept of Fedora upsetting the purists.

If you download initially from Fedora then you either trust the connection
today or you do not. And some mechanism needs to be invented that can
declare "trust old key for items dated older than XXX. After that trust
only this new key until YYY, after which you will need an even newer key."

That's probably the infrastructure improvements they mumbled about in
their status reports.

{^_-}

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux