[OpenAFS] Providing signed packages (was Re: any experiences with
OpenAFS client ...)
D Brashear
shadow@gmail.com
Thu, 23 Oct 2014 14:14:04 -0400
--001a11c2b12c8fe65a05061b0711
Content-Type: text/plain; charset=UTF-8
On Thu, Oct 23, 2014 at 12:02 PM, Andrew Deason <adeason@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
--001a11c2b12c8fe65a05061b0711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 23, 2014 at 12:02 PM, Andrew Deason <span dir=3D"ltr"><<=
a href=3D"mailto:adeason@sinenomine.net" target=3D"_blank">adeason@sinenomi=
ne.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This is a problem for all of the binaries that <a href=3D"http://openafs.or=
g" target=3D"_blank">openafs.org</a> provides, but<br>
it's an urgent problem for OS X specifically because of two issues:<br>
we've never provided signed OS X packages, and in recent releases of OS=
<br>
X it is difficult or impossible for a user to install unsigned openafs<br>
packages. In order to sign this, you need to go through Apple to get the<br=
>
relevant certificate; more information can be found around here:<br>
<<a href=3D"https://developer.apple.com/developer-id/" target=3D"_blank"=
>https://developer.apple.com/developer-id/</a>>. We also need the specif=
ic<br>
thing mentioned in the lower-right, mentioning kexts, which links to<br>
here: <<a href=3D"https://developer.apple.com/contact/kext/" target=3D"_=
blank">https://developer.apple.com/contact/kext/</a>>. I assume Daria ha=
s<br>
more insight into this process than I do, but I assume you need to agree<br=
>
to some legal stuff or whatever in order for them to give you a<br>
certificate to use for signing.<br></blockquote><div><br></div><div>This is=
basically the summary.<br><br></div><div>The kext bit unlike the rest invo=
lves a human at the other end answering based <br>on what you answered on t=
hat page and potentially asking for more info.'<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
For RHEL packages distributed through <a href=3D"http://openafs.org" target=
=3D"_blank">openafs.org</a>, currently they are<br>
signed by a key we just have on the <a href=3D"http://openafs.org" target=
=3D"_blank">openafs.org</a> website; I assumed it<br>
was just some key that Daria created a long time ago, but it's not clea=
r<br>
who the legal party is that's signing them. </blockquote><div><br></div=
><div>Actually, the first signing key was created by Simon (on lochranza) w=
hen<br>he worked for INF; I created a second one when we had <a href=3D"htt=
p://bender.openafs.org">bender.openafs.org</a><br></div><div>building RPMs,=
for that. Neither suggests anything other than that the host built<br></di=
v><div>the RPMs in question, and unless you install the package that adds t=
hem, they<br></div><div>won't be used for verification as RHEL is not s=
hipping those keys. So you must<br></div><div>take action before the signin=
g is worth anything.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For =
the Foundation to take<br>
this over, I assume we'd just create a new key in a similar way for the=
<br>
foundation. Or transfer the old key, but a new one is probably better,<br>
which clearly identifies the foundation. (Note: going forwards we hope<br>
to stop distributing RHEL RPMs through <a href=3D"http://openafs.org" targe=
t=3D"_blank">openafs.org</a> as of RHEL7+, so this<br>
will probably also just "go away".)<br>
<br></blockquote><div>Yes, that's my assumption at the moment; for new =
platforms the problem stops existing<br>at some point.<br>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">
<br>
For any other platforms, such as HPUX (historically), </blockquote><div><br=
></div><div>I don't think until very recently AIX had a way; Solaris we=
let our packages bitrot <br>and now the mechanism to make packages is diff=
erent; and I haven't kept track of FreeBSD.<br>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">AIX, Solaris,<br>
FreeBSD, we just don't sign the binaries. These could be signed at some=
<br>
point, but other platforms seem like a much bigger priority for now.<br>
<br>
For all of these situations where the Foundation would provide the<br>
ability to sign binaries, there are those legal considerations, then,<br>
but also other things. The Foundation needs to have a point of contact<br>
for any of these, and needs to go through the process of signing up for<br>
the relevant service and buying the relevant certificates/keys, etc. We<br>
also need to have a place or person(s) to store the secret keys; if<br>
they're not stored securely, they obviously do no good. It also needs t=
o<br>
be clear how they will get used to sign the binary releases (who gets<br>
access to the keys for signing).<br>
<br>
So, that's the kind of thing that needs to be done. But just for OS X<b=
r>
for the urgent issue; all the other platforms and most of the procedures<br=
>
and such could be deferred until later. The specific legal<br>
considerations you need to be aware of will probably be found by going<br>
through the OS X process in the links provided above.<br>
<span class=3D"HOEnZb"></span></blockquote><div><br></div><div>That's a=
pretty apt summary of what's in play. <br></div></div><br>-- <br><div =
dir=3D"ltr">D</div>
</div></div>
--001a11c2b12c8fe65a05061b0711--