On Thu, Oct 23, 2014 at 12:02 PM, Andrew Deason <adea...@sinenomine.net> wrote:
> > 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. > This is basically the summary. The kext bit unlike the rest involves a human at the other end answering based on what you answered on that page and potentially asking for more info.' 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. Actually, the first signing key was created by Simon (on lochranza) when he worked for INF; I created a second one when we had bender.openafs.org building RPMs, for that. Neither suggests anything other than that the host built the RPMs in question, and unless you install the package that adds them, they won't be used for verification as RHEL is not shipping those keys. So you must take action before the signing is worth anything. > 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".) > > Yes, that's my assumption at the moment; for new platforms the problem stops existing at some point. > > For any other platforms, such as HPUX (historically), I don't think until very recently AIX had a way; Solaris we let our packages bitrot and now the mechanism to make packages is different; and I haven't kept track of FreeBSD. > 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. > That's a pretty apt summary of what's in play. -- D
