On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera <bnocera(a)redhat.com> wrote:
----- Original Message -----
>
>
> On 3/12/20 10:57 AM, Bastien Nocera wrote:
> >
> >
> > ----- Original Message -----
> > <snip>
> >> The git tags are still signed by Linus. Does that cover your concerns?
> >
> > Not really, no. I think that multiplying the intermediaries between
> >
kernel.org
> > and the Fedora repos by adding
gitlab.com in the middle might not be the
> > best of ideas.
> >
> > If the Fedora security team is fine with it, I'm fine with it, and even if
> > I
> > understand the practical concerns (pagure not being up to par to deal with
> > repos that size, and without a mail gateway support), I find it slightly
> > concerning.
> >
>
> I think this boils down to how much do you trust the kernel maintainers.
> Keep in mind that the existing model requires the kernel maintainers
> to manually pull down a tree and extract the tarball and then upload.
> You can probably trust them to not do anything malicious but mistakes
> can happen (source: I screwed up many times). It's good to be concerned
> about provenance as a threat model but I consider maintainers screwing
> up manual tasks to be a bigger threat model to Fedora kernel security
> so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust
gitlab.com _in addition_ to trusting
kernel.org and
fedoraproject.org. I wouldn't be concerned at all if
the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers
will care about that. They clearly haven't cared given that the CKI
project does not run on what most in the project generally considers
"trusted infrastructure".
I also am personally not a fan of the "source-git" approach for
various reasons (including that it makes it *much* more difficult to
identify downstream vs upstream changes, more easily leading to
forks), but the kernel team actively contributes to upstream and our
current policy makes it incredibly difficult to have non-upstream
changes in the kernel, so I'm less worried there.
--
真実はいつも一つ!/ Always, there's only one truth!