Re: Secrecy and user trust

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

 



On Fri, Sep 5, 2008 at 11:24 AM, Todd Denniston
<Todd.Denniston@xxxxxxxxxxxxxxxxxx> wrote:
> 3) you apparently believe that RPM must be able to directly use these
> signatures.
> I believe The extra signatures are for USERS to VERIFY _before_ feeding the
> DATA of the KEY to RPM.

If we are going to wait to distribute the key only after the detached
signatures are available for inclusion with the key... yes..i think
holding off on the distribution should in fact only be done if we can
make use of those signatures client side. if we cant.. there's no
point in holding off on distribution. You as an individual are free to
hold off on making use of that key until there are a reasonable number
of signatures associated with the key as it sits on a public
keyserver.

> 5) we both agree that a key that is JUST signed by random internet users who
> were not given the key data securely from the physical machine to be of
> little to no value.
> However I may be under the mistaken idea that a few of the folks who
> are community members, actually work and live very near Red Hat's brick and
> mortar location.  And I could be under the further mistaken idea that a
> subset
> of those might actually be willing to make the trip to get the key and begin
> the web.
> BTW, I consider many of the Red Hat employees to be part of the Fedora
> community.

How many of those people went ahead and signed the previous key as
seen on pgp.mit.edu? Which ones of those people are the people you
think have physical access to the key as Red Hat employees? All of
them? None of them? particular people on that list of signatories? But
since you can't reasonably verify that the physically had access to
the key.. you still have to trust those individuals that they did.  If
you want specific individuals that you trust to sign the key... lobby
those individuals to sign the key.

> 6) you and apparently disagree that OUT OF BAND conformation of data has
> value. Where in band would be a signature RPM could use.

At no point have a said that out of band verification doesn't have
value. I am saying that delaying the distribution of the key makes no
sense if we must rely on the vast majority of users to use out of band
verification. If you personally need to wait for out of band
verification.. then wait.. don't use the key until you feel
comfortable with its validity. If that comfort level never comes for
you personally, then so be it.  But we aren't going to be flying
Release Engineering members all over the world with cdroms in hand to
build the web of trust. Well not unless you want to pay for the
tickets and their perdiems.

>
> 7) I believe communicating on this list and suggesting that I would like to
> see out of band data created, counts as 'talking' to some of the 3rd parties
> I would like to see sign the data. It appears in your message that you do
> not.

pgp.mit.edu exists... use it for the out-of-band data all you want. It
doesn't really matter whether or not I need that data to exist. What
matters is that can we realisticly build a viable web of trust around
the key, If you think we can, then go ahead...do it. But if you plan
involves flying release engineering people to your doorstep.. I'll
make sure I get your the correct addresses to send the plane tickets
and the perdiem expense money.

>
> 8) to answer the question of "Who should be the first to sign the key?":
> SOME ENTITY IS USING THE NEW KEY TO SIGN NEW PACKAGES... CORRECT?
> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html
> That entity would be the logical choice for _one_ of the first signatures
> placed on the public key, even if _I_ don't have them as an ultimately
> trusted
> source.
>
> 9) RE:
>> At best we could maybe get the release engineering people who have
>> direct access to the key to create detached signatures, <SNIP>
>> Are those people in your web of trust?
>
> Not sure, funny thing about a web of trust, a person knows a couple of other
> folks and they intern know a few folks...
> Oh and there the, very near the signing machine, persona of
> <security@xxxxxxxxxx> and <secalert@xxxxxxxxxx> which are probably already
> fairly protected by the policies of the company standing behind them.

You'll note that security@xxxxxxxxxx already signed the previous key
as it sits on pgp.mit.edu. Is that entities signature enough for you
personally? Then wait for that signature to show up on pgp.mit.edu for
the new key after the new key shows up there.
Just as Jesse could sign it and place that signature at pgp.mit.edu
for you to verify.
Is Jesse's personal signature enough for you? is it enough for
everyone else who wants to see detached signatures? If you remember
the started with a discussion about having livna sign the key...not
Fedora release engineering.  Why exactly can't you and others wait for
which ever signatures you trust to show up on the key as it sits on
pgp.mit.edu before you make use of the key?


-jef

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