On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@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".
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