Re: Secrecy and user trust

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

 



Patrick O'Callaghan wrote:
On Thu, 2008-09-04 at 23:12 +0800, Ed Greshko wrote:
Patrick O'Callaghan wrote:
NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine.
True.
Actually I don't understand the paragraph above.  It seems to be saying
that packages would be signed with a public key which can't be done. So, the person making that statement needs to clarify.

Which is the point I made earlier.
And packages signed with any valid redhat key would be rejected.
Which is what I said. Thus it would be noticed immediately.
No, they would not be rejected as long as you still have Red Hat's
public key installed on your system.  You can determine what public keys
are on your system by "rpm -qa gpg-pubkey*".
When an rpm is signed it is signed with a private key and information
about the corresponding public key is placed in the rpm file.  That
information is used to retrieve the correct public key for
verification.  So, as long as you've not deleted it, they will verify.

The hypothetical scenario being discussed is that you have already
replaced the former (good but now possibly suspect) public key with a
spurious new one. If that were to happen, you would be in danger of
accepting trojanned packages signed with this new fake key. My point is
that you would also *reject* packages signed with the new good key, and
this would be noticed very quickly (basically the next time you did an
update).

That's exactly right, and why the public key should be as trustworthy as possible, because once you accept a single trojanned package you may either suffer damage immediately, or have some part of the "next time you did an update" fail. Imagine a slight change to updated so it never tells you there *is* an update.

I am making the point that an improved method of checking the new key is desirable, technically possible, and that a false package could cause problems in a very short time, and might be able to hide thereafter.

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

--
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