[OpenAFS] Providing signed packages (was Re: any experiences with OpenAFS client ...)

[Andrew Deason]

On Wed, 22 Oct 2014 19:59:59 +0000
"E. Margarete Ziemer" <emziemer@sinenomine.net> wrote:

> I will put the lawyer and risk assessment topics on the agenda for the
> next Foundation Board meeting.  Thank you, all of you, for this
> discourse, which has helped to sharpen my/our thoughts and focus on
> what exact and unambiguous questions would/will have to be posed to a
> lawyer.  While none of us is a lawyer, we can, together, hammer out
> the exact questions.  Based on the discussion thus far, what do y'all
> think those questions should be, precisely?  

It's not just a legal question, but a more general goal of signing
releases that openafs.org provides.

Some background (sorry if this sounds too basic, just trying to explain
and make sure people are on the same page):

For many forms of packaging, there is the notion of cryptographically
"signing" the built binaries with a public key or certificate. The act
of signing them is the signer's way of putting some vague "stamp of
approval" on the binary, usually for the purposes of saying that the
binaries are indeed built from the source tree from openafs.org, and
haven't been tampered with. So a user of openafs can download a package
from openafs.org, and check that it has been signed by a trusted party
(or has been signed by someone that is trusted by some higher-up trusted
3rd party), and so someone hasn't modified it to include spyware, a
virus, etc. Some people also believe the act of signing it extends some
implicit liability to the signer, since if someone uses a signed package
and it breaks, they can point to the org that signed the package and say
"hey, you said this was okay". Signing certain types of packages
indicate very specific things (you must agree to some conditions of a
contract or something to do so).

So, when openafs.org provides built binaries for users, it would be
better if they were signed by "someone". Obviously historically, we
haven't had a good answer for who that "someone" should be, since there
was no person or organization that represented openafs. And now the
Foundation is the clear candidate for the organization that should be
doing so.

The current situation:

This is a problem for all of the binaries that openafs.org provides, but
it's an urgent problem for OS X specifically because of two issues:
we've never provided signed OS X packages, and in recent releases of OS
X it is difficult or impossible for a user to install unsigned openafs
packages. In order to sign this, you need to go through Apple to get the
relevant certificate; more information can be found around here:
<https://developer.apple.com/developer-id/>. We also need the specific
thing mentioned in the lower-right, mentioning kexts, which links to
here: <https://developer.apple.com/contact/kext/>. I assume Daria has
more insight into this process than I do, but I assume you need to agree
to some legal stuff or whatever in order for them to give you a
certificate to use for signing.

For Windows, the binaries provided by openafs.org are currently signed
by YFS (and previously by Secure Endpoints, I assume). That allows users
to at least install the software, but of course some people don't like
relying on that company when they don't have a contract or whatnot. I'm
not exactly sure what the procedure is for setting up a new organization
to sign the packages, but some information from Microsoft appears to
start here:
<http://msdn.microsoft.com/en-us/library/ie/ms537361(v=vs.85).aspx>.

For RHEL packages distributed through openafs.org, currently they are
signed by a key we just have on the openafs.org website; I assumed it
was just some key that Daria created a long time ago, but it's not clear
who the legal party is that's signing them. For the Foundation to take
this over, I assume we'd just create a new key in a similar way for the
foundation. Or transfer the old key, but a new one is probably better,
which clearly identifies the foundation. (Note: going forwards we hope
to stop distributing RHEL RPMs through openafs.org as of RHEL7+, so this
will probably also just "go away".)

For Debian, and for RPMs delivered via other organizations, like CentOS
or ScientificLinux, the packages are signed by that organization (e.g.
by the Debian maintainer, the SL maintainer, etc). So we don't have to
worry about that.

For the SuSE RPM packages we provide, I assume we just use a key that
lives in openafs.org somewhere, or Christof is using his own key he
made.

For any other platforms, such as HPUX (historically), AIX, Solaris,
FreeBSD, we just don't sign the binaries. These could be signed at some
point, but other platforms seem like a much bigger priority for now.

For all of these situations where the Foundation would provide the
ability to sign binaries, there are those legal considerations, then,
but also other things. The Foundation needs to have a point of contact
for any of these, and needs to go through the process of signing up for
the relevant service and buying the relevant certificates/keys, etc. We
also need to have a place or person(s) to store the secret keys; if
they're not stored securely, they obviously do no good. It also needs to
be clear how they will get used to sign the binary releases (who gets
access to the keys for signing).

So, that's the kind of thing that needs to be done. But just for OS X
for the urgent issue; all the other platforms and most of the procedures
and such could be deferred until later. The specific legal
considerations you need to be aware of will probably be found by going
through the OS X process in the links provided above.

-- 
Andrew Deason
adeason@sinenomine.net