Re: Intel SOF firmware
Hello Peter, On Fri, Mar 13, 2020 at 7:37 PM Peter Robinson wrote: > [snip] > If they update using the recommended supported methods (upgrade and > dnf distro-sync) it will pull in new additions to the installed comps > groups so that should work fine with upgrades. Yes, I meant if someone already did the upgrade to F32 or does it before Jaroslav's pull-request is merged. Best regards, Javier ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Intel SOF firmware
On Fri, Mar 13, 2020 at 5:03 PM Javier Martinez Canillas wrote: > > Hello Jaroslav, > > On Tue, Mar 10, 2020 at 10:00 AM Jaroslav Kysela wrote: > > [snip] > > > So thinking more about this, I guess we should only add the explicit > > requires to the kernel package for F31 (and F30) and add it to comps > > for F32+, this way F30 / F31 users will get the package through > > the requires (and keep it on upgrade to F32+) and fresh F32 installs > > will also get it this way. > > I think we also need the requires in the kernel package for F32, since > users could update their systems to F32 before it is released. If they update using the recommended supported methods (upgrade and dnf distro-sync) it will pull in new additions to the installed comps groups so that should work fine with upgrades. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Intel SOF firmware
Hello Jaroslav, On Tue, Mar 10, 2020 at 10:00 AM Jaroslav Kysela wrote: [snip] > So thinking more about this, I guess we should only add the explicit > requires to the kernel package for F31 (and F30) and add it to comps > for F32+, this way F30 / F31 users will get the package through > the requires (and keep it on upgrade to F32+) and fresh F32 installs > will also get it this way. I think we also need the requires in the kernel package for F32, since users could update their systems to F32 before it is released. Best regards, Javier ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 10:00 AM Josh Boyer wrote: > > On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa wrote: > > > > 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. > I think that will depend on how much we will grow to rely on the CKI stuff to make "good" kernels. Ideally, it'll become critical to doing so, and thus it will make sense to fold it under the Fedora banner. -- 真実はいつも一つ！/ Always, there's only one truth! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, 2020-03-13 at 07:07 -0400, Neal Gompa wrote: > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera > wrote: > > > > > > - Original Message - > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > - Original Message - > > > > > > > > > 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'm not sure what your issue with CKI is, but that's beside the point. What exactly about the tarball coming from kernel.org makes you trust it? That's not a rhetorical question, I'm genuinely curious. Is it the x509 certificate they were issued? Is it that the tarballs are GPG- signed? > 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. > Currently we make a clone of Linus's tree and do a diff between master and the latest tag and then plop that into the lookaside cache. No individual commits, nothing. You know what happens if I'm working on a patch in that repository? Into the patch it goes, and good luck finding it among thousands of other changes. In the source tree, every commit is still broken out, figuring out what patches Fedora carries is a simple git command. It's *way* simpler to discover what patches are included in a build and why. Kind regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 9:56 AM Josh Boyer wrote: > > Provenance isn't what I was phrasing as risky. We depend on the > mirror network to scale, which is entirely outside of our control and > if they decide it's no longer worth distributing Fedora binaries we'd > be screwed. It's the exact concern Neal has :) > Well, as a mirror admin, I don't plan on stopping anytime soon. :) That said, we still control the master endpoint, and there *are* some fallback scenarios, just way more expensive and difficult to deal with. I hope we don't have to go there, I enjoy the generosity of our mirror network and I'm glad to contribute to the project myself in this manner, too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa wrote: > > On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer wrote: > > > > On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa wrote: > > > > > > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera wrote: > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > > >> 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@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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.fedoraproje
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 9:51 AM Peter Robinson wrote: > > > > > > >> 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. > > And git repos should be verifiable to the upstream so I believe this > should be no worse than any other git ecosystem. > > > (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.) > > Package/repo signing mitigates that, but that can also be done in the > git side of things too. Provenance isn't what I was phrasing as risky. We depend on the mirror network to scale, which is entirely outside of our control and if they decide it's no longer worth distributing Fedora binaries we'd be screwed. It's the exact concern Neal has :) josh ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
> > > > >> 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. And git repos should be verifiable to the upstream so I believe this should be no worse than any other git ecosystem. > (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.) Package/repo signing mitigates that, but that can also be done in the git side of things too. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer wrote: > > On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa wrote: > > > > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera wrote: > > > > > > > > > > > > - Original Message - > > > > > > > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > >> 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@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa wrote: > > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera wrote: > > > > > > > > - Original Message - > > > > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > > > > > - Original Message - > > > > > > > >> 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.) josh > 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! > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera wrote: > > > > - Original Message - > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > > - Original Message - > > > > > >> 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! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
- Original Message - > On Thu, Mar 12, 2020 at 9:58 AM Bastien Nocera wrote: > > > > > > > - Original Message - > > > > > 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 don't really see how this is relevant in regards to kernel.org. > dist-git still uses the lookaside for tarballs, which are downloaded from > kernel.org, signature verified, and uploaded independent of anything gitlab > is doing. Development work happens on top of a tree at gitlab, which is > how our fedora specific patches, config options, and spec file are > maintained, but none of this is on kernel.org anyway. The tree used as a > basis does use the kernel.org tree, but this is not much different from > cloning a tree anywhere else and doing development on top of it. Presumably the important distinction is that if you were just "doing development somewhere else", the diff/patches would then be reviewed before being merged. Here, they're going to be reviewed as they're being merged into the gitlab.com repo, and the sync to the fedoraproject.org repo isn't going to be reviewed because it's likely not going to be human-readable. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
- Original Message - > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > - Original Message - > > > >> 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. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
