greg at kroah.com
Sun Sep 8 09:58:23 PDT 2013
On Sun, Sep 08, 2013 at 06:43:09PM +0200, Eugen Leitl wrote:
> On Sun, Sep 08, 2013 at 09:08:24AM -0700, Greg KH wrote:
> > > Real physical security and a process to keep signing secrets
> > > secure in community based Linux and *BSD distributions.
> > What are the problems in the existing processes that you feel are week?
> > For example, what is wrong with openSUSE's signing process that you feel
> > are wrong?
> I'm only aware of how Debian does things, and not in any detail.
Then don't assume that all distros have this type of problem please.
> What I would do is to separate the signing secrets across multiple
> key people, and do a recorded/witnessed ceremony following a CA-like
> model, signing on an air-gapped machine which is securely
> wiped afterwards and transferring packages via sneakernet
> (making sure there's nothing autoexecuted on plugin)
> to the machine where it is being published. Yes, this is a huge
And it makes automated builds an almost impossible thing to achive, so
it's not realistic.
> So have a secure process in place, monitor the process by
> external parties so that we can be sure that it is actually being
> done the way it is said to be done. Trust, but verify.
Agreed, and I think that other distros already do this, Debian might be
the exception :(
> > > Review of anything crypto based. Completely different process
> > > for anything crypto based than for everything else. No more
> > > undetected regression meltdowns a la Debian.
> > What type of review? What type of process would catch stuff like that?
> Getting in the professionals. A lot of old cryptography and
> cypherpunk hands have reappeared and the woodwork is buzzing
> with activity. They have clue and they're willing to help.
Projects almost always gladly accept patches and review, what's stopping
anyone from doing this today? I know of a handful of people who started
doing this for the Linux kernel a few years ago and instantly got job
offers to continue doing this full-time. Some of them accepted and have
been working very well on fixing a huge range of issues. Some decided
to stay where they were and continue to churn out great tools that let
us fix these issues (academia is a good place for stuff like this.)
Those tools work on all projects if they wish to be used, it's only a
matter of the developers using them.
> Somebody should first get them talking, and then organize a
> physical meeting. If I knew any distro guys I would try to
> hook them up.
Have them go to FOSDEM, where all the distros have a multi-day track to
work on issues that encompass them all.
More information about the linux-elitists