11:36 a.m.
Having been a participant or project leader for system programs, systems
and network administration, and security development and monitoring for
some decades, it seems to me that the Fedora project is lacking the most
important clue on handling a security issue, that of keeping the users
informed so they can make rational decisions.
If the infrastructure problem was caused by a disgruntled employee
rather than a gaping hole in the security of the distribution, that
should have been said, to reassure users that they don't have the same
hole. Yes, there may be code which snuck in after the compromise, we
understand that.
If there is a hole, users should know that, even if you don't have a
fix, to avoid the impression that the problems are being covered up.
If there is a known date before which packages can be trusted, that
should be said. Users who lag the cutting edge will be reassured. People
won't have to be checking security logs for a decade if the problem is
more recent. People on distributions older than FC8 which are not
maintained should be told if the problem goes back that far.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
11:27 a.m.
On 02/09/2008, Bill Davidsen <davidsen(a)tmr.com> wrote:
If there is a known date before which packages can be trusted, that
should be said. Users who lag the cutting edge will be reassured. People
won't have to be checking security logs for a decade if the problem is
more recent. People on distributions older than FC8 which are not
maintained should be told if the problem goes back that far.
The infrastructure is up and running. We have been told that new
updates will be made available as soon as they (and existing content)
have been signed with a new key. They have announced that they do not
believe there is any risk from existing content. What do you want to
know?
11:42 a.m.
Bill Crawford wrote:
On 02/09/2008, Bill Davidsen <davidsen(a)tmr.com> wrote:
> If there is a known date before which packages can be trusted, that
> should be said. Users who lag the cutting edge will be reassured. People
> won't have to be checking security logs for a decade if the problem is
> more recent. People on distributions older than FC8 which are not
> maintained should be told if the problem goes back that far.
The infrastructure is up and running. We have been told that new
updates will be made available as soon as they (and existing content)
have been signed with a new key. They have announced that they do not
believe there is any risk from existing content. What do you want to
know?
When and how did the intrusion occur? How was it initially detected?
--
Les Mikesell
lesmikesell(a)gmail.com
11:51 a.m.
On 02/09/2008, Les Mikesell <lesmikesell(a)gmail.com> wrote:
When and how did the intrusion occur? How was it initially detected?
*shrug*
I don't actually need to know, so I'm not making a fuss.
I suspect, as has been hinted at here multiple times, there may be
legal reasons why they haven't provided you with some of the details
you would like to see.
I'd suggest re-reading the announcement that Paul W. Frields sent out
(url below) and then, should you really, really feel the need to know
more, I'd suggest you contact whoever at the Fedora Project you pay
for support, complaining about your SLA not being met ;o)
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....
12:16 p.m.
Bill Crawford wrote:
> When and how did the intrusion occur? How was it initially detected?
*shrug*
I don't actually need to know, so I'm not making a fuss.
Everyone needs to whether or not they are at risk with the same
vulnerability and how to detect it.
I suspect, as has been hinted at here multiple times, there may be
legal reasons why they haven't provided you with some of the details
you would like to see.
I'd suggest re-reading the announcement that Paul W. Frields sent out
(url below) and then, should you really, really feel the need to know
more, I'd suggest you contact whoever at the Fedora Project you pay
for support, complaining about your SLA not being met ;o)
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....
This is about community, not SLA's. Communities are easily alienated
when not included in needed communications. I'd suggest reconsidering
whether your community is important or not.
--
Les Mikesell
lesmikesell(a)gmail.com
12:46 p.m.
* Les Mikesell <lesmikesell(a)gmail.com> [20080902 19:15]:
Bill Crawford wrote:
>
>> When and how did the intrusion occur? How was it initially detected?
>
> *shrug*
>
> I don't actually need to know, so I'm not making a fuss.
Everyone needs to whether or not they are at risk with the same
vulnerability and how to detect it.
Les,
This has been gone over more than once, and you have been involved in
the discussions. You already know what has been said, so there is
really no need to rehash it again.
> I suspect, as has been hinted at here multiple times, there may
be
> legal reasons why they haven't provided you with some of the details
> you would like to see.
>
> I'd suggest re-reading the announcement that Paul W. Frields sent out
> (url below) and then, should you really, really feel the need to know
> more, I'd suggest you contact whoever at the Fedora Project you pay
> for support, complaining about your SLA not being met ;o)
>
> http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....
This is about community, not SLA's. Communities are easily alienated
when not included in needed communications. I'd suggest reconsidering
whether your community is important or not.
I keep hearing this statement from a small but rather vocal selection
of people. This selection of people has a rather large overlap with
another small selection of people who is keen on complaining about a
lot of other things about the Fedora project.
Follow announce-list, when there is news, it'll be posted there.
/Anders
12:37 p.m.
On Tue, 2008-09-02 at 17:51 +0100, Bill Crawford wrote:
On 02/09/2008, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> When and how did the intrusion occur? How was it initially detected?
*shrug*
I don't actually need to know, so I'm not making a fuss.
I disagree. I think we do need to know. What I don't worry about is
knowing *immediately*. I'm willing to cut the Fedora devs some slack as
it may be an ongoing situation and I don't doubt they are fully occupied
in pushing updates, signing packages etc.
However I think we have a right to expect a much more detailed report on
this "in due course" (no, I don't know how long that is).
poc
12:49 p.m.
Bill Crawford wrote:
On 02/09/2008, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> When and how did the intrusion occur? How was it initially detected?
*shrug*
I don't actually need to know, so I'm not making a fuss.
I suspect, as has been hinted at here multiple times, there may be
legal reasons why they haven't provided you with some of the details
you would like to see.
As noted, the detail I would have liked was to know if this was a
failure of system security or a failure of misplaced trust. If there is
a hole in their server system security it's likely to be in ours as well.
And if someone could say with certainty that packages downloaded before
{date} were safe, it would be more reassuring than "there is little
risk to Fedora users who wish to install or upgrade signed Fedora
packages." If the start date of the problem is known, that would be
really good information for people who keep a local repository and don't
have to upgrade every new install totally over the network.
I'd suggest re-reading the announcement that Paul W. Frields sent out
(url below) and then, should you really, really feel the need to know
more, I'd suggest you contact whoever at the Fedora Project you pay
for support, complaining about your SLA not being met ;o)
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....
I felt the need to spend some of my three day holiday reinstalling
servers with another distribution, when knowing the start date of the
problem would have let me make an intelligent choice. Saying "was
quickly discovered" doesn't tell me if it was minutes, hours, or months.
What I was looking for was a "safe if loaded before" date.
So yes, I "really, really" felt the need to know more.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
12:55 p.m.
Quoting Bill Davidsen <davidsen(a)tmr.com>:
As noted, the detail I would have liked was to know if this was a
failure of system security or a failure of misplaced trust. If there is
a hole in their server system security it's likely to be in ours as
well.
And if someone could say with certainty that packages downloaded before
{date} were safe, it would be more reassuring than "there is little
risk to Fedora users who wish to install or upgrade signed Fedora
packages." If the start date of the problem is known, that would be
really good information for people who keep a local repository and
don't have to upgrade every new install totally over the network.
Well, I know someone on this list said I should feel safe in upgrading
my F6 box to F9. I don't know if that answers your questions or not.
That being said, I think I'll wait until F10 or until fresh ISO images
come out. Despite the fact that my only installation is a single,
personal box, I don't want to risk getting hacked because someone
*may* have gotten some bogus packages into the system and/or
compromised the signing key for Fedora.
Unless/until someone from Fedora says "It is safe to install Fedora 9
from the original ISO images distributed when F9 was released" I am
not going to trust that they are safe.
3:52 p.m.
John Aldrich wrote:
Quoting Bill Davidsen <davidsen(a)tmr.com>:
>
> As noted, the detail I would have liked was to know if this was a
> failure of system security or a failure of misplaced trust. If there is
> a hole in their server system security it's likely to be in ours as
> well.
>
> And if someone could say with certainty that packages downloaded before
> {date} were safe, it would be more reassuring than "there is little
> risk to Fedora users who wish to install or upgrade signed Fedora
> packages." If the start date of the problem is known, that would be
> really good information for people who keep a local repository and
> don't have to upgrade every new install totally over the network.
>
Well, I know someone on this list said I should feel safe in upgrading
my F6 box to F9. I don't know if that answers your questions or not.
That being said, I think I'll wait until F10 or until fresh ISO images
come out. Despite the fact that my only installation is a single,
personal box, I don't want to risk getting hacked because someone *may*
have gotten some bogus packages into the system and/or compromised the
signing key for Fedora.
Unless/until someone from Fedora says "It is safe to install Fedora 9
from the original ISO images distributed when F9 was released" I am not
going to trust that they are safe.
Hey I am currently downloading the ISO dvd to install after I finish my
day's lessons, is this not a good idea to do?
Travis
4 p.m.
On Tue, 02 Sep 2008 16:52:08 -0400
vestwearingpunk(a)gmail.com (Travis Arnold) wrote:
John Aldrich wrote:
...snipp...
> Unless/until someone from Fedora says "It is safe to
install Fedora
> 9 from the original ISO images distributed when F9 was released" I
> am not going to trust that they are safe.
>
Hey I am currently downloading the ISO dvd to install after I finish
my day's lessons, is this not a good idea to do?
From:
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....
"At this time we are confident there is little
risk to Fedora users who wish to install or upgrade signed Fedora
packages."
This pretty heavily implies to me that the iso images are fine as
shipped when F9 was released. Do you expect the project to announce
each item that is ok? Instead, please expect that anything that was
bad/wrong/shouldn't be used would be heavily announced and removed from
download.
Also, you might consider using the fedora
unity respin and save yourself some time downloading updates:
http://spins.fedoraunity.org/spins
Travis
kevin
4:04 p.m.
* Travis Arnold <vestwearingpunk(a)gmail.com> [20080902 22:52]:
[drivel snipped]
>
Hey I am currently downloading the ISO dvd to install after I finish my
day's lessons, is this not a good idea to do?
The word from the Fedora folks on Aug 14th was - don't update until
further notice. Since then, they have - IIRC - said it's safe to do
so. The ISO's should be safe, as well as the packages that you can
update to from the servers.
New updates should start rolling once they have resigned everything.
/Anders
5:06 p.m.
On Tue, Sep 2, 2008 at 2:04 PM, Anders Karlsson <anders(a)trudheim.co.uk> wrote:
* Travis Arnold <vestwearingpunk(a)gmail.com> [20080902 22:52]:
[drivel snipped]
> >
> Hey I am currently downloading the ISO dvd to install after I finish my
> day's lessons, is this not a good idea to do?
The word from the Fedora folks on Aug 14th was - don't update until
further notice. Since then, they have - IIRC - said it's safe to do
so. The ISO's should be safe, as well as the packages that you can
update to from the servers.
New updates should start rolling once they have resigned everything.
/Anders
For once I'm glad I've not updated my system in the last few
days; and I won't for quite a few more.
~af
9:30 a.m.
Anders Karlsson wrote:
* Travis Arnold <vestwearingpunk(a)gmail.com> [20080902 22:52]:
[drivel snipped]
> Hey I am currently downloading the ISO dvd to install after I finish my
> day's lessons, is this not a good idea to do?
The word from the Fedora folks on Aug 14th was - don't update until
further notice. Since then, they have - IIRC - said it's safe to do
so. The ISO's should be safe, as well as the packages that you can
update to from the servers.
New updates should start rolling once they have resigned everything.
Distributing that will be quite slow, since they need to (a) validate,
then (b) sign, then (c) distribute out-of-band to mirrors, and then
hardest of all find a secure way to provide the public part of the
signing key. Obviously you don't risk letting someone slip in a bogus
NEW fake key and go around on this again.
Suggestion: since the livna key is still secure (AFAIK) let them
distribute the new Fedora key and sign the RPM.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
10:42 a.m.
On Wed, 03 Sep 2008 10:30:39 -0400
davidsen(a)tmr.com (Bill Davidsen) wrote:
Anders Karlsson wrote:
> * Travis Arnold <vestwearingpunk(a)gmail.com> [20080902 22:52]:
> [drivel snipped]
>> Hey I am currently downloading the ISO dvd to install after I
>> finish my day's lessons, is this not a good idea to do?
>
> The word from the Fedora folks on Aug 14th was - don't update until
> further notice. Since then, they have - IIRC - said it's safe to do
> so. The ISO's should be safe, as well as the packages that you can
> update to from the servers.
>
> New updates should start rolling once they have resigned everything.
>
Distributing that will be quite slow, since they need to (a)
validate, then (b) sign, then (c) distribute out-of-band to mirrors,
Well, depends on what you mean by quite slow, but yes, doing all the
re-signing is taking a while right now. Distribution to mirrors will be
the next bottleneck.
and then hardest of all find a secure way to provide the public part
of the signing key. Obviously you don't risk letting someone slip in
a bogus NEW fake key and go around on this again.
Indeed.
The proposed plan (that has since had a few modifications):
http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html
Suggestion: since the livna key is still secure (AFAIK) let them
distribute the new Fedora key and sign the RPM.
That was suggested before, but it's not a great solution for several
reasons: Not everyone has livna enabled. Having one repo publish keys
for another seems wrong, especially when they are not officially
connected.
kevin
8:49 p.m.
Kevin Fenzi wrote:
On Wed, 03 Sep 2008 10:30:39 -0400
davidsen(a)tmr.com (Bill Davidsen) wrote:
[...]
> and then hardest of all find a secure way to provide the public
part
> of the signing key. Obviously you don't risk letting someone slip in
> a bogus NEW fake key and go around on this again.
Indeed.
The proposed plan (that has since had a few modifications):
http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html
Since rpm/yum don't have any method to handle a key revocation, this
process is harder than it might otherwise be. As I understand the
plan currently, the new key will be included in an updated
fedora-release package that will be signed by the old key. This will
make the change as transparent as possible for most users and since it
is not believed that the old key is compromised at this time, it is
reasonably secure. (Insert various caveats regarding the meaning of
"reasonably secure" and "not believed ... compromised ..." as
needed.)
I presume that the new key's fingerprint and other details will be
added to https://fedoraproject.org/keys sometime soon and that can be
used by those who want a bit more verification of the new key before
trusting it.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sanity is the trademark of a weak mind.
-- Mark Harrold
11:41 a.m.
On Thu, 2008-09-04 at 17:16 +0100, Bill Crawford wrote:
On 04/09/2008, Todd Zullinger <tmz(a)pobox.com> wrote:
> Since rpm/yum don't have any method to handle a key revocation, this
> process is harder than it might otherwise be.
"rpm -e --allmatches gpg-pubkey-$fingerprint" not enough? ;o)
Revocation doesn't just mean removing a key, it means declaring it to be
invalid so it won't be used in the future.
poc
8:11 a.m.
Bill Davidsen:
> Suggestion: since the livna key is still secure (AFAIK) let them
> distribute the new Fedora key and sign the RPM.
Kevin Fenzi:
That was suggested before, but it's not a great solution for
several
reasons: Not everyone has livna enabled. Having one repo publish keys
for another seems wrong, especially when they are not officially
connected.
I'm not sure whether *also* having the keys on other sites is so bad.
If you take it like the GPG model - countersigning and cross-checking
through other sources that you also trust. If Livna, ATRPMs, and a few
other usual repos had the same Fedora public key, you'd be more
confident that the key you got from what you think is a real Fedora
mirror, is the right one.
--
[tim@localhost ~]$ uname -r
2.6.25.14-108.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
12:37 p.m.
Tim wrote:
I'm not sure whether *also* having the keys on other sites is so
bad.
If you take it like the GPG model - countersigning and cross-checking
through other sources that you also trust. If Livna, ATRPMs, and a few
other usual repos had the same Fedora public key, you'd be more
confident that the key you got from what you think is a real Fedora
mirror, is the right one.
There certainly isn't anything stopping others from singing the Fedora
key (as can be seen by the number of signatures already¹. I do wonder
how many of those folks have met with the holder of the secret part of
the Fedora key for verifying the fingerprint.
Another issue with adding signatures to the key is that rpm has no
ability to check those signatures (I'm not even sure if it imports
a key with multiple signatures properly). Now that rpm is being more
actively developed and the lack of a key revocation feature has been
felt, maybe someone will submit some patches to add such features².
¹
http://subkeys.pgp.net:11371/pks/lookup?search=0x4F2A6FD2&fingerprint...
² http://wiki.rpm.org/Contribute
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So its hurry! Hurry! Step right up, it's a matter of life or death
The sun is going down and the moon is just holding its breath.
3:38 p.m.
Tim wrote:
Bill Davidsen:
>> Suggestion: since the livna key is still secure (AFAIK) let them
>> distribute the new Fedora key and sign the RPM.
Kevin Fenzi:
> That was suggested before, but it's not a great solution for several
> reasons: Not everyone has livna enabled. Having one repo publish keys
> for another seems wrong, especially when they are not officially
> connected.
I'm not sure whether *also* having the keys on other sites is so bad.
I give up, politics as usual. If a proposed solution isn't perfect it
isn't good enough, so trust us.
If you take it like the GPG model - countersigning and
cross-checking
through other sources that you also trust. If Livna, ATRPMs, and a few
other usual repos had the same Fedora public key, you'd be more
confident that the key you got from what you think is a real Fedora
mirror, is the right one.
Well said. Common sense. The political answer is "wait until new
improved RPM comes out."
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
1:42 p.m.
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
hardest of all find a secure way to provide the public part of the
signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.
poc
1:49 p.m.
On Wed, Sep 03, 2008 at 14:12:47 -0430,
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
> hardest of all find a secure way to provide the public part of the
> signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.
You still need a secure channel. What is changed is that it only needs
protection for integrity, not eavesdropping. The worst case is actually a
man in the middle attack.
10:42 p.m.
Patrick O'Callaghan wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
> hardest of all find a secure way to provide the public part of the
> signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.
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. And packages signed with any valid redhat key would be
rejected.
The public key really must be distributed in a secure manner.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
12:37 a.m.
* Bill Davidsen <davidsen(a)tmr.com> [20080904 05:29]:
Patrick O'Callaghan wrote:
> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>> hardest of all find a secure way to provide the public part of the
>> signing key
>
> The whole point about asymmetric encryption is that you don't need a
> secure distribution channel. The worst that can happen is that some fake
> public key gets distributed, which won't match the private key and hence
> will be instantly detectable.
>
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. And packages signed with any valid redhat key would be
rejected.
The public key really must be distributed in a secure manner.
I am sure the infrastructure team is all ears for a detailed
suggestion on how you believe this should be achieved. And with your
extensive experience in the field - you ought to be able to provide a
detailed plan of action.
It's very easy sitting at the side-line criticising, but actually
*doing* it is much harder.
IMHO - we're at the "put up or shut up" point with the criticism now.
/Anders
12:26 p.m.
Anders Karlsson wrote, On 09/04/2008 01:37 AM:
* Bill Davidsen <davidsen(a)tmr.com> [20080904 05:29]:
> Patrick O'Callaghan wrote:
>> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>>> hardest of all find a secure way to provide the public part of the
>>> signing key
>> The whole point about asymmetric encryption is that you don't need a
>> secure distribution channel. The worst that can happen is that some fake
>> public key gets distributed, which won't match the private key and hence
>> will be instantly detectable.
>>
> 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. And packages signed with any valid redhat key would be
> rejected.
>
> The public key really must be distributed in a secure manner.
I am sure the infrastructure team is all ears for a detailed
suggestion on how you believe this should be achieved. And with your
extensive experience in the field - you ought to be able to provide a
detailed plan of action.
It's very easy sitting at the side-line criticising, but actually
*doing* it is much harder.
IMHO - we're at the "put up or shut up" point with the criticism now.
/Anders
See the suggestion I made a while back[4] for further information about our
current use of cobwebs of trust. My suggestion then was not to take care of
the current situation, it is too late for using it for the current situation,
but it would make any later situations easier to deal with. I still think
Fedora needs a master key made (soon after the current situation is resolved)
so that we can start building at least a cobweb for it.
suggestions for now:
1) sign the new key with the old key... it is the infrastructure team's plan
to do so any way, and many folks will be happy with it.
2) distribute [email | website posting | mass CD mailing] a version of the new
key signed by SEVERAL prominent Fedora and OSS/Free software community
members. (So any conceived conspiracy has to be larger, and more likely found
out :)
[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
{something seems bonkers with the way the html is showing the footnotes at
the end of the message, as it looks like footnote 2 is referencing 3-7, but
those seem to have been concatenated onto the same line with footnote 2.}
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
3:58 p.m.
Anders Karlsson wrote:
* Bill Davidsen <davidsen(a)tmr.com> [20080904 05:29]:
> Patrick O'Callaghan wrote:
>> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>>> hardest of all find a secure way to provide the public part of the
>>> signing key
>> The whole point about asymmetric encryption is that you don't need a
>> secure distribution channel. The worst that can happen is that some fake
>> public key gets distributed, which won't match the private key and hence
>> will be instantly detectable.
>>
> 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. And packages signed with any valid redhat key would be
> rejected.
>
> The public key really must be distributed in a secure manner.
I am sure the infrastructure team is all ears for a detailed
suggestion on how you believe this should be achieved. And with your
extensive experience in the field - you ought to be able to provide a
detailed plan of action.
It's very easy sitting at the side-line criticising, but actually
*doing* it is much harder.
Which is why I made a concrete and readily implemented suggestion that
the new key be distributed by livna (and/or atrpm, etc) signed with a
key which is believed to be secure, preferably several of them.
No one claimed that it couldn't be done, or even that it wouldn't work,
just that it was bad politics to have another repo sign.
IMHO - we're at the "put up or shut up" point with the criticism now.
I offered a technically viable solution for new key signing and
distribution, it was rejected for political reasons. Sorry you feel
that's criticism.
/Anders
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3:52 p.m.
On Thu, Sep 4, 2008 at 12:58 PM, Bill Davidsen <davidsen(a)tmr.com> wrote:
No one claimed that it couldn't be done, or even that it
wouldn't work, just
that it was bad politics to have another repo sign.
Has anyone with the authority to sign with the livna key come forward
and said they'd be willing to do it?
Have you tested recently rpm's ability to import keys that have been
signed versus bare keys?
-jef
3:57 p.m.
On Thu, Sep 04, 2008 at 12:52:51 -0800,
Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Thu, Sep 4, 2008 at 12:58 PM, Bill Davidsen
<davidsen(a)tmr.com> wrote:
> No one claimed that it couldn't be done, or even that it wouldn't work,
just
> that it was bad politics to have another repo sign.
Has anyone with the authority to sign with the livna key come forward
and said they'd be willing to do it?
Have you tested recently rpm's ability to import keys that have been
signed versus bare keys?
Is that what my problem was yesterday? I filed a bugzilla about a key I
was trying to import (mostly about the error message not being very helpful)
and got feedback that the key was importable by the rawhide rpm. (Which I hope
to test late tonight or tomorrow.)
4:05 p.m.
On Thu, Sep 4, 2008 at 12:57 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
Is that what my problem was yesterday? I filed a bugzilla about a key
I
was trying to import (mostly about the error message not being very helpful)
and got feedback that the key was importable by the rawhide rpm. (Which I hope
to test late tonight or tomorrow.)
Was it? I not completely up to speed on rpm's capabilities. But I
think it was a problem at one point.... but i may not be remembering
correctly. You shouldn't trust me.
I think it would be wisest for the people who are suggesting that
signed keys be used... go ahead and test that rpm can import them on
F8 and F9 systems. If it doesn't work.. its a non-starter from a
technical perspective and we need to move on.
-jef
4:59 p.m.
Jeff Spaleta wrote, On 09/04/2008 05:05 PM:
On Thu, Sep 4, 2008 at 12:57 PM, Bruno Wolff III
<bruno(a)wolff.to> wrote:
> Is that what my problem was yesterday? I filed a bugzilla about a key I
> was trying to import (mostly about the error message not being very helpful)
> and got feedback that the key was importable by the rawhide rpm. (Which I hope
> to test late tonight or tomorrow.)
Was it? I not completely up to speed on rpm's capabilities. But I
think it was a problem at one point.... but i may not be remembering
correctly. You shouldn't trust me.
I think it would be wisest for the people who are suggesting that
signed keys be used... go ahead and test that rpm can import them on
F8 and F9 systems. If it doesn't work.. its a non-starter from a
technical perspective and we need to move on.
-jef
Although rpm may not have the ability to use keys with signatures in them,
this does NOT make it a non-starter.
PGP|GPG can generate DETACHED signatures[1], which can be used with the public
key file out side of rpm's band to verify the new key.
[1] gpg --help 2>&1 |grep "detached signature"
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
6:22 p.m.
On Thu, Sep 4, 2008 at 1:59 PM, Todd Denniston
<Todd.Denniston(a)ssa.crane.navy.mil> wrote:
Although rpm may not have the ability to use keys with signatures in
them,
this does NOT make it a non-starter.
It's going to impact in what fashion we distribute the key. if we
can'd distribute the signed key and have it import as expected...then
there's no point in attempting to distribute a signed key. Do all
this 3rd party signing stuff on a public key server.
PGP|GPG can generate DETACHED signatures[1], which can be used with the
public key file out side of rpm's band to verify the new key.
what is stopping any 3rd party from generating detached signatures
right now? What was stopping them from doing it on the last key? If
you or I or livna or anyone else wanted to create a detached signature
on the Fedora key..we could have..and we'd still be we are right now
dealing with how to distribute a new key. The extra signatures do not
materially help because we do not have a technical mechanism to make
use of those signatures as part of the client side package management
operations. Look at the existing Fedora key as it sits on the
pgp.mit.edu key server. People have signed it there. We have no way to
make use of that information client side. But you can... anyone can...
just as anyone can push a new signature against that existing key.
Nor do we have a special mechanism which lets 3rd parties verify the
key's validity that individual end-users do not have. And this last
one is key. Having livna, or myself, or you.. sign a key that was
transmitted electronically to us doesn't do squat in terms of
increasing its trustability. if anything it distorts the web of trust
because we've signed something we can't tangible verify.
Distributing the detached signatures as part of the fedora-release
package with a bare importable key..when we aren't making use of
those detached signatures as part of the packaging process..at
all...seems...futile to me. We don't have a mechanism which enforces
the existence of signatures on the keys in the rpm keyring. There is
no trust metric exposed by which you can rank the trustability of a
particular key when using it. If you want 3rd parties to sign the
Fedora packaging signing key... talk to the 3rd parties about signing
the new key as soon as its made available and placing those detached
signatures on sites they control or a public key server so you can
verify the detached signatures when Fedora releases the bare key with
3rd parties you personally trust.
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.
If you can convince them to actually sign the key, since they have the
exact same problem that you have.. they have to be transmitted the key
in order for them to sign it. So they have to trust the transmission
of the key... just as you do. There is a basic logic fallacy here,
some 3rd party has to initially trust the key. If you personally
aren't going to be that 3rd party...then why would you expect another
3rd party to be the first? If you are going to be paranoid about
verifying the transmission of the new key to yourself... then you have
to be equally paranoid about how the signatories of that key were
transmitted the key before they signed it.
GPG keysigning events typically involve face-to-face meetings with
some form of official documentation (drivers licenses AND passports
typically) which people agree to trust. Those identification documents
are crucial elements of GPG signing events... they form a baseline
expectation that you are who you say you are. You can't do that sort
of thing with the fedora signing key. You can't meet face-to-face to
verify its identity, you can't get government issued ID which form the
baseline for trust (assuming the ID is of course not falsified).
At best we could maybe get the release engineering people who have
direct access to the key to create detached signatures, because they
perhaps the only people who do not have to be transmitted the key in
order to sign it. But now you are left with the problem of trusting
their personal keys. Are those people in your web of trust? Are you
going to meet face to face with them and exchange key signatures? If
rpm's key management doesn't handle signed keys..how do you know to
trust their keys which signed the signature.
And on and on....all of it outside of the band of rpm. We don't have
a compelling reason to distribute those detached signatures as part of
the fedora-release package which will contain the key. We don't have
a way to make use of them, and if you have to go out of band to verify
the key...then go out of band. All including them will do will slow
down the process of getting the new key out to anyone as we wait for
3rd parties to sign the key and had the signatures back to us to
distribute. What's stopping anyone from doing all of this 3rd party
signing part of public key server operations? Someone publishes the
Fedora signing key to a key server, 3rd parties pull the key and sign
it and push the signatures back up to the key server. You then take
the time out of band to check that key server for signatures.
In fact none of this has to be steps that Fedora as a project has to
take. Since you can't verify that Fedora sent the key to the
keyserver, Once I get the key transmitted to me electronically I
could upload to a public server.. so could you. I could sign it....so
could you...so could anyone. But none of those action impart any
additional trust all that says is that we all received the same key.
Is that really worthwhile information? If you think it is then I
suggest you organize a campaign to have everyone create a detached
signature for the new key when it becomes available and submit it to
one of the pgp keyservers. That sort of organized activity might not
add any real trust metric to the key..but it would be an interested
head count of how many people actually have gpg keys out there in
Fedoraland.
You can take a look at the existing Fedora Project key at
pgp.mit.edu's search. It's been signed by 3rd parties. So some
individuals have signed the key. Do you trust them?
-jef"I should go ahead and sign the old key now, just because it
doesn't matter"spaleta
8:59 a.m.
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.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
9:38 a.m.
On Fri, Sep 05, 2008 at 09:59:26 -0400,
Bill Davidsen <davidsen(a)tmr.com> wrote:
This is a (hopefully) one-time problem, and therefore it probably
Considering that this has happened twice to large distributions (Debian and
Red Hat / Fedora), I think the best we can hope for is rare.
11:46 a.m.
On Fri, Sep 5, 2008 at 5:59 AM, Bill Davidsen <davidsen(a)tmr.com> wrote:
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.
Your assumption absolutely breaks the trust metric. Assume your wrong. Assume
that 3rd party repositories are treated just like any other end-user
to Fedora...because they are just other end-users with absolutely no
special relationship. Assume that.. because that's how it stands.
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.
Are seriously telling us to wait to distribute keys to people so we
can get updates flowing again until someone has flown several hundred
miles and done the GPG key signing dance with a 3rd party repo
signatory and then flown back? Right now for this one time problem..
that is absolutely not worth it. Nor with that ever be worth it.
Especially since every single one of our users were already using a
key that didn't rely on a physical face-to-face 3rd party key signing
up to this point.
-jef
2:03 p.m.
From: "Jeff Spaleta" <jspaleta(a)gmail.com>
Sent: Friday, 2008, September 05 09:46
On Fri, Sep 5, 2008 at 5:59 AM, Bill Davidsen
<davidsen(a)tmr.com> wrote:
> 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.
Your assumption absolutely breaks the trust metric. Assume your wrong.
Assume
that 3rd party repositories are treated just like any other end-user
to Fedora...because they are just other end-users with absolutely no
special relationship. Assume that.. because that's how it stands.
> 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.
Are seriously telling us to wait to distribute keys to people so we
can get updates flowing again until someone has flown several hundred
miles and done the GPG key signing dance with a 3rd party repo
signatory and then flown back? Right now for this one time problem..
that is absolutely not worth it. Nor with that ever be worth it.
Especially since every single one of our users were already using a
key that didn't rely on a physical face-to-face 3rd party key signing
up to this point.
Suppose Fedora generates a new key. They can get it out there by putting
it on their website, in an update RPM, and in plain textual format in
the primary download sites. Then I as a user either trust that or find
I have to take a trip to somebody's office I know is authoritative for
Fedora and get the key on some portable media.
Now, I can also check the key if it is uploaded to all the mirrors the
same way. If I download from a large collection of sites and they all
are bit copies of each other then either the web of deceit is so large
we're all lost anyway or I have a good key.
So the focus of the discussion is silly. Trust is established once, in
some way. Use the same way again that satisfied you in the first place
and get on with life.
{^_^} <- betting the real problem is "infrastructure."
2:28 p.m.
jdow wrote:
Suppose Fedora generates a new key. They can get it out there by putting
it on their website, in an update RPM, and in plain textual format in
the primary download sites. Then I as a user either trust that or find
I have to take a trip to somebody's office I know is authoritative for
Fedora and get the key on some portable media.
Now, I can also check the key if it is uploaded to all the mirrors the
same way. If I download from a large collection of sites and they all
are bit copies of each other then either the web of deceit is so large
we're all lost anyway or I have a good key.
Judy, you make too much sense. This thread has long outlived any
useful function, I think. What you just suggested is the automatic,
normal, natural thing anyone would have, and probably nearly everyone
here already has, think of. I'd also publish MD5 and/or SHA1 hashes
of the files, but that' a minor tweak.
So the focus of the discussion is silly. Trust is established once, in
some way. Use the same way again that satisfied you in the first place
and get on with life.
{^_^} <- betting the real problem is "infrastructure."
The only point I saw to the discussion was the first question
posed, which was:
Since Fedora got compromised, we'd like to know
what they run on their servers, and whether we
might ourselves be vulnerable to the same kind of
attack which compromised Fedora in the first place.
If so, we'd like to know what the attack was,
how it succeeded, and how to protect against it.
Recovery seems to me to be obvious and simple. I never saw
(perhaps I missed) an answer to the first question.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
1:55 p.m.
From: "Bill Davidsen" <davidsen(a)tmr.com>
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.
{^_-}
2:24 p.m.
Jeff Spaleta wrote, On 09/04/2008 07:22 PM:
A really long email, read it here:
https://www.redhat.com/archives/fedora-list/2008-September/msg00523.html
0) Although it has been stated that the old fedora key's pass phrase was not
used during the exposure, it is intimated that the soft version of the private
key was available on the machine and could have been copied by the 'agent'.
I, and I believe Bill & Bruno, see this as Someone other than authorized
Fedora representatives have opportunity to have the pass phrase protected
private key, and time to beat on the pass phrase, which means to us the key IS
compromised.
You and a few others, give the appearance that this means nothing.
1) we agree that the best web of trust is generated when ALL of the parties
have physically met and verified each other, i.e., 1 meeting for every public
key I have, granted that's not a web.
2) we apparently do not agree that
(Assuming I like the way A and C verify the folks they sign for.)
if I met A and C and exchanged keys with them, and I get a public key for B
that was signed by A and C in an email from B, then I can trust the key to be
from B, and after some getting to know B, I might even be sane in accepting a
key for D that was signed by B who I have still never met in person.
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.
Do I believe in our current climate (crypto education level) that a large
percentage of Fedora users will take advantage of this out of band data? NO.
Will a reasonable percentage of those who need to use fedora (think support
for new hardware or and algorithms not yet in RHEL), and are supposed to use
due care|diligence in their job, take advantage of this out of band data? I
believe the answer to be YES.
4) So far the only signature on 0X4F2A6FD2 (the old key) that I have _some_
trust in is from 0xDB42A60E.
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.
6) you and apparently disagree that OUT OF BAND conformation of data has
value. Where in band would be a signature RPM could use.
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.
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(a)redhat.com> and <secalert(a)redhat.com> which are probably already
fairly protected by the policies of the company standing behind them.
10) RE:
We don't have
a compelling reason to distribute those detached signatures as part of
the fedora-release package which will contain the key.
Note that the only detached signatures which I ever suggest should be
distributed with the fedora-release package were of a Fedora master key
persona that does not YET exist.
Think about "PKI" a little bit,
is "GTE CyberTrust Global Root" Serial Number 01:A5 a person?
is "Akamai Subordinate CA 3" Serial Number 04:00:04:03 a person?
is "www.redhat.com" Serial Number 01:00:00:00:00:01:17:6B:14:92:65 a person?
we both know the answer is NO to all the above, and we both know that for the
persona "Akamai Subordinate CA 3" and the persona "GTE CyberTrust Global
Root"
ultimately a (probably trust-able) person enters appropriate data under
appropriate rules to make the key available for the encryption system to sign
other data.
And we both trust it every time we go to https://www.redhat.com/archives/fedora-*
I am asking that the fedora project create a 'root' that will be protected
appropriately so it can be ultimately trusted into the future, so the PROJECT
can vouch for any other NEW keys they HAVE to distribute, so that the new key
can be trusted AS SOON as it is made available. And I am proposing
that it will, by the time it is needed, be trusted much as the keys we have
for <security(a)redhat.com> and <secalert(a)redhat.com>, i.e., some have chains
that go to the source, others will trust based on age and lack of complaints.
BTW infrastructure folks and J. Keating, I think you have been doing the best
job possible. What you see in this message is my attempt at a discussion
mostly over policy.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
3:07 p.m.
On Fri, Sep 5, 2008 at 11:24 AM, Todd Denniston
<Todd.Denniston(a)ssa.crane.navy.mil> 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(a)redhat.com> and <secalert(a)redhat.com> which are probably already
fairly protected by the policies of the company standing behind them.
You'll note that security(a)redhat.com 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
5:08 p.m.
Jeff, please excuse me if I'm taking too much out of context from your
mail.
Jeff Spaleta wrote:
GPG keysigning events typically involve face-to-face meetings with
some form of official documentation (drivers licenses AND passports
typically) which people agree to trust. Those identification documents
are crucial elements of GPG signing events... they form a baseline
expectation that you are who you say you are. You can't do that sort
of thing with the fedora signing key. You can't meet face-to-face to
verify its identity, you can't get government issued ID which form the
baseline for trust (assuming the ID is of course not falsified).
It is quite true that the Fedora key cannot be verified by most of us
in the same way that we could verify the key of an individual. But...
At best we could maybe get the release engineering people who have
direct access to the key to create detached signatures, because they
perhaps the only people who do not have to be transmitted the key in
order to sign it.
This would be excellent. (Though I would hate to ask Jesse to do any
more work at this time. :)
But now you are left with the problem of trusting their personal
keys. Are those people in your web of trust?
Yes. From FUDCon Raleigh, I'm a hop away from Jesse's key, as it is
signed by Matt Domsch, whom I traded signatures with. That wasn't
very hard, and I don't even consider myself to be all that well
connected. :)
Are you going to meet face to face with them and exchange key
signatures?
Where possible, definitely. It's a nice excuse to meet some new
people and chat a little about geekery.
If rpm's key management doesn't handle signed keys..how do
you know
to trust their keys which signed the signature.
Very simple: by using gpg to look at the signatures on a key before
importing it. This is precisely how https://fedoraproject.org/keys
explains how to verify a key.
And on and on....all of it outside of the band of rpm.
And that's perfectly fine. Yes, it means that it isn't the sole
method that all users will use to establish trust in the new keys, but
it also isn't a method that takes much time at all (I refer only to
having Jesse and other rel-eng folks that were involved in generating
the key signing it, not having some other repository's key sign it).
You can take a look at the existing Fedora Project key at
pgp.mit.edu's search. It's been signed by 3rd parties. So some
individuals have signed the key. Do you trust them?
Most of them, no. In fact, those that have signed this key are folks
whose signatures now hold less weight with me since they were willing
to sign a key that they could not possibly have done much meaningful
verification on.
-jef"I should go ahead and sign the old key now, just because
it
doesn't matter"spaleta
Hopefully you understand gpg a little better than that and know that
signing a key you can't have verified just devalues the weight of your
signatures. ;)
And, just so it doesn't seem like I'm suggesting we require this as
part of the new key release plan, I must say that I do find publishing
the key's fingerprint at https://fedoraproject.org/keys to be enough
for me to establish trust in it. Adding a sig on the public key
servers from Jesse (and/or other rel-eng folks with access to it)
would simply be a nice bonus.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I expected times like this -- but never thought they'd be so bad, so
long, and so frequent.
-- Demotivators (www.despair.com)
5:41 p.m.
On Fri, Sep 5, 2008 at 2:08 PM, Todd Zullinger <tmz(a)pobox.com> wrote:
This would be excellent. (Though I would hate to ask Jesse to do
any
more work at this time. :)
Ah there's the rub. You want him to sign it..but you don't want to ask
him to sign it. You want someone like me to order him to sign it.
Check that list of signatories again for the old key at pgp.mit.edu.
Did Jesse ever sign the old key? If the answer was no... and you
trusted that key before...did you really need Jesse to sign the new
one to trust it now?
Tell me the name of the one person everyone is going to trust when
they sign the key. Is everyone going to trust Jesse? Really?
Everyone? If that were so, I think Jesse would have been the first
suggestion....not livna.
Most of them, no. In fact, those that have signed this key are
folks
whose signatures now hold less weight with me since they were willing
to sign a key that they could not possibly have done much meaningful
verification on.
How do you KNOW they didn't do any meaningful verification on it? How
do you KNOW that anyone does meaningful verification on any key before
they sign it? In the case of the original fedora signing key did you
call up each of those individuals and ask them? You have no idea if
they did or did not verify the key adequately. In fact you will have a
very hard time getting people to agree on what adequately means for a
signing key that is not attached to a human identity. Until you ask
them why they were comfortable signing the key you don't know if those
individuals are less trustworthy or not..and even then you have to
trust their answers. To trust any signature on any key you must make
assumptions on the actions of others.
What's even funnier is that you just admitted that the case of the
Fedora signing key your assumptions concerning other people's actions
decrease overall trust. Which is the exact opposite of what you want!
You want people to sign the key to increase trust..but you just stated
that having lots of people sign the previous key..means you assume
they didn't do it right and that you decrease trust in them instead of
increasing trust in the key. MADNESS.
You just admitted that the signing key is treated differently than a
normal gpg key because its not attached to an identity. And that's
sort of the point. The web-of-trust concept does not equally apply to
keys which are not strongly attached to a verifiable human identity.
The web-of-trust is illusionary for keys that are not strongly
attached to human identities.
-jef
8:09 p.m.
Jeff Spaleta wrote:
Ah there's the rub. You want him to sign it..but you don't
want to
ask him to sign it. You want someone like me to order him to sign
it.
Not at all. I did not ever ask you to ask Jesse. In fact, I did ask
him about it via IRC shortly after I sent my message. We'll see what
he says if he notices the message and has a moment. I'm not terribly
worried about it either way.
Check that list of signatories again for the old key at pgp.mit.edu.
Did Jesse ever sign the old key? If the answer was no... and you
trusted that key before...did you really need Jesse to sign the new
one to trust it now?
As I said in my previous message:
And, just so it doesn't seem like I'm suggesting we require this
as part of the new key release plan, I must say that I do find
publishing the key's fingerprint at https://fedoraproject.org/keys
to be enough for me to establish trust in it. Adding a sig on the
public key servers from Jesse (and/or other rel-eng folks with
access to it) would simply be a nice bonus.
Tell me the name of the one person everyone is going to trust when
they sign the key. Is everyone going to trust Jesse? Really?
Everyone? If that were so, I think Jesse would have been the first
suggestion....not livna.
1) I don't know where you get the idea that one person that everyone
trusts must sign the key for any signatures to be valid. That's not
what the web of trust if about.
2) I never suggested Livna sign the key because I don't believe anyone
at Livna has close enough access to the new key to provide any decent
verification of the key. In the case of a key that represents an
entity, the best place to start is with the individual(s) that have
access to the private key.
How do you KNOW they didn't do any meaningful verification on
it?
How do you KNOW that anyone does meaningful verification on any key
before they sign it?
IMO, the only people that can do meaningful verification of a key such
as the fedora signing key are those people that control the secret
key. Anyone else is simply taking their word for it (or piling on
with an "this is the same key I got elsewhere" sort of
"verification",
which means nothing to me).
To trust any signature on any key you must make assumptions on the
actions of others.
Right, and I use the past actions of those people as my guide. When
someone signs a key that I know they could not have properly verified
(since it isn't a human and could not have shown them an sort of ID),
then I choose not to trust those people's signatures.
What's even funnier is that you just admitted that the case of
the
Fedora signing key your assumptions concerning other people's
actions decrease overall trust. Which is the exact opposite of what
you want!
You lost me there Jeff. I think you may be reading things into my
words that I have not intended.
If Jesse Keating or other rel-eng folks with access to the private key
sign the key, it holds some weight as they are the folks that can
properly verify the key.
You want people to sign the key to increase trust..but you just
stated that having lots of people sign the previous key..means you
assume they didn't do it right and that you decrease trust in them
instead of increasing trust in the key. MADNESS.
Not madness at all. It's the basics of the OpenPGP trust model.
People that sign things without proper verification lose their
reputation as good signatories.
You just admitted that the signing key is treated differently than a
normal gpg key because its not attached to an identity. And that's
sort of the point. The web-of-trust concept does not equally apply
to keys which are not strongly attached to a verifiable human
identity. The web-of-trust is illusionary for keys that are not
strongly attached to human identities.
And the goal of having one of the humans that generated the key sign
it is to bring some level of the traditional web of trust back.
Again, with the key fingerprints being published on fedoraproject.org
and the keys available in public cvs, I think there are plenty of ways
to establish trust in the new keys. If they get signed by Jesse,
that's one more way that some of us can use. If they don't, I'm not
going to lose any sleep.
But no worry, I'm not asking you to do anything, so relax and have a
home brew. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If age imparted wisdom, there wouldn't be any old fools.
-- Claudia Young
11:17 p.m.
On Fri, Sep 5, 2008 at 5:09 PM, Todd Zullinger <tmz(a)pobox.com> wrote:
1) I don't know where you get the idea that one person that
everyone
trusts must sign the key for any signatures to be valid. That's not
what the web of trust if about.
Yes of course.. a chain of trust... i mispoke. Let me be more
deliberate. A single signature that everyone ends up trusting through
their own personal chains of trust. I don't really think one signature
is going to suffice for everyone who cares about this to the point of
requesting detected signatures be included with the key in the
package. If Jesse signs it and posts that signature to the key server
is that going to suffice for everyone who needs signature assurance?
Is Jesse really in everyone's web of trust?
If Jesse Keating or other rel-eng folks with access to the private
key
sign the key, it holds some weight as they are the folks that can
properly verify the key.
It only holds weight if those with signing authority with the key also
cross-sign their personal keys using the package signing key. The only
way to verify access to the key is to sign with the key. So for this
to mean anything at all, we'll need to get the people with signing
authority to sign their personal gpg key with the signing key as
well as sign the signing key with their personal key then submit
both signatures to a public keyserver for verification or you'll not
have any verifiable evidence that these people have access to the
signing key at all. God forbid you take my word for it that Jesse or
anyone else actually has signing authority. Without the
cross-signing, you are just taking our collective word for who has
access to the key. And there's no point in included the detached sigs
unless we also include the personal signing keys and the associated
cross-signatures. Again its just all more effectively done via public
keyserver operations. If you can wait for it, I can try to make sure
that the people with signing authority do the cross-signing with their
personal keys and public keyserver publishing. But its not going to
happen before the key is pushed out in the fedora-release package.
This is probably a good topic for the next scheduled rel-eng meeting
or FESCo meeting if it doesn't happen by then.
-jef
-jef
11:22 p.m.
On Fri, Sep 05, 2008 at 08:17:48PM -0800, Jeff Spaleta wrote:
On Fri, Sep 5, 2008 at 5:09 PM, Todd Zullinger <tmz(a)pobox.com>
wrote:
> 1) I don't know where you get the idea that one person that everyone
> trusts must sign the key for any signatures to be valid. That's not
> what the web of trust if about.
Yes of course.. a chain of trust... i mispoke. Let me be more
deliberate. A single signature that everyone ends up trusting through
their own personal chains of trust. I don't really think one signature
is going to suffice for everyone who cares about this to the point of
requesting detected signatures be included with the key in the
package. If Jesse signs it and posts that signature to the key server
is that going to suffice for everyone who needs signature assurance?
Is Jesse really in everyone's web of trust?
I don't normally read this list, so pardon the late comment.
I feel that posting the new package signing key information far and
wide is a fine method to distribute it, and additional signatures on
it are not strictly necessary. However, if it would help smooth
adoption, I'd be happy to trade signatures with anyone who is in a
position to sign the new package signing key (for obvious reasons, I
cannot sign it myself).
I'm one of the GnuPG developers, and as such, a copy of my key is in
/usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has
gnupg-1.4 installed. It's a key that many (most?) Fedora users
already have, and had before this current problem even started. This
doesn't mean people should necessarily trust my key, of course, but it
does serve as a pretty effective pre-distributed key that can be
leveraged for this as its very wide distribution would make it
difficult to replace out from under someone without the mischief being
very visible (much the same argument that also holds for the new
package signing key, of course, except that my key is already widely
distributed).
As luck has it, I work around half an hour away from the Red Hat
Massachusetts office.
David
6:07 a.m.
On 09/09/2008, David Shaw <dshaw(a)jabberwocky.com> wrote:
I'm one of the GnuPG developers, and as such, a copy of my key
is in
/usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has
gnupg-1.4 installed. It's a key that many (most?) Fedora users
already have, and had before this current problem even started. This
doesn't mean people should necessarily trust my key, of course, but it
does serve as a pretty effective pre-distributed key that can be
leveraged for this as its very wide distribution would make it
difficult to replace out from under someone without the mischief being
very visible (much the same argument that also holds for the new
package signing key, of course, except that my key is already widely
distributed).
As luck has it, I work around half an hour away from the Red Hat
Massachusetts office.
Now that, seems like a really good idea :o)
How about you sign, e.g. Jesse's key (if he's willing)?
David
Bill
10:08 a.m.
On Tue, Sep 09, 2008 at 12:07:36PM +0100, Bill Crawford wrote:
On 09/09/2008, David Shaw <dshaw(a)jabberwocky.com> wrote:
> I'm one of the GnuPG developers, and as such, a copy of my key is in
> /usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has
> gnupg-1.4 installed. It's a key that many (most?) Fedora users
> already have, and had before this current problem even started. This
> doesn't mean people should necessarily trust my key, of course, but it
> does serve as a pretty effective pre-distributed key that can be
> leveraged for this as its very wide distribution would make it
> difficult to replace out from under someone without the mischief being
> very visible (much the same argument that also holds for the new
> package signing key, of course, except that my key is already widely
> distributed).
>
> As luck has it, I work around half an hour away from the Red Hat
> Massachusetts office.
Now that, seems like a really good idea :o)
How about you sign, e.g. Jesse's key (if he's willing)?
I'm happy to exchange signatures with Jesse or anyone else in the
Boston area.
To be clear, though: I don't want to give the impression that I think
the release plan is not sufficient. I think it's about as good as it
can be given the facts of how RPM does key management. Any additional
signatures on the package signing key are just a nice bonus for those
who want to do additional checks.
David
12:07 p.m.
On Tue, Sep 9, 2008 at 7:08 AM, David Shaw <dshaw(a)jabberwocky.com> wrote:
I'm happy to exchange signatures with Jesse or anyone else in
the
Boston area.
Who said Jesse was in the Boston area?
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00228...
-jef
1:29 p.m.
On 09/09/2008, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Tue, Sep 9, 2008 at 7:08 AM, David Shaw
<dshaw(a)jabberwocky.com> wrote:
> I'm happy to exchange signatures with Jesse or anyone else in the
> Boston area.
Who said Jesse was in the Boston area?
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00228...
Probably my fault, I merely suggested that if he were able to sign
keys, signing Jesse's would provide a short path from there to the new
signing keys. Sorry :o)
6:08 a.m.
I scanned this thread and was a bit disappointed. Lots of apparently
competent people arguing from false assumptions.
None of you know me from Adam. If we met at a key-signing party, you
would have no reason to trust this guy with an odd scare and a week's
growth of whiskers on his face. Face to face is only useful if the
face matches a familiar pattern.
Shoot, I know most of you better from the patterns in your posts than
I would know you if we met face to face.
You could show me your passport and other ID (including the
electronic ones), and I would still know more about you from the
patterns of your posts on the list.
In the real world, if Jack Smack comes up to me and tells me my
cousin is introducing him, I check with my cousin, and I still don't
really trust him until I get to know him. Dorothy Developer who is an
acquaintance of a friend of a developer known by a couple of guys I
met at the last Linux conference I attended has an advantage in
numbers, but I still don't trust her programming until I have run her
stuff a couple of times. And checked my logs
Chain of trust is an illusion. So is a web of trust.
What I do have is a running OS and log files in my firewalls. And
memories of domain names I have surfed by.
That the keys posted on the mirrors and the main site match is good
evidence of a number of people cooperating. That is why I trust the
keys enough to try the OS, and I could trust them no more were they
to be signed by someone chained back to verisign or whoever.
Speaking of verisign, trusting a single entity as a "root of trust"
is not far removed from trusting some charismatic religious or
philosophical type to be your moral root. The CAs can serve a
purpose, but they tend to be used against that purpose more than for.
The best use of the keys is as a checksum. Isn't that clear?
Joel Rees
8:24 a.m.
On Wed, 2008-09-03 at 23:42 -0400, Bill Davidsen wrote:
Patrick O'Callaghan wrote:
> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>> hardest of all find a secure way to provide the public part of the
>> signing key
>
> The whole point about asymmetric encryption is that you don't need a
> secure distribution channel. The worst that can happen is that some fake
> public key gets distributed, which won't match the private key and hence
> will be instantly detectable.
>
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.
And packages signed with any valid redhat key would be
rejected.
Which is what I said. Thus it would be noticed immediately.
The public key really must be distributed in a secure manner.
The standard way is to use certificates, but the update process isn't
set up for this AFAIK, and in any case certificates have to be
signed ... I'm sure suggestions are welcome as to how to accomplish
this.
poc
10:12 a.m.
Patrick O'Callaghan wrote:
--
You have had a long-term stimulation relative to business.
> 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.
> 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.
10:29 a.m.
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
11:05 a.m.
On Thu, Sep 4, 2008 at 8:29 AM, Patrick O'Callaghan
<pocallaghan(a)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
4:06 p.m.
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(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
7:02 p.m.
Patrick O'Callaghan wrote:
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 is an extremely unlikely possibility as you have to generate a key
with the same key id (fingerprint)as the original. Also, you have to
determine how to trick all users in to replacing the original.
--
Necessity is a mother.
8:26 p.m.
On Fri, 2008-09-05 at 08:02 +0800, Ed Greshko wrote:
Patrick O'Callaghan wrote:
>
> 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 is an extremely unlikely possibility as you have to generate a key
with the same key id (fingerprint)as the original. Also, you have to
determine how to trick all users in to replacing the original.
Exactly. That's what I've been saying all along. I don't understand what
the disagreement is about, if anything.
poc
9:03 a.m.
Ed Greshko wrote:
Patrick O'Callaghan wrote:
> 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 is an extremely unlikely possibility as you have to generate a key
with the same key id (fingerprint)as the original. Also, you have to
determine how to trick all users in to replacing the original.
All users? This is like spam email, you only need to succeed in a few
cases to get benefit. And distributing the fingerprint assumes you can
do that securely as well.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
11:43 a.m.
Bill Davidsen wrote:
Ed Greshko wrote:
> Patrick O'Callaghan wrote:
>> 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 is an extremely unlikely possibility as you have to generate a key
> with the same key id (fingerprint)as the original. Also, you have to
> determine how to trick all users in to replacing the original.
All users? This is like spam email, you only need to succeed in a few
cases to get benefit. And distributing the fingerprint assumes you can
do that securely as well.
I think you have no concept of public/private encryption or signing.
--
Behind every great computer sits a skinny little geek.
3:44 p.m.
Ed Greshko wrote:
Bill Davidsen wrote:
> Ed Greshko wrote:
>> Patrick O'Callaghan wrote:
>>> 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 is an extremely unlikely possibility as you have to generate a key
>> with the same key id (fingerprint)as the original. Also, you have to
>> determine how to trick all users in to replacing the original.
> All users? This is like spam email, you only need to succeed in a few
> cases to get benefit. And distributing the fingerprint assumes you can
> do that securely as well.
>
I think you have no concept of public/private encryption or signing.
My concept is that if I can fool you into accepting a false public key,
I can sign packages with the matching false private key, and when you
install the first such package it may (probably will) include evil
things of some nature.
Do you disagree? Or feel that if I can get you to run one evil package I
can't put in a root kit, or rend personal information from your systems,
or otherwise attack your system?
If you feel that line of attack is not possible do tell me how your
concept of encryption and signing prevents it.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
2:43 a.m.
Bill Davidsen wrote:
Ed Greshko wrote:
> Bill Davidsen wrote:
>> Ed Greshko wrote:
>>> Patrick O'Callaghan wrote:
>>>> 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 is an extremely unlikely possibility as you have to generate a
>>> key
>>> with the same key id (fingerprint)as the original. Also, you have to
>>> determine how to trick all users in to replacing the original.
>> All users? This is like spam email, you only need to succeed in a few
>> cases to get benefit. And distributing the fingerprint assumes you can
>> do that securely as well.
>>
> I think you have no concept of public/private encryption or signing.
>
My concept is that if I can fool you into accepting a false public
key, I can sign packages with the matching false private key, and when
you install the first such package it may (probably will) include evil
things of some nature.
Do you disagree? Or feel that if I can get you to run one evil package
I can't put in a root kit, or rend personal information from your
systems, or otherwise attack your system?
If you feel that line of attack is not possible do tell me how your
concept of encryption and signing prevents it.
I thought you were talking "real world" as opposed to purely
hypothetical.
--
"I am your density." -- George McFly in "Back to the Future"
4:03 p.m.
Ed Greshko wrote:
>> I think you have no concept of public/private encryption or
signing.
>>
> My concept is that if I can fool you into accepting a false public
> key, I can sign packages with the matching false private key, and when
> you install the first such package it may (probably will) include evil
> things of some nature.
>
> Do you disagree? Or feel that if I can get you to run one evil package
> I can't put in a root kit, or rend personal information from your
> systems, or otherwise attack your system?
>
> If you feel that line of attack is not possible do tell me how your
> concept of encryption and signing prevents it.
>
I thought you were talking "real world" as opposed to purely hypothetical.
I think it is a reasonable real world assumption that some users could
have their DNS compromised in a way that would make them pull packages
from somewhere other than the official repositories. Can any key trust
scenario where they have to obtain a new key protect against installing
modified packages? (i.e. assume that the fake key and packages come from
the same place(s) pretending to be the official repositories and mirrors).
--
Les Mikesell
lesmikesell(a)gmail.com
6:01 p.m.
Les Mikesell wrote:
Ed Greshko wrote:
>
>>> I think you have no concept of public/private encryption or signing.
>>>
>> My concept is that if I can fool you into accepting a false public
>> key, I can sign packages with the matching false private key, and when
>> you install the first such package it may (probably will) include evil
>> things of some nature.
>>
>> Do you disagree? Or feel that if I can get you to run one evil package
>> I can't put in a root kit, or rend personal information from your
>> systems, or otherwise attack your system?
>>
>> If you feel that line of attack is not possible do tell me how your
>> concept of encryption and signing prevents it.
>>
> I thought you were talking "real world" as opposed to purely
> hypothetical.
I think it is a reasonable real world assumption that some users could
have their DNS compromised in a way that would make them pull packages
from somewhere other than the official repositories. Can any key
trust scenario where they have to obtain a new key protect against
installing modified packages? (i.e. assume that the fake key and
packages come from the same place(s) pretending to be the official
repositories and mirrors).
It would be very nice if someone would fully define what they mean by
the very vague term "fake key".
--
It is now 10 p.m. Do you know where Henry Kissinger is? -- Elizabeth
Carpenter
6:07 p.m.
Ed Greshko wrote:
It would be very nice if someone would fully define what they mean by
the very vague term "fake key".
And along with that, define the method used to distribute said key in a
manner that would be oblivious to the all end users. It has to be
oblivious to all end users such that nobody would be able to raise an
alarm in a reasonable amount of time.
If the public/private key methods employed today are as easy to
penetrate and subvert as some seem to be claiming then one has to
question why it hasn't already been done.
--
Gravity brings me down.
7:03 p.m.
Ed Greshko wrote:
Ed Greshko wrote:
> It would be very nice if someone would fully define what they mean by
> the very vague term "fake key".
>
In this context it would one that a user would install that was not the
one officially created for the packages in the fedora repository.
And along with that, define the method used to distribute said key in
a
manner that would be oblivious to the all end users.
It doesn't have to fool all the end users, just you. Or someone with
content worth stealing, or on a network worth penetrating.
It has to be
oblivious to all end users such that nobody would be able to raise an
alarm in a reasonable amount of time.
What's a reasonable amount of time? A victim would notice if/when they
manage to get an official RPM that the key doesn't match (unless their
subverted packages remove the check) and might or might not do something
besides import the correct key.
If the public/private key methods employed today are as easy to
penetrate and subvert as some seem to be claiming then one has to
question why it hasn't already been done.
It's not easy to fool everyone. The question is whether there is a way
to start from scratch so you can't fool anyone.
--
Les Mikesell
lesmikesell(a)gmail.com
7:22 p.m.
Les Mikesell wrote:
Ed Greshko wrote:
> Ed Greshko wrote:
>> It would be very nice if someone would fully define what they mean by
>> the very vague term "fake key".
>>
In this context it would one that a user would install that was not
the one officially created for the packages in the fedora repository.
In other
words, you don't know how to define what a "fake key" is....so
just avoid it and pretend.
> And along with that, define the method used to distribute said key in a
> manner that would be oblivious to the all end users.
It doesn't have to fool all the end users, just you. Or someone with
content worth stealing, or on a network worth penetrating.
So, the target is
"one" system.
> It has to be
> oblivious to all end users such that nobody would be able to raise an
> alarm in a reasonable amount of time.
What's a reasonable amount of time? A victim would notice if/when
they manage to get an official RPM that the key doesn't match (unless
their subverted packages remove the check) and might or might not do
something besides import the correct key.
More "ifs".
> If the public/private key methods employed today are as easy to
> penetrate and subvert as some seem to be claiming then one has to
> question why it hasn't already been done.
It's not easy to fool everyone. The question is whether there is a
way to start from scratch so you can't fool anyone.
And, it is even less easy to "fool" the people whose networks have
something worth stealing....
Why go through the laughingly improbably scenario of attempting to
subvert the public/private key infrastructure with the potential need
need to simultaneously subvert DNS infrastructure on a single target
when there are already other much more simple attack vectors?
Oh, and to answer your question...."Is there a way to design a system so
you can't fool anyone?" Absolutely not.
--
Do YOU have redeeming social value?
7:50 p.m.
Ed Greshko wrote:
> It's not easy to fool everyone. The question is whether there is a
> way to start from scratch so you can't fool anyone.
>
And, it is even less easy to "fool" the people whose networks have
something worth stealing....
And yet it happens regularly.
Why go through the laughingly improbably scenario of attempting to
subvert the public/private key infrastructure with the potential need
need to simultaneously subvert DNS infrastructure on a single target
when there are already other much more simple attack vectors?
What's the point of having the key at all if you implicitly trust the
delivery mechanism of the RPM packages?
--
Les Mikesell
lesmikesell(a)gmail.com
7:53 p.m.
Les Mikesell wrote:
Ed Greshko wrote:
>
>> It's not easy to fool everyone. The question is whether there is a
>> way to start from scratch so you can't fool anyone.
>>
> And, it is even less easy to "fool" the people whose networks have
> something worth stealing....
And yet it happens regularly.
By a much much more simple approach.
> Why go through the laughingly improbably scenario of attempting to
> subvert the public/private key infrastructure with the potential need
> need to simultaneously subvert DNS infrastructure on a single target
> when there are already other much more simple attack vectors?
What's the point of having the key at all if you implicitly trust the
delivery mechanism of the RPM packages?
Good approach, answer a question with
another question.
--
Within a computer, natural language is unnatural.
8:22 p.m.
Ed Greshko wrote:
> What's the point of having the key at all if you implicitly trust the
> delivery mechanism of the RPM packages?
Good approach, answer a question with another question.
If you can't say why you need the key in the first place, there isn't
much hope of seeing why you need a different reason to trust the key
than the content it verifies.
--
Les Mikesell
lesmikesell(a)gmail.com
8:34 p.m.
Les Mikesell wrote:
Ed Greshko wrote:
>
>> What's the point of having the key at all if you implicitly trust the
>> delivery mechanism of the RPM packages?
> Good approach, answer a question with another question.
>
If you can't say why you need the key in the first place, there isn't
much hope of seeing why you need a different reason to trust the key
than the content it verifies.
Bzzzzttt... Wong! You are attacking the current system and it is
incumbent on you to prove your points.
I can't help but to see the irony in that those clamoring for "explicit
details" from the Fedora folks as to the nature, methods, damage
inflicted on the Fedora infrastructure are so devoid of details on how
their attack vector would work. Their scenario amounts to...generate a
fake key pair, fool people in accepting it, sign compromised packages,
fool people into downloading and installing them...take over their systems.
<comic aside>
There is a much easier way to achieve the above. Trick people into
installing Microsoft products.
</comic aside.
--
The onset and the waning of love make themselves felt in the uneasiness
experienced at being alone together. -- Jean de la Bruyere
10:12 p.m.
Ed Greshko wrote:
>>> What's the point of having the key at all if you implicitly trust the
>>> delivery mechanism of the RPM packages?
>> Good approach, answer a question with another question.
>>
> If you can't say why you need the key in the first place, there isn't
> much hope of seeing why you need a different reason to trust the key
> than the content it verifies.
>
Bzzzzttt... Wong! You are attacking the current system and it is
incumbent on you to prove your points.
I'm not sure there is a 'current system', but if you mean the plan to
use the old key validation for the installation of a package containing
the new one and the new repo locations, I don't have a better suggestion.
I can't help but to see the irony in that those clamoring for
"explicit
details" from the Fedora folks as to the nature, methods, damage
inflicted on the Fedora infrastructure are so devoid of details on how
their attack vector would work. Their scenario amounts to...generate a
fake key pair, fool people in accepting it, sign compromised packages,
fool people into downloading and installing them...take over their systems.
I'm sure there are people capable of that - but in the planned scenario
the same person has to also possess the old signing key.
--
Les Mikesell
lesmikesell(a)gmail.com
7:27 p.m.
Ed Greshko wrote:
Ed Greshko wrote:
> It would be very nice if someone would fully define what they mean by
> the very vague term "fake key".
>
I think most of us would mean a key created by someone not part of the
Fedora project, and which is intended to convince users that it is, in
fact, a key created and distributed by the Fedora project and used to
sign official releases.
I speak only for me, of course.
And along with that, define the method used to distribute said key in
a
manner that would be oblivious to the all end users. It has to be
oblivious to all end users such that nobody would be able to raise an
alarm in a reasonable amount of time.
Here we disagree. That's like saying that spam has to fool all readers
to be worth doing. If an unauthorized key is used to cause users to
install unauthorized software, then it has achieved its purpose. Note
that the purpose is yet unclear, and may not exist, but once such an
install takes place it could fo any or all of the following:
- steal information from a user system
- use the user system to run untrusted executables (or any kind)
- damage the reputation of Fedora and Red Hat
- damage the reputation and user trust of Linux in general
for the purpose of reducing use of Linux vs. other operating systems
I rate the first two as likely, the third as a possible effect even if
unintended, and the last as another possible effect, which might be
intended.
If the public/private key methods employed today are as easy to
penetrate and subvert as some seem to be claiming then one has to
question why it hasn't already been done.
It has already been proved to be possible, so discussion of how easy it
is or way is irrelevant, at least to me.
The new public key could be distributed from the master Red Hat servers,
not from mirrors, which would allow validation of the content by the
validity of the SSL certificate. Once a trusted signature is available,
all other packages, from mirror or torrent, could be properly validated.
While this is inconvenient, it is also as secure as the original, and
not readily vulnerable to attacks in the distribution, since middlemen
are not involved. And once the key is out for a few days, and many users
have it and can quickly compare it to any other key distributed by other
means, then it can be sent out in a more convenient manner if people
really feel the need to trade some security for ease of use.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
7:43 p.m.
Bill Davidsen wrote:
>
> If the public/private key methods employed today are as easy to
> penetrate and subvert as some seem to be claiming then one has to
> question why it hasn't already been done.
>
It has already been proved to be possible, so discussion of how easy
it is or way is irrelevant, at least to me.
??? It has? So, what was done? Was
the signing key of Fedora
compromised? Was a replacement key public key generated and
distributed? Were packages signed by the replacement key distributed?
What was "proven".
The new public key could be distributed from the master Red Hat
servers, not from mirrors, which would allow validation of the content
by the validity of the SSL certificate. Once a trusted signature is
available, all other packages, from mirror or torrent, could be
properly validated.
"Could"...how?
While this is inconvenient, it is also as secure as the original, and
not readily vulnerable to attacks in the distribution, since middlemen
are not involved. And once the key is out for a few days, and many
users have it and can quickly compare it to any other key distributed
by other means, then it can be sent out in a more convenient manner if
people really feel the need to trade some security for ease of use.
A whole bunch of people are wringing their hands over nothing. I
suppose if you want to continue doing that that is your choice.
The strange things is that none of this would have come up if the
servers of Fedora hadn't been penetrated by some method which nobody on
this list is privy to...but can spend endless hours on idle speculation
and fear mongering.
[WOT comment] I suspect that those fear peddlers, if located in the US,
will also be voting for the Republican candidate. :-)
--
Some people's mouths work faster than their brains. They say things they
haven't even thought of yet.
8:46 p.m.
Ed Greshko wrote:
Bill Davidsen wrote:
>> If the public/private key methods employed today are as easy to
>> penetrate and subvert as some seem to be claiming then one has to
>> question why it hasn't already been done.
>>
> It has already been proved to be possible, so discussion of how easy
> it is or way is irrelevant, at least to me.
??? It has? So, what was done? Was the signing key of Fedora
compromised? Was a replacement key public key generated and
distributed? Were packages signed by the replacement key distributed?
What was "proven".
What was done was to breach security to the extent that new keys are
prudent, and in a way that may not be quantifyable. The action on the
RHEL side indicates that a bogus ssh package may have been distributed.
I encourage you to read the announcements and see if my interpretation
is not correct. A new ssh package was released "just in case," which is
good procedure.
> The new public key could be distributed from the master Red Hat
> servers, not from mirrors, which would allow validation of the content
> by the validity of the SSL certificate. Once a trusted signature is
> available, all other packages, from mirror or torrent, could be
> properly validated.
"Could"...how?
Sorry, I thought you understood how signing works. Once a user has a
trusted "new" public key, it can be used to check the signing on any new
packages. The current distribution has the ability to do this, limited
by the correctness of the public key.
Note that if your system is compromised, this isn't going to be safe,
many things could be faking correct operation. You can go back to the
original install media and start over depending on your evaluation of
exposure. Since Fedora hasn't provided a date before which packages were
known to be trusted, I can't say if any updates past the install media
are safe, but since they are still available I assume that's the case.
> While this is inconvenient, it is also as secure as the original,
and
> not readily vulnerable to attacks in the distribution, since middlemen
> are not involved. And once the key is out for a few days, and many
> users have it and can quickly compare it to any other key distributed
> by other means, then it can be sent out in a more convenient manner if
> people really feel the need to trade some security for ease of use.
>
A whole bunch of people are wringing their hands over nothing. I
suppose if you want to continue doing that that is your choice.
Do you personally warrant that there is no problem, and that you will
make good any damage if you're wrong, and that you have the resources to
do so? Didn't think so, so it isn't nothing, it's a low probability risk
which can be reduced by securely distributing the new public key.
The strange things is that none of this would have come up if the
servers of Fedora hadn't been penetrated by some method which nobody on
this list is privy to...but can spend endless hours on idle speculation
and fear mongering.
[WOT comment] I suspect that those fear peddlers, if located in the US,
will also be voting for the Republican candidate. :-)
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
9:04 p.m.
Bill Davidsen wrote:
Ed Greshko wrote:
> Bill Davidsen wrote:
>
>
>>> If the public/private key methods employed today are as easy to
>>> penetrate and subvert as some seem to be claiming then one has to
>>> question why it hasn't already been done.
>>>
>> It has already been proved to be possible, so discussion of how easy
>> it is or way is irrelevant, at least to me.
> ??? It has? So, what was done? Was the signing key of Fedora
> compromised? Was a replacement key public key generated and
> distributed? Were packages signed by the replacement key distributed?
> What was "proven".
What was done was to breach security to the extent that new keys are
prudent, and in a way that may not be quantifyable. The action on the
RHEL side indicates that a bogus ssh package may have been
distributed. I encourage you to read the announcements and see if my
interpretation is not correct. A new ssh package was released "just in
case," which is good procedure.
Which may simply be good practice to keep
people from asking "what if"
and to satisfy the masses.
If RH/Fedora was to determine that nothing was compromised and that new
keys were not necessary they would have a similar problem in that some
contingent would claim RH/Fedora was lying to them. It could be (note I
am as well informed as you are as to what actually occurred) they are
picking their poison, choosing between 2 bad choices. Damned if they
do, damned if they don't.
>
>> The new public key could be distributed from the master Red Hat
>> servers, not from mirrors, which would allow validation of the content
>> by the validity of the SSL certificate. Once a trusted signature is
>> available, all other packages, from mirror or torrent, could be
>> properly validated.
> "Could"...how?
Sorry, I thought you understood how signing works. Once a user has a
trusted "new" public key, it can be used to check the signing on any
new packages. The current distribution has the ability to do this,
limited by the correctness of the public key.
You have given zero details (and it
has to be detailed and plausible) as
to how you go about distributing and having the key installed. You
don't say how this "fake-trusted" key will interact with previously
signed packages. Along those lines, you've not indicated if this
"fake-trusted" key will replace or coexist with the current public key.
Note that if your system is compromised, this isn't going to be
safe,
many things could be faking correct operation. You can go back to the
original install media and start over depending on your evaluation of
exposure. Since Fedora hasn't provided a date before which packages
were known to be trusted, I can't say if any updates past the install
media are safe, but since they are still available I assume that's the
case.
>> While this is inconvenient, it is also as secure as the original, and
>> not readily vulnerable to attacks in the distribution, since middlemen
>> are not involved. And once the key is out for a few days, and many
>> users have it and can quickly compare it to any other key distributed
>> by other means, then it can be sent out in a more convenient manner if
>> people really feel the need to trade some security for ease of use.
>>
> A whole bunch of people are wringing their hands over nothing. I
> suppose if you want to continue doing that that is your choice.
Do you personally warrant that there is no problem, and that you will
make good any damage if you're wrong, and that you have the resources
to do so? Didn't think so, so it isn't nothing, it's a low probability
risk which can be reduced by securely distributing the new public key.
I personally
am losing "zero" sleep over this non issue. I personally
don't give a darn if RH/Fedora releases a new public key or not.
--
Why does New Jersey have more toxic waste dumps and California have more
lawyers? New Jersey had first choice.
1:56 a.m.
From: "Patrick O'Callaghan" <pocallaghan(a)gmail.com>
Sent: Thursday, 2008, September 04 06:24
On Wed, 2008-09-03 at 23:42 -0400, Bill Davidsen wrote:
> Patrick O'Callaghan wrote:
> > On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
> >> hardest of all find a secure way to provide the public part of the
> >> signing key
> >
> > The whole point about asymmetric encryption is that you don't need a
> > secure distribution channel. The worst that can happen is that some
> > fake
> > public key gets distributed, which won't match the private key and
> > hence
> > will be instantly detectable.
> >
> 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.
> And packages signed with any valid redhat key would be
> rejected.
Which is what I said. Thus it would be noticed immediately.
> The public key really must be distributed in a secure manner.
The standard way is to use certificates, but the update process isn't
set up for this AFAIK, and in any case certificates have to be
signed ... I'm sure suggestions are welcome as to how to accomplish
this.
poc
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
If this can be done once in an initial install situation it can be done
again in an update situation using the same mechanism.
{^_^}
2:50 a.m.
* jdow <jdow(a)earthlink.net> [20080905 08:56]:
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
Once you have installed the system - the updates you are pulling down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
The part about how to distribute the new public key - that is the
thing that the infrastructure team is debating how to best do now.
Nitpicking - it is spelled "Red Hat".
If this can be done once in an initial install situation it can be
done
again in an update situation using the same mechanism.
{^_^}
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
If you decide not to trust passports, you will simply find it a bit
hard to travel from country to country. If you don't trust the Fedora
key, you'll find it a bit hard to use Fedora.
My view of the Fedora public key is that it is a means to verify the
integrity of the packages coming from the Fedora repo's. That the
package is originating from Fedora, and not from untrusted 3rd
party and that the packages have not been tampered with in
mid-flight. If you don't trust the method by which packages are
downloaded, verified and installed by yum - maybe you'd trust going to
the Fedora download site and grabbing the packages, one by one, and
installing them by hand?
This is a potential solution actually. If you don't trust https:// to
the download section of Fedora - you don't trust Fedora full stop. So
providing a page with the new key, and instruction for what to change
and how, on your system to point at the new repo's should satisfy even
the most paranoid people on this list. As the packages are signed with
the new key, and if you remove the old key - you should be OK. Right?
Yes - it requires manual interaction, it'll be a PITA etc etc ad
nauseum. You have a better, more trustworthy idea? Let's hear it.
/Anders
9:22 a.m.
Anders Karlsson wrote:
* jdow <jdow(a)earthlink.net> [20080905 08:56]:
> Suppose I have NO RedHat installed. I have no working computer near
> me. I want to install Fedora 9. How do I establish the ability to
> subject the packages to tests for being properly signed, that the
> key used in the test is correct, and that I am reading and updating
> from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
And here you bring out a good point, most users probably download an
image and create the media themselves. Assuming that you get the sha1sum
from a trusted source *and use it*, you are probably as safe doing that
as buying from a DVD house and using that, or going to an install-a-thon
and having a perfect stranger install software on your system. Having
been the installer a few times, perhaps people could question me,
although no one has.
Once you have installed the system - the updates you are pulling down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
The part about how to distribute the new public key - that is the
thing that the infrastructure team is debating how to best do now.
Nitpicking - it is spelled "Red Hat".
> If this can be done once in an initial install situation it can be done
> again in an update situation using the same mechanism.
>
> {^_^}
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
If you decide not to trust passports, you will simply find it a bit
hard to travel from country to country. If you don't trust the Fedora
key, you'll find it a bit hard to use Fedora.
My view of the Fedora public key is that it is a means to verify the
integrity of the packages coming from the Fedora repo's. That the
package is originating from Fedora, and not from untrusted 3rd
party and that the packages have not been tampered with in
mid-flight. If you don't trust the method by which packages are
downloaded, verified and installed by yum - maybe you'd trust going to
the Fedora download site and grabbing the packages, one by one, and
installing them by hand?
This is a potential solution actually. If you don't trust https:// to
the download section of Fedora - you don't trust Fedora full stop. So
providing a page with the new key, and instruction for what to change
and how, on your system to point at the new repo's should satisfy even
the most paranoid people on this list. As the packages are signed with
the new key, and if you remove the old key - you should be OK. Right?
Actually, I would think that just distributing a single RPM package that
way, containing the new key, would be preferable to getting it through
the yum distribution channel, at least from my point of view. Then the
yum channel would become trusted again.
Yes - it requires manual interaction, it'll be a PITA etc etc ad
nauseum. You have a better, more trustworthy idea? Let's hear it.
Actually I assumed that distribution directly from the Fedora servers
had been impractical or even insecure for some reason, which is why I
have proposed alternative ideas. It crossed my mind that the SSL certs
might have been compromised as well.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
1:51 p.m.
From: "Anders Karlsson" <anders(a)trudheim.co.uk>
Sent: Friday, 2008, September 05 00:50
* jdow <jdow(a)earthlink.net> [20080905 08:56]:
> Suppose I have NO RedHat installed. I have no working computer near
> me. I want to install Fedora 9. How do I establish the ability to
> subject the packages to tests for being properly signed, that the
> key used in the test is correct, and that I am reading and updating
> from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
Where did I get the media? How do I establish the chain of trust?
Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
around. If trust can be established from zero then it can happen
again.
Once you have installed the system - the updates you are pulling
down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
If I am actually going to the right mirrors and not a setup of fast
flux servers full of malware that will be true.
The part about how to distribute the new public key - that is the
thing that the infrastructure team is debating how to best do now.
Nitpicking - it is spelled "Red Hat".
And I'd be likely installing Fedora these days.
> If this can be done once in an initial install situation it can
be done
> again in an update situation using the same mechanism.
>
> {^_^}
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
Exactly. This is the point. If I can proceed from zero and establish
trust once I can do it again. So I am unclear over what the problem
in that regard can be such that it would stall the process of getting
rolling again.
I can see other items causing a hitch in the gitalong. But I cannot
see any means other than trusting my DNS server and the routers
between download.fedora.redhat.com and me. If I could trust them once
I can trust them again. So the focus of this thread is wrong. It
should be more along the lines of "How can a company that uses RPM
and signed packages arrange to have the packages multiply signed so
that both an old obsolete key works and a new key works?"
THAT is probably not a simple problem. I also suspect it is not something
considered in designing rpm itself or the distribution system.
If you decide not to trust passports, you will simply find it a bit
hard to travel from country to country. If you don't trust the Fedora
key, you'll find it a bit hard to use Fedora.
My view of the Fedora public key is that it is a means to verify the
integrity of the packages coming from the Fedora repo's. That the
package is originating from Fedora, and not from untrusted 3rd
party and that the packages have not been tampered with in
mid-flight. If you don't trust the method by which packages are
downloaded, verified and installed by yum - maybe you'd trust going to
the Fedora download site and grabbing the packages, one by one, and
installing them by hand?
This is a potential solution actually. If you don't trust https:// to
the download section of Fedora - you don't trust Fedora full stop. So
providing a page with the new key, and instruction for what to change
and how, on your system to point at the new repo's should satisfy even
the most paranoid people on this list. As the packages are signed with
the new key, and if you remove the old key - you should be OK. Right?
Personally I trust the connection between me and Red Hat or me and
Fedora - effectively the same thing. Tampering would have to be quite
comprehensive to keep me fooled for long enough to make it worth the
cracker's efforts. DNS is the easiest hole in the picture. And that
means the main root name servers would have to be changed. (I am being
a bad girl at the moment and am using them directly. I switched pending
hearing that DSLExtreme had completed their update. I've had other things
more pressing to do than change it back.) The second level hole is the
man in the middle attacking me specifically. "They ARE out to get me. But
it is nothing personal." It's not me specifically they are targeting. It's
people who present themselves as targets of opportunity. The attack in
this case would have to be so comprehensive that it beggars the imagination
for it to hold up past the first attempted update cycle.
If trust can be established once, it can be establised again the same way
as many times as needed. So the discussion needs to move to what may be
the REAL problem. Can an rpm be signed with multiple keys in any
meaningful way so that people pre-update can still grab the key updates
and compare files prior to a specific date against the old key while new
files compare against the new key.
If THAT can be done it seems like both this discussion and the delay
are somewhat spurious, right?
{^_-}
3:12 p.m.
* jdow <jdow(a)earthlink.net> [20080905 20:52]:
From: "Anders Karlsson" <anders(a)trudheim.co.uk>
Sent: Friday, 2008, September 05 00:50
> * jdow <jdow(a)earthlink.net> [20080905 08:56]:
>> Suppose I have NO RedHat installed. I have no working computer near
>> me. I want to install Fedora 9. How do I establish the ability to
>> subject the packages to tests for being properly signed, that the
>> key used in the test is correct, and that I am reading and updating
>> from a legitimate mirror?
>
> In this event you are likely installing from physical media, which
> will have the public key on it already. If you do not trust that media
> - why are you installing from it?
Where did I get the media? How do I establish the chain of trust?
Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
around. If trust can be established from zero then it can happen
again.
You had no OS installed - so where did you get the media from?
The only thing that matters at this point is whether you do, or not,
trust the media you are installing from? If you do - then you will
have a good key on the media that will validate updates later.
> Once you have installed the system - the updates you are pulling
down
> will be verified with the key that was on the media - unless you
> actively go and switch off the gpg checking.
If I am actually going to the right mirrors and not a setup of fast
flux servers full of malware that will be true.
Mu.
The Fedora installation media installs repo configs that point to the
Fedora projects servers. Your comment indicates that you believe your
ISP and the DNS servers you use are compromised. At this point - all
bets are off.
> As others have already pointed out - it's a question of
trust. At some
> point or other - you have to decide what you trust. If you do not
> trust something, do not use it (and then live with the consequences of
> that choice).
Exactly. This is the point. If I can proceed from zero and establish
trust once I can do it again. So I am unclear over what the problem
in that regard can be such that it would stall the process of getting
rolling again.
I can see other items causing a hitch in the gitalong. But I cannot
see any means other than trusting my DNS server and the routers
between download.fedora.redhat.com and me. If I could trust them once
I can trust them again. So the focus of this thread is wrong. It
should be more along the lines of "How can a company that uses RPM
and signed packages arrange to have the packages multiply signed so
that both an old obsolete key works and a new key works?"
THAT is probably not a simple problem. I also suspect it is not something
considered in designing rpm itself or the distribution system.
This is what the infrastructure team have been working on, and reading
the fedora-devel list should give answers to the plans that they have.
It would appear that you can only sign a package with a single key at
a time. I just tested it.
[snip]
If trust can be established once, it can be establised again the same
way
as many times as needed. So the discussion needs to move to what may be
the REAL problem. Can an rpm be signed with multiple keys in any
meaningful way so that people pre-update can still grab the key updates
and compare files prior to a specific date against the old key while new
files compare against the new key.
It appears the answer is no. Only one signature at a time. This is one
of the problems the infrastructure team have been wrestling with.
If THAT can be done it seems like both this discussion and the delay
are somewhat spurious, right?
It would appear the discussion is not entirely spurious. ;-)
/Anders
3:38 a.m.
From: "Anders Karlsson" <anders(a)trudheim.co.uk>
Sent: Friday, 2008, September 05 13:12
* jdow <jdow(a)earthlink.net> [20080905 20:52]:
> From: "Anders Karlsson" <anders(a)trudheim.co.uk>
> Sent: Friday, 2008, September 05 00:50
>
>
>> * jdow <jdow(a)earthlink.net> [20080905 08:56]:
>>> Suppose I have NO RedHat installed. I have no working computer near
>>> me. I want to install Fedora 9. How do I establish the ability to
>>> subject the packages to tests for being properly signed, that the
>>> key used in the test is correct, and that I am reading and updating
>>> from a legitimate mirror?
>>
>> In this event you are likely installing from physical media, which
>> will have the public key on it already. If you do not trust that media
>> - why are you installing from it?
>
> Where did I get the media? How do I establish the chain of trust?
> Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
> around. If trust can be established from zero then it can happen
> again.
You had no OS installed - so where did you get the media from?
The only thing that matters at this point is whether you do, or not,
trust the media you are installing from? If you do - then you will
have a good key on the media that will validate updates later.
I probably should have said no OS new enough to have been signed. That
is why I amplified it to the old copy of RH4 or maybe a really antique
Slackware. The idea is that I had something via which I could initialize
the bootstrap process - barely.
Basically I had to trust that when I logged into download.fedora...
that I went to the right place and nobody in the middle was in a
position to futz the results. If I was paranoid I could then go to
several of the other mirror sites and perform downloads of at least
the signatures to see if they were bit copies of each other.
I could, with enough work, establish trust. I can, if needed, do that
again. Poof - much discussion about nothing new. It's all old well
covered territory.
>> Once you have installed the system - the updates you are
pulling down
>> will be verified with the key that was on the media - unless you
>> actively go and switch off the gpg checking.
>
> If I am actually going to the right mirrors and not a setup of fast
> flux servers full of malware that will be true.
Mu.
The Fedora installation media installs repo configs that point to the
Fedora projects servers. Your comment indicates that you believe your
ISP and the DNS servers you use are compromised. At this point - all
bets are off.
>> As others have already pointed out - it's a question of trust. At some
>> point or other - you have to decide what you trust. If you do not
>> trust something, do not use it (and then live with the consequences of
>> that choice).
>
> Exactly. This is the point. If I can proceed from zero and establish
> trust once I can do it again. So I am unclear over what the problem
> in that regard can be such that it would stall the process of getting
> rolling again.
>
> I can see other items causing a hitch in the gitalong. But I cannot
> see any means other than trusting my DNS server and the routers
> between download.fedora.redhat.com and me. If I could trust them once
> I can trust them again. So the focus of this thread is wrong. It
> should be more along the lines of "How can a company that uses RPM
> and signed packages arrange to have the packages multiply signed so
> that both an old obsolete key works and a new key works?"
>
> THAT is probably not a simple problem. I also suspect it is not something
> considered in designing rpm itself or the distribution system.
This is what the infrastructure team have been working on, and reading
the fedora-devel list should give answers to the plans that they have.
It would appear that you can only sign a package with a single key at
a time. I just tested it.
Of course, if you think about it an RPM that will accept multiple
signatures would also have to have a proper signature revocation protocol
involved. But how does that prevent someone who has compromised the
key from issueing a revoke and a new key that is next used to sign a
full set of forged RPMs? I imagine the Fedora and Red Hat fellows have
their hands seriously full figuring out how they are going to handle
the whole process.
[snip]
> If trust can be established once, it can be establised again the same way
> as many times as needed. So the discussion needs to move to what may be
> the REAL problem. Can an rpm be signed with multiple keys in any
> meaningful way so that people pre-update can still grab the key updates
> and compare files prior to a specific date against the old key while new
> files compare against the new key.
It appears the answer is no. Only one signature at a time. This is one
of the problems the infrastructure team have been wrestling with.
> If THAT can be done it seems like both this discussion and the delay
> are somewhat spurious, right?
It would appear the discussion is not entirely spurious. ;-)
Large chunks of the discussion have bypassed the main problems in flights
of trust fantasy. They established trust once. They can do it again. So
that is not the problem other from a convenience standpoint.
Nor is RPM accepting multiple keys the real problem, necessarily. It will
accept multiple keys already - one at a time. It becomes the users PITA
to figure out which one to use on a package. But in the "Establish Trust"
world that's always been the problem; and, it's been solved. Do it once
means you can do it repeatedly.
Mike recounted his original issues. One of them touched what I see as the
really big issue.
M> Since Fedora got compromised, we'd like to know
M> what they run on their servers, and whether we
M> might ourselves be vulnerable to the same kind of
M> attack which compromised Fedora in the first place.
M> If so, we'd like to know what the attack was,
M> how it succeeded, and how to protect against it.
Red Hat and Fedora both push SELinux heavily. As I remember my older
days in the DoD world and articles I have read over the years major
components of SELinux include access control lists and logs. The ACL as
a tool prevents unauthorized access to files even by "root". And logs
are supposed to be rigorous enough to track the movements of any account
on the machine such that you can tell if the machine was compromised and
how it was compromised. If the machines were compromised such that the
log files are insecure that must have the NSA folks in a really serious
tizzy if SELinux was installed and used properly.
(If I was in that environment, I'd have a separate logging machine that
had no means if ingress and performed logging via "tail -f" on the real
log files over ssh connections from the log check machine. This is a
variant of the old log to TTY machine process of the bad old days.)
For one I'd like to know if they used their own Bandini (tm) known as
SELinux. And I'd like to know how they were compromised. (And I bet
they would, too.)
{^_^} Joanne
10:26 p.m.
On Sat, Sep 6, 2008 at 1:38 AM, jdow <jdow(a)earthlink.net> wrote:
From: "Anders Karlsson" <anders(a)trudheim.co.uk>
Sent: Friday, 2008, September 05 13:12
Some 50000 posts later .....
Where are the other critical open source players in all this?
Moving forward...
At this point a critical missing component is the framework to re-key/
sign the top of a distribution tree/mesh. All vendors might face
this same problem and so all vendors have skin in this game.
It seems that a collection of face to face credential exchanges and
FedX packages containing CDROMs with the public half of key pairs to
and from the likes of RH, Fedora, Sun, Cray, Cisco, Dell, Debian,
Ubuntu, Scientific Linux, Cern, CentOS, and some.edu sites on multiple
continents could go a long way to establish a foundation for a web of
trust.
Each site can then use their 'top' level keys to sign a set of
critical site and individual keys then place the master key in an off
line vault.
Once the foundation is in place ... more can be done (designed).
--
NiftyFedora
T o m M i t c h e l l
9:49 a.m.
jdow wrote:
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
This is the same issue you have with SSH, or encrypted web pages.
Who certifies the certificators? Diffie and Hellman solved the
key distribution problem, but the only way we know of to know that
you've got the right public key is to perform the initial transfer in
person, and then build a "web of trust" as has been mentioned.
If this can be done once in an initial install situation it can be
done
again in an update situation using the same mechanism.
One way is to download the stuff from Red Hat's site itself,
and trust that no one has managed to intercept your communications.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
3:59 p.m.
Mike McCarty wrote:
jdow wrote:
>
> If this can be done once in an initial install situation it can
be done
> again in an update situation using the same mechanism.
One way is to download the stuff from Red Hat's site itself,
and trust that no one has managed to intercept your communications.
Actually you don't need "the stuff" other than the new key, do you?
And
the sha1sum (or even sha256sum) of the key and the ISO install image.
Once you have that you can trust the mirrors, because even if someone
can corrupt a mirror it will be detected. And a list of checksums for
all packages released against FC[89] so I can check my archived RPMs
against it.
That should restore the level of trust present for any previous Fedora
release.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3:03 p.m.
Bill Davidsen wrote:
Mike McCarty wrote:
> jdow wrote:
>>
>> If this can be done once in an initial install situation it can be done
>> again in an update situation using the same mechanism.
>
> One way is to download the stuff from Red Hat's site itself,
> and trust that no one has managed to intercept your communications.
>
Actually you don't need "the stuff" other than the new key, do you? And
I used a generic noun because I don't know what "the stuff" is going
to be. It might be a RPM with the new key in it, or just some text,
or I don't know what. Your comment is correct, but perhaps slightly
misdirected because I was vague.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
11:10 a.m.
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen <davidsen(a)tmr.com> wrote:
Patrick O'Callaghan wrote:
>
> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>>
>> hardest of all find a secure way to provide the public part of the
>> signing key
>
> The whole point about asymmetric encryption is that you don't need a
> secure distribution channel. The worst that can happen is that some fake
> public key gets distributed, which won't match the private key and hence
> will be instantly detectable.
>
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. And packages signed with any valid redhat key would be rejected.
The public key really must be distributed in a secure manner.
Isn't the point of a Public Key to be publicly distributed?
The Private Key is what you closely guard against all tampering.
~af
11:16 a.m.
On Thu, Sep 04, 2008 at 09:10:14 -0700,
Aldo Foot <lunixer(a)gmail.com> wrote:
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen
<davidsen(a)tmr.com> wrote:
> Patrick O'Callaghan wrote:
>
> The public key really must be distributed in a secure manner.
Isn't the point of a Public Key to be publicly distributed?
Yes, but you need to know that you have the correct public key. So while it
doesn't need to be secret, it does need integrity protection.
The Private Key is what you closely guard against all tampering.
The private key needs to be kept secret. Tampering isn't normally going to
be that big of a deal, since you'll notice and then realize it most likely
isn't secret any more and change the key pair.
12:18 p.m.
Aldo Foot wrote, On 09/04/2008 12:10 PM:
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen
<davidsen(a)tmr.com> wrote:
> Patrick O'Callaghan wrote:
>> On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
>>> hardest of all find a secure way to provide the public part of the
>>> signing key
>> The whole point about asymmetric encryption is that you don't need a
>> secure distribution channel. The worst that can happen is that some fake
>> public key gets distributed, which won't match the private key and hence
>> will be instantly detectable.
>>
> 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. And packages signed with any valid redhat key would be rejected.
>
> The public key really must be distributed in a secure manner.
Isn't the point of a Public Key to be publicly distributed?
Only part of the point.
Yes, you can give your Public Key to me, and I can give it to Jim, and Jim can
give it to Jane, and it is still good for it's purpose, which is to validate
that the packet of data sent on the net has not been messed with between being
signed with the private key and arriving at the destination.
But, should Jane be trusting a key given to her by that shady guy Jim to
install random bits of software?
Now if some time earlier Jane and I had met, and exchanged public keys and she
felt that my signature was worthy of trust[1], and I had signed your key
before giving it to Jim, then Jane would have SOME reason to trust that the
key came from _WHO_ it claims to come from instead of some key that Jim
generated to do a MITM attack[2].
The underlying thing Bill was getting at with "The public key really must be
distributed in a secure manner" is security from an INTEGRITY perspective[3].
Unfortunately, currently most of us only have a very tenuous web of trust back
to any key that that could vouch for the fact that any new key is actually
from the Fedora crew. Many folks will trust the key because the old key
(which has a shadow of doubt over it) will sign it, i.e., they will get it
with yum and because the old key's sig passes what is on their system it will
be installed. Some may trust it because they have a substantial web of trust
to Paul Frields or other Fedora community members who may sign a version of
the public key. Others may trust it because they trust a person who gives it
to them and know that person got it physically from a person at the red hat
building who the second person trusts.
See the suggestion I made a while back[4] for further information about our
current use of cobwebs of trust. My suggestion then was not to take care of
the current situation, it is too late for using it for the current situation,
but it would make any later situations easier to deal with. I still think
Fedora needs a master key made (soon after the current situation is resolved)
so that we can start building at least a cobweb for it.
The Private Key is what you closely guard against all tampering.
~af
[1] http://en.wikipedia.org/wiki/Web_of_trust
[2]
http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Example_of_a_succes...
[3] http://en.wikipedia.org/wiki/Data_integrity
[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
{something seems bonkers with the way the html is showing the foot notes at
the end of the message, as it looks like foot note 2 is referencing 3-7, but
those seem to have been concatenated onto the same line with foot note 2.}
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
4:46 p.m.
On Tue, 2008-09-02 at 17:27 +0100, Bill Crawford wrote:
On 02/09/2008, Bill Davidsen <davidsen(a)tmr.com> wrote:
> If there is a known date before which packages can be trusted, that
> should be said. Users who lag the cutting edge will be reassured. People
> won't have to be checking security logs for a decade if the problem is
> more recent. People on distributions older than FC8 which are not
> maintained should be told if the problem goes back that far.
The infrastructure is up and running.
FC-10/rawhides's infrastructure seems up
and running.
FC-9 and FC-8's cvs and buildsys are up again, but no pushes are
happening. In a nutshell, this means FC-8/F-9's infrastructure is
effectively down.
Ralf
9:37 a.m.
Ralf Corsepius wrote:
On Tue, 2008-09-02 at 17:27 +0100, Bill Crawford wrote:
> On 02/09/2008, Bill Davidsen <davidsen(a)tmr.com> wrote:
>
>> If there is a known date before which packages can be trusted, that
>> should be said. Users who lag the cutting edge will be reassured. People
>> won't have to be checking security logs for a decade if the problem is
>> more recent. People on distributions older than FC8 which are not
>> maintained should be told if the problem goes back that far.
> The infrastructure is up and running.
FC-10/rawhides's infrastructure seems up and running.
FC-9 and FC-8's cvs and buildsys are up again, but no pushes are
happening. In a nutshell, this means FC-8/F-9's infrastructure is
effectively down.
I tried to update a clean install (see below) and got metadata but no
packages. That may have just been a bad time, or even the old packages
may be unavailable. Fortunately for me I have every RPM I ever got, back
to FC4, and the FC1 KRUD relase as well. Unfortunately for me I'm not
sure I trust them. I wanted to D/L the current and compare with the old
I already have, and see if anything has changes.
Note on not downloading over and over... if you have multiple systems,
you can set one to keep the RPMs after use, then copy them to the same
location in /var/cache/yum in another machine. Just the RPMs, not the
metadata. This allows the metadata to come in from the network and the
RPMs to be local, helpful on a machine with slow network. For no network
at all, the rpm "freshen" command will update only what you have installed.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
5701
days inactive
5712
days old
90 comments
22 participants
participants (22)
-
Aldo Foot -
Anders Rayner-Karlsson -
Bill Crawford -
Bill Davidsen -
Bruno Wolff III -
David Shaw -
Ed Greshko -
jdow -
Jef Spaleta -
Joel Rees -
John Aldrich -
Jonathan Underwood -
Kevin Fenzi -
Les Mikesell -
Mike McCarty -
Nifty Fedora Mitch -
Patrick O'Callaghan -
Ralf Corsepius -
Tim -
Todd Denniston -
Todd Zullinger -
Travis Arnold