Secrecy and user trust

Aldo Foot lunixer at gmail.com
Thu Sep 4 16:05:28 UTC 2008


On Thu, Sep 4, 2008 at 8:29 AM, Patrick O'Callaghan
<pocallaghan at gmail.com> 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).
>
> poc

That's what logic says. Things should work If a new private key is created
and the corresponding public key distribuited.
Doesn't matter how many fake keys I may have. I'll know something
is wrong with my updates if I have a pirate public key.

~af




More information about the fedora-list mailing list