On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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. Ah. I see, well that makes sense, yes. > 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. CKI didn't evolve as a Fedora specific thing. It certainly benefits Fedora, and I think we should welcome such activities without being worried entirely about control. The tipping point in my mind is whether we *depend* on something for Fedora's success. Those kinds of projects should probably be folded into Fedora control. CKI is massively valuable, but if it disappeared tomorrow Fedora would still continue on. > 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! I agree 100%. josh _______________________________________________ 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
