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
