Re: Upcoming Fedora kernel workflow changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera <bnocera@xxxxxxxxxx> 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".
>
> Fedora's "trusted infrastructure" can't scale to what CKI is doing.
> One could argue about what trusted infrastructure means in general,
> because in my opinion there is no such thing, but it would be entirely
> irresponsible to overwhelm already limited capacity with something
> that is done at the scale CKI runs.  Figuring out how to get
> comfortable with using cloud resources for workloads where that make
> sense is critical to our long term success.
>
> (FWIW, I'm trying really hard not to read your comment as a slam on
> the kernel team here.  I also find it an interesting example of
> cognitive dissonance that CKI running in AWS somehow triggers this
> comment, when all of Fedora is dependent on the mirror network to
> serve the actual binaries to users and *that* is far more risky than
> doing build testing in the cloud that doesn't even impact end-users.)
>

I am not slamming the kernel maintainers. They're doing excellent
work, and many of the efforts as part of the CKI project are to be
lauded. I am also not saying cloud resources in themselves are a
problem, but it's not like you're running on a git server hosted in
Fedora's AWS/Azure/GCP account.

My principal concern has always been that projects under the Fedora
banner (or something like it) should be under infrastructure that the
Fedora Project controls.

Honestly, I don't care if it's RHOSP, Fedora's AWS/Azure/GCP, or a
server in a Red Hat office or datacenter. What I care about is that
when push comes to shove, we're not screwed by an external force in an
unexpected fashion in a way where we have no recovery plan.

Personally, I think it's cool to see that the Red Hat kernel might
eventually be derived from the Fedora kernel as a consequence of this
effort!




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux