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
