On Tue, 31 Dec 2013 13:27:30 -0500
Daniel Kahn Gillmor wrote:
> On 12/31/2013 01:19 PM, Graham Leggett wrote:
> > It is also a statement of what keys have historically been used to
> > sign past artifacts, and that is just as important.
>
> These are distinct things, though. It would be great i
On 12/31/2013 01:19 PM, Graham Leggett wrote:
> It is also a statement of what keys have historically been used to sign past
> artifacts, and that is just as important.
These are distinct things, though. It would be great if the apache
project could separately identify which keys are going to be
On 31 Dec 2013, at 20:07, Issac Goldstand wrote:
> Not in this case. Revoking would be a statement by the key owner that
> the key is no good (something that would probably be smart to do, but at
> the same time way out of the PMC's control). Pruning the KEYS file is a
> statement by the PMC ab
Not in this case. Revoking would be a statement by the key owner that
the key is no good (something that would probably be smart to do, but at
the same time way out of the PMC's control). Pruning the KEYS file is a
statement by the PMC about what keys the PMC authorizes to sign artifacts.
Issa
Isn't the "normal" solution path - rather than prune, to revoke keys?
On Fri, Dec 27, 2013 at 4:53 PM, Frederick Miller wrote:
> Please remove me from this email list. Please unsubscribe me. Thanks.
>
>
> On Fri, Dec 27, 2013 at 10:49 AM, Daniel Kahn Gillmor <
> d...@fifthhorseman.net> wrote:
>
Our company would have run into the problem, though I knew it beforehand and
avoided the problem on affected servers by switching back to prefork. We have
setup our servers to build all shared mpms anyways, so this wasn’t a big
problem.
All the affected systems were in fact 32bit SLES (10 and 1
