On jueves, 13 de octubre de 2016 1:34:42 PM CDT Kevin Fenzi wrote:
I meant to reply to this eariler. ;)
I just now saw the reply
:(
On Mon, 10 Oct 2016 17:20:06 -0500
Dennis Gilmore <dennis(a)ausil.us> wrote:
> On Monday, October 10, 2016 10:27:29 AM CDT Kevin Fenzi wrote:
> > Greetings.
> >
> > We have a request (
> >
https://pagure.io/fedora-infrastructure/issue/5372 ) to setup ssl
> > cert pinning for ostree deliverables. It's also been a long
> > wishlist item to have that for rpm deliverables too. Unfortunately
> > there's a bunch of moving parts here that we need to sort out
> > before we can move this forward.
> >
> > First some background/info:
> >
> > *
kojipkgs.fedoraproject.org currently uses a valid digisign cert.
> > It needs this because browsers download from it directly, our
> > builders download from it directly, etc.
> >
> > * pkgs/koji currently use certs signed by the Fedora Koji CA (which
> >
> > expires in 2024). This is currently needed by koji to do builds
> >
> > and the upload cgi for lookaside.
>
> The koji CA expires in 2018
ok
> > * We are hoping to deploy soon a pair of freeipa servers in
> > production that get information from fas and allow us to issue
> > kerberos tickets. koji can already authenticate via this method.
> >
> > * There's an outstanding ticket about having a verified way to get
> >
> > source:
https://pagure.io/fedora-infrastructure/issue/2324
> >
> > Questions we need to figure out:
> >
> > * Are we going to retire/replace the koji CA? My thought was yes,
> > but I think Dennis wasn't on board with this. Can anyone who wants
> > to save it speak up? :)
>
> I am against kerberos being the only auth mechanism. I suspect that
> some people either cant for reasons beyond our control or won't set
> up kerberos for auth
I'm interested in what these reasons could be.
The machines managed by their employers IT who forbid using any external
kerberos. The users just do not like kerberos.
Maintaining 2 authentication stacks is not something we really want
to
do if we can at all avoid it. And kerberos should be a good deal more
secure than certs I would think, and we still don't have a great setup
to manage the certs.
sure. it could be IPA makes it simple for us.
> > * The upload cgi would need to auth with kerberos and sigul
would
> > need to auth with kerberos for this to work.
> >
> > * If we are not completely retiring the koji CA, are we replacing
> > it?
>
> If not retired it has to be replaced, could be certs from freeipa
> that auto renew with certmonger, which i suspect users would like
> better than entering their kerberos password once a day.
well, we can adjust the kerberos settings. If they can renew for a week
would that be sufficent?
possibly, I am not the users. though with kerberos based
ssh for access to git
and fedora infra resources puts another benefit to having kerberos, as well as
possibly sso on all the web apps.
> > * Is ostree going to stay distributed at kojipkgs ? Or is
it going
> > to move somewhere else? we should figure out the final place for it
> >
> > before we go setting up cert pinning.
>
> No, it needs to go on the mirrors when we sort out how to mirror it,
> and the client and mirrormanager support it
Right, so doing some cert pinning right now might be not a great idea
if we are just going to move it.
There is bound to be a lot of moving coming. what is any different about any
of this that we do not need to do the same for rpm repos?
> > * The simple way to do pinning is for the application(s) to
include
> > a hard coded list of valid certs. I guess this would require
> > changes in librepo and somewhere in ostree?
> >
> > * The complex way to do pinning would be to setup
> >
> >
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
> > For this we would need to get backup keys for our cert(s) that are
> > used for this and setup webservers to send the right headers. This
> > would also need (more complex) changes in librepo and/or
> >
> > somewhere in ostree. This would also optionally get us reports of
> > violations.
> >
> > Thoughts? Comments?
>
> Not against making changes, but I do not think that they totally fit
> into long term goals
Well, I can definitely see the need for cert pinning and moving to
kerberos, but perhaps you can expand on the long term goals that this
doesn't address?
Well can we do cert pinning with mirrors? I guess we could to mirrormanager.
Does it matter with signed commits or repodata? some content will never or
rarely be available via https
Dennis
kevin