On Wed, 22 Oct 2014 19:59:59 +0000 "E. Margarete Ziemer" <emzie...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info