* Sourceware / GNU Toolchain at Cauldron @ 2022-09-16 20:57 Zoë Kooyman 2022-09-16 21:10 ` Ian Kelling 2022-09-18 16:27 ` Mark Wielaard 0 siblings, 2 replies; 15+ messages in thread From: Zoë Kooyman @ 2022-09-16 20:57 UTC (permalink / raw) To: overseers [-- Attachment #1: Type: text/plain, Size: 973 bytes --] Hi all, We are aware that several presentations will be given at Cauldron this weekend proposing new ways to support the Sourceware project and the GNU Toolchain packages hosted there. The FSF has been a fiscal sponsor to the GNU Toolchain for several years (and continues to be), and has been grateful to have Sourceware providing development infrastructure using free software. Unfortunately, we won't have staff present at Cauldron, but we are keeping up with the development of the various proposals and talking with people involved, as well as seeing how we might be able to offer support to help make good things happen. We want Sourceware and the GNU packages it hosts to have stable homes and strong futures in freedom. We expect the conversations in the next few days to be open and transparent and involving the community, and look forward to discussing the best way(s) forward in the coming weeks. Zoë Kooyman Executive director FSF ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-16 20:57 Sourceware / GNU Toolchain at Cauldron Zoë Kooyman @ 2022-09-16 21:10 ` Ian Kelling 2022-09-18 16:27 ` Mark Wielaard 1 sibling, 0 replies; 15+ messages in thread From: Ian Kelling @ 2022-09-16 21:10 UTC (permalink / raw) To: Overseers mailing list; +Cc: Zoë Kooyman The message was accidentally not plain text, I'm replying just to make a plain text version so it is readable in the archive: Zoë Kooyman via Overseers <overseers@sourceware.org> writes: Hi all, We are aware that several presentations will be given at Cauldron this weekend proposing new ways to support the Sourceware project and the GNU Toolchain packages hosted there. The FSF has been a fiscal sponsor to the GNU Toolchain for several years (and continues to be), and has been grateful to have Sourceware providing development infrastructure using free software. Unfortunately, we won't have staff present at Cauldron, but we are keeping up with the development of the various proposals and talking with people involved, as well as seeing how we might be able to offer support to help make good things happen. We want Sourceware and the GNU packages it hosts to have stable homes and strong futures in freedom. We expect the conversations in the next few days to be open and transparent and involving the community, and look forward to discussing the best way(s) forward in the coming weeks. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-16 20:57 Sourceware / GNU Toolchain at Cauldron Zoë Kooyman 2022-09-16 21:10 ` Ian Kelling @ 2022-09-18 16:27 ` Mark Wielaard 2022-09-18 21:38 ` Mark Wielaard 1 sibling, 1 reply; 15+ messages in thread From: Mark Wielaard @ 2022-09-18 16:27 UTC (permalink / raw) To: Zoë Kooyman via Overseers; +Cc: Zoë Kooyman Hi Zoë, On Fri, Sep 16, 2022 at 04:57:36PM -0400, Zoë Kooyman via Overseers wrote: > We are aware that several presentations will be given at > Cauldron this weekend proposing new ways to support the Sourceware > project and the GNU Toolchain packages hosted there. > > The FSF has been a fiscal sponsor to the GNU Toolchain for several > years (and continues to be), and has been grateful to have > Sourceware providing development infrastructure using free > software. Unfortunately, we won't have staff present at Cauldron, > but we are keeping up with the development of the various proposals > and talking with people involved, as well as seeing how we might be > able to offer support to help make good things happen. > > We want Sourceware and the GNU packages it hosts to have stable > homes and strong futures in freedom. We expect the conversations in > the next few days to be open and transparent and involving the > community, and look forward to discussing the best way(s) forward in > the coming weeks. Thanks. I am really happy you are actively involved. I also want to thank Bradley and Karen from the SFC for calling into the discussion. But the discussion at Cauldron seemed really chaotic, I have trouble trying to summarize it. I posted my original discussion notes and first impressions here: https://gnu.wildebeest.org/blog/mjw/2022/09/18/sourceware-infrastructure-conservancy-gnu-toolchain-at-cauldron/ We agreed to continue the discussion on this mailinglist. Hopefully that will be a little more productive and structured. Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-18 16:27 ` Mark Wielaard @ 2022-09-18 21:38 ` Mark Wielaard 2022-09-19 21:09 ` Mark Wielaard 2022-09-26 22:04 ` Carlos O'Donell 0 siblings, 2 replies; 15+ messages in thread From: Mark Wielaard @ 2022-09-18 21:38 UTC (permalink / raw) To: Overseers Hi all, On Sun, Sep 18, 2022 at 06:27:33PM +0200, Mark Wielaard via Overseers wrote: > But the discussion at Cauldron seemed really chaotic, I > have trouble trying to summarize it. I posted my original discussion > notes and first impressions here: > https://gnu.wildebeest.org/blog/mjw/2022/09/18/sourceware-infrastructure-conservancy-gnu-toolchain-at-cauldron/ > > We agreed to continue the discussion on this mailinglist. Hopefully > that will be a little more productive and structured. I tried to write up some notes from the discussion at Cauldron on my flight back to the Netherlands. It is somewhat unfortunate that there were so many interruptions and that apparently some people had missed some parts of the public discussions we have had on this list and in the public chats with the SFC. I thought we had over-communicated, but apparently we still missed to include people in the conversation. I honestly believed we had explicitly invited them earlier. These are somewhat random since I was a bit too flabergasted about what happened that I didn't make real notes. Please feel free to correct any misinterpretations. - Apparently our message of "everything is fine, we don't have any funding needs at this time, we are just thinking about the future" made some people think they couldn't sponsor at all. But I am happy people are so eager to sponsor. I wonder how we can adjust our messaging to be clear that financial contributions are of course always welcome. It is certainly not a bad thing to have some backup money in case of emergency. - Somewhat similarly there seemed to be the concern that when we do formulate some technical goals that we could use funding for that the Conservancy would be unable to help with fundraising events. But from our discussions with the SFC this is precisely one of the services the Conservancy offers. - As far as I understand there is no reason not to try to also raise funds through the Linux Foundation if that is easier for some companies. The Conservancy already does help projects that get some funding through the Linux Foundation. - There were several different kind of "security concerns" which would be good to untangle: - There is the concern of he security of the sourceware server itself. We discussed that in one of the public chats with the SFC and the recommendation was to see if we could maybe hire a penetration testing firm to see if we missed anything. - There is the "hardening" concern of separating unix user accounts for separate services like running git hooks. This is one of the things that the buildbot service offers. We could also adopt something like gitolite. - There is the secure software supply chain idea. This is one of the things I wanted to discuss now that we have services like public-inbox and tools like b4 for patch attestation. Sourceware offers the services for that, but it really is a policy question for the guest projects whether they use that (and for example whether to use signed git commits). - Although it is true that there is a GNU Toolchain with the FSF as fiscal sponsor and that the separate GNU projects work together using that name, it wasn't clear to me when in this discussion we were talking about the gdb, binutils, glibc and gcc projects collectively. From other discussions during Cauldron it was very clear that although each project is hosted on sourceware and using some of the same services, each one has its own policies which make sense for their separate communities. - I wasn't really sure what to make of this LF/GTI proposal. It seemed to conflate separate concerns that we were explicitly trying to avoid with our Sourceware as Conservancy member proposal. It seemed to mix explicit fundraising with advocating for a certain "managed services at the LF/IT" technical proposal for using those funds. And setting up yet another fiscal sponsor? Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-18 21:38 ` Mark Wielaard @ 2022-09-19 21:09 ` Mark Wielaard 2022-09-26 22:04 ` Carlos O'Donell 1 sibling, 0 replies; 15+ messages in thread From: Mark Wielaard @ 2022-09-19 21:09 UTC (permalink / raw) To: Overseers mailing list And here are some (my client connected and disconnected a lot, so I might have missed some) relevant #overseers irc logs with comments from people participating remotely: bkuhn: As part of answer to the question of “is SFC's capable of fundraising for its projects?” https://sfconservancy.org/docs/software-freedom-conservancy_Form-990_fy-2020.pdf and https://sfconservancy.org/docs/software-freedom-conservancy_independent-audit_fy-2020.pdf#page=11 karen: I didn't include it in my estimation of our grant funding but I am currently at the signing paperwork stage for a $450k grant from a major grantmaker bkuhn: I agree with codonell that you need a plan, but the *plan* (including costs) has to come before doing any fundraising, and for a FOSS initiative that plan should be publicly available. That's one of the things that SFC helps its projects do. serhei: so there was an entire presentation on infrastructure that got skipped over :) the infrastructure is being implemented as frugally as possible according to unix philosophy, but there are potential ideas to develop it further with either fixed or ongoing costs. fche: https://gnu.wildebeest.org/~mark/sourceware/presentation.html << the talk, as prepared bkuhn: I do want to note that dje mentioned Yocto as an example of what LF can provide. I note that Yocto's infrastructure is proprietary software, including even for the mailing lists. https://lists.yoctoproject.org/g/yocto https://lwn.net/Articles/700479/ serhei: it is going to take time to lower the temperature from the way this has been announced & incorporate those into a more credible proposal karen: I was just noting that SFC has close relationships with RH and have been talking to them about this (and other things) in a productive way bkuhn: We are too … we at SFC advise all our projects to write up a very clear proposal for their project plan, ideally on that is for two years out. We then encourage the projects to attach specific currency amounts and lists of hours of staff/contractor time needed for each thing during those two years. and then get a bottom line number, and THAT plus 15-20% (for safety, in case you under budgeted) is your fundraising target you show that plan to the public and your potential funders, and say: "Do you want to fund this?" The problem with seeking funding FIRST before the plan is clear is that it gives funders the opportunities to lobby you to do it differently than the community wants. We see it all the time, it happens to every organization that relies on contributions (as opposed to selling a product/service) to do its work. serhei: there's a term by Jane Jacobs 'catastrophic money' that encapsulates the risks of someone coming in and suddenly going "here is a pile of money" you end up building something completely different from what you would build when you have to be cautious with resources and you risk building something that is far less resilient bkuhn: SFC is absolutely willing to work with Overseers both on budget and making the plan a bit more ambitious. I do think it's unlikely 400k/year this soon can be used effectively, but I also think (and the Overseers will be annoyed I've said this) that they are not quite ambitious enough in the current plan. The clearly written plan allows you to stick to your plan when you're tempted by 💰💰💰 to just do it "slightly different" … because, slowly it becomes it's not so slightly, and then next thing you know, you're a year out and are like "Um, why are we doing what the funders want rather than what we want?" Note that the mailing list thread on overseers@sourceware is a good place to further this discussion. I'd really love to see someone post a summary of the session to that thread. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-18 21:38 ` Mark Wielaard 2022-09-19 21:09 ` Mark Wielaard @ 2022-09-26 22:04 ` Carlos O'Donell 2022-09-27 1:31 ` Alexandre Oliva ` (2 more replies) 1 sibling, 3 replies; 15+ messages in thread From: Carlos O'Donell @ 2022-09-26 22:04 UTC (permalink / raw) To: Overseers mailing list; +Cc: Mark Wielaard On 9/18/22 17:38, Mark Wielaard via Overseers wrote: > - There were several different kind of "security concerns" which would > be good to untangle: > > - There is the concern of he security of the sourceware server > itself. We discussed that in one of the public chats with the SFC > and the recommendation was to see if we could maybe hire a > penetration testing firm to see if we missed anything. Discussed in the BoF were a few additional items: - Defense in depth - Multiple servers, each with distinct services. - Multiple servers for one service where possible. - If governments want to use FOSS tools directly, do we need to comply with security standards like a contractor would? - Does NIST SP 800 53r5 apply to Sourceware.org? - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf > - There is the "hardening" concern of separating unix user accounts > for separate services like running git hooks. This is one of the > things that the buildbot service offers. We could also adopt > something like gitolite. ... and run them on a distinct machine (which requires machine resources, and admin time, etc). Adopting gitolite is also a great step in the direction of not having real accounts for users of a services. > - There is the secure software supply chain idea. This is one of the > things I wanted to discuss now that we have services like > public-inbox and tools like b4 for patch attestation. Sourceware > offers the services for that, but it really is a policy question > for the guest projects whether they use that (and for example > whether to use signed git commits). I agree these are going to be policy questions for each project to discuss. Though the proposal to use managed services with the LF IT would align us with exactly the groups doing public-inbox, b4, patatt, and other work for the Kernel. We would be leveraging everything they've been doing, which we could also do, but the proposal is about having them support us instead. > - Although it is true that there is a GNU Toolchain with the FSF as > fiscal sponsor and that the separate GNU projects work together > using that name, it wasn't clear to me when in this discussion we > were talking about the gdb, binutils, glibc and gcc projects > collectively. From other discussions during Cauldron it was very > clear that although each project is hosted on sourceware and using > some of the same services, each one has its own policies which make > sense for their separate communities. Correct. The core GNU Toolchain projects in this case are gcc, binutils, glibc and gdb. We work to try and support each other as the "GNU Toolchain." We adopt best practices from each other, attend BoFs together, and discuss solutions to common problems using FOSS tooling that we could all adopt. > - I wasn't really sure what to make of this LF/GTI proposal. It seemed > to conflate separate concerns that we were explicitly trying to > avoid with our Sourceware as Conservancy member proposal. It seemed > to mix explicit fundraising with advocating for a certain "managed > services at the LF/IT" technical proposal for using those funds. And > setting up yet another fiscal sponsor? It is two proposals. A fiscal sponsor for infrastructure in the OpenSSF via the GNU Toolchain Infrastructure project at the Linux Foundation. A proposal to use managed services with the Linux Foundation IT for projects currently at sourceware.org. Technically speaking, I think the Linux Foundation IT, with their existing work with public-inbox (ahead of its time), b4, patatt, and more, means they are globally the best positioned to keep solving these problems and supporting the development of these FOSS tools for the linux kernel and others. Even more so for a distributed development model that we use for the GNU Toolchain. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-26 22:04 ` Carlos O'Donell @ 2022-09-27 1:31 ` Alexandre Oliva 2022-09-27 11:02 ` Mark Wielaard 2022-09-28 11:14 ` Frank Ch. Eigler 2 siblings, 0 replies; 15+ messages in thread From: Alexandre Oliva @ 2022-09-27 1:31 UTC (permalink / raw) To: Carlos O'Donell via Overseers; +Cc: Carlos O'Donell, Mark Wielaard On Sep 26, 2022, "Carlos O'Donell via Overseers" <overseers@sourceware.org> wrote: > - If governments want to use FOSS tools directly, do we need to comply with security > standards like a contractor would? > - Does NIST SP 800 53r5 apply to Sourceware.org? > - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf What's the theory about which if any of these various controls would apply to GNU toolchain packages, and what the "organization" would be whose goals, mission, etc should drive the choices for each applicable control? I mean, I imagine that, if any of these requirements apply to the LF, whose employees have exclusive write access to the ultimate upstream Linux repositoriess (torvalds, stable), it would have to enforce controls on this software development project it carries out, but I don't see whether or how this carries onto companies that package, test, validate, qualify and distribute, or vice-versa. Furthermore, when we bring the GNU Toolchain packages into the context, it's not at all clear that these controls clearly aimed at proprietary software development, processes and commercial arrangements would apply to individuals or groups of individuals that get together to develop software entirely in public, as in our case. Would packagers and redistributors each consider our communities as suppliers, as external systems, or each contributor as an external developer? If there are requirements for 2FA for "privileged" access (is write access to repositories privileged?) for commercial packagers and redistributors, do they carry over to the entire community? I don't even see that such a requirement is present, let alone that it extends to the community. (and I'm not even getting at the disconnect between access controls to code repositories and actually tracking code provenance and integrity, which is entirely unrelated with access controls to a shared repository, but currently accomplished by means of digital signing and secure hash-chaining of commits, including releases) It's certainly not the case in Linux the kernel, where patches are integrated by multiple parties into various community repositories and maintainers until they eventually make Torvalds' and then later stable trees. That's a fundamentally different structure from the one we've adopted, in which maintainers and contributors have write access to the master repositories. I'd appreciate a lot more details on what key features and corresponding 53r5 controls allegedly required for compliance a migration into LF infrastructure would bring, and what community organization changes, if any, these changes would require. It would be premature to as much as consider such a migration without understanding these implications, and without information about how any such requirements apply to our communities and redistributors, it all comes across as fear mongering; more so considering that nobody else seems to be taking this extreme position in which requirements must be met not only by commercial redistributors, but by every upstream project. Such extraordinary claims must be supported by equally extraordinary evidence, and I haven't seen any. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-26 22:04 ` Carlos O'Donell 2022-09-27 1:31 ` Alexandre Oliva @ 2022-09-27 11:02 ` Mark Wielaard 2022-09-28 11:14 ` Frank Ch. Eigler 2 siblings, 0 replies; 15+ messages in thread From: Mark Wielaard @ 2022-09-27 11:02 UTC (permalink / raw) To: Overseers mailing list; +Cc: Carlos O'Donell Hi Carlos, Thanks for joining the public discussion. On Mon, 2022-09-26 at 18:04 -0400, Carlos O'Donell via Overseers wrote: > - There is the "hardening" concern of separating unix user > > accounts > > for separate services like running git hooks. This is one of the > > things that the buildbot service offers. We could also adopt > > something like gitolite. > > ... and run them on a distinct machine (which requires machine resources, and admin > time, etc). > > Adopting gitolite is also a great step in the direction of not having real accounts > for users of a services. Lets add gitolite to the roadmap, I think it is a great idea to offer it to projects. I am running it personally for code.wildebeest.org, it is packaged and I know it is practically zero-maintenance to run. We can even run it inside a project specific container or vm to have more isolation. > Technically speaking, I think the Linux Foundation IT, with their existing work with > public-inbox (ahead of its time), b4, patatt, and more, means they are globally the > best positioned to keep solving these problems and supporting the development of > these FOSS tools for the linux kernel and others. Even more so for a distributed > development model that we use for the GNU Toolchain. I agree they do some nice work supporting those upstream tools and services. And I have been really happy that we now have our own public- inbox instance at https://inbox.sourceware.org/ There is a bit more background about using it with b4 including a discussion on patch attestation in the original BoF discussion presentation: https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide14 Press 'p' for presentation notes for some additional background/questions. Or see the raw markdown presentation: https://gnu.wildebeest.org/~mark/sourceware/sourceware.md b4 console session: https://gnu.wildebeest.org/~mark/sourceware/b4.session.txt Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-26 22:04 ` Carlos O'Donell 2022-09-27 1:31 ` Alexandre Oliva 2022-09-27 11:02 ` Mark Wielaard @ 2022-09-28 11:14 ` Frank Ch. Eigler 2022-09-30 13:38 ` Carlos O'Donell 2 siblings, 1 reply; 15+ messages in thread From: Frank Ch. Eigler @ 2022-09-28 11:14 UTC (permalink / raw) To: Overseers mailing list; +Cc: Carlos O'Donell, Mark Wielaard Hi - > - Defense in depth > - Multiple servers, each with distinct services. > - Multiple servers for one service where possible. Depends on the threat model. Which one are you concerned about? > - If governments want to use FOSS tools directly, do we need to > comply with security standards like a contractor would? > - Does NIST SP 800 53r5 apply to Sourceware.org? > [...] If we don't have evidence that it does, what is the purpose of bringing it up? > It is two proposals. > > A fiscal sponsor for infrastructure in the OpenSSF via the GNU > Toolchain Infrastructure project at the Linux Foundation. > > A proposal to use managed services with the Linux Foundation IT for > projects currently at sourceware.org. Are they separable? - FChE ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-28 11:14 ` Frank Ch. Eigler @ 2022-09-30 13:38 ` Carlos O'Donell 2022-10-02 14:55 ` Frank Ch. Eigler 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2022-09-30 13:38 UTC (permalink / raw) To: Frank Ch. Eigler, Overseers mailing list; +Cc: Mark Wielaard On 9/28/22 07:14, Frank Ch. Eigler wrote: > Hi - > > >> - Defense in depth >> - Multiple servers, each with distinct services. >> - Multiple servers for one service where possible. > > Depends on the threat model. Which one are you concerned about? Completely agree. Consider an attacker simply looking to disrupt services (DoS, DDos) using another service on the current system. The more services present on the system the more the opportunity to do this kind of attack. This isn't a full threat model, but they are prevalent enough that it is expected risk decreases as the number of services on the system decreases. The cost to manage goes up too, so there is a tradeoff that the projects using the service must decide is acceptable. >> - If governments want to use FOSS tools directly, do we need to >> comply with security standards like a contractor would? >> - Does NIST SP 800 53r5 apply to Sourceware.org? >> [...] > > If we don't have evidence that it does, what is the purpose of bringing it up? Two downstream users of our sources have cited NIST SP 800-53 as something they had to comply with, and I want to dig more into two possible scenarios: (a) Is there an expectation that upstream source control repositories need to meet this regulation as well as the downstreams? (b) If we met the regulation would it improve FOSS adoption and support downstream users? With the new "infrastructure" bugs in bugzilla I filed this: https://sourceware.org/bugzilla/show_bug.cgi?id=29629 I noted that gitlab and github both have slightly different technical answers to this question. >> It is two proposals. >> >> A fiscal sponsor for infrastructure in the OpenSSF via the GNU >> Toolchain Infrastructure project at the Linux Foundation. >> >> A proposal to use managed services with the Linux Foundation IT for >> projects currently at sourceware.org. > > Are they separable? They are, the fund is designed to support more than just managed services. The details are posted here: https://sourceware.org/pipermail/overseers/2022q3/018896.html -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-09-30 13:38 ` Carlos O'Donell @ 2022-10-02 14:55 ` Frank Ch. Eigler 2022-10-03 13:26 ` Siddhesh Poyarekar 0 siblings, 1 reply; 15+ messages in thread From: Frank Ch. Eigler @ 2022-10-02 14:55 UTC (permalink / raw) To: Carlos O'Donell; +Cc: Overseers mailing list, Mark Wielaard Hi - > >> - Defense in depth > >> - Multiple servers, each with distinct services. > >> - Multiple servers for one service where possible. > > > > Depends on the threat model. Which one are you concerned about? > Consider an attacker simply looking to disrupt services (DoS, DDos) > using another service on the current system. The more services > present on the system the more the opportunity to do this kind of > attack. I don't quite see the "more opportunity". If someone wants to take out a particular source hosting site, they'll go after it, whether or not the target site is sharing resources with others. We are fortunate to use fully decentralized source control systems, where full clones at developers - and at other services like github etc. - are routine, and permit work to continue. I'd be surprised to hear of any organization hoping to hurt free software development by DoS'ing the sites - it'd be a futile gesture. > >> - If governments want to use FOSS tools directly, do we need to > >> comply with security standards like a contractor would? > >> - Does NIST SP 800 53r5 apply to Sourceware.org? > >> [...] > > If we don't have evidence that it does, what is the purpose of > > bringing it up? > Two downstream users of our sources have cited NIST SP 800-53 as > something they had to comply with Downstream corporations distributing products based on FOSS are irrelevant to this question. > and I want to dig more into two possible scenarios: > > (a) Is there an expectation that upstream source control > repositories need to meet this regulation as well as the > downstreams? (b) If we met the regulation would it improve FOSS > adoption and support downstream users? I can only assume that you already have evidence/argument in the affirmative for these questions, otherwise why are we discussing any of this? Can we hear that evidence/argument please? > >> It is two proposals. > >> > >> A fiscal sponsor for infrastructure in the OpenSSF via the GNU > >> Toolchain Infrastructure project at the Linux Foundation. > >> > >> A proposal to use managed services with the Linux Foundation IT for > >> projects currently at sourceware.org. > > > > Are they separable? > > They are, the fund is designed to support more than just managed services. That's not quite the same thing. Are the funds available for novel things that the various development communities may start requesting, **instead of** redirecting the vast majority to LF-IT for managed services? Or, are managed services an inseparable component of this proposal? - FChE ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-10-02 14:55 ` Frank Ch. Eigler @ 2022-10-03 13:26 ` Siddhesh Poyarekar 2022-10-03 13:53 ` Frank Ch. Eigler 2022-10-03 15:55 ` Christopher Faylor 0 siblings, 2 replies; 15+ messages in thread From: Siddhesh Poyarekar @ 2022-10-03 13:26 UTC (permalink / raw) To: Overseers mailing list, Carlos O'Donell Cc: Frank Ch. Eigler, Mark Wielaard On 2022-10-02 10:55, Frank Ch. Eigler via Overseers wrote: > I don't quite see the "more opportunity". If someone wants to take > out a particular source hosting site, they'll go after it, whether or > not the target site is sharing resources with others. The point is that targeting all of sourceware would be easy with shared resources; compromising a single service leaves every other service on the machine vulnerable. In fact we've seen this in action multiple times in the past (although I doubt if they're actual exploit attempts, just load issues) with sourceware where one bogged down service ends up worsening experience for other services. It's pretty much standard practice today to isolate services into separate machines and/or containers depending on their criticality. > We are fortunate to use fully decentralized source control systems, > where full clones at developers - and at other services like github > etc. - are routine, and permit work to continue. I'd be surprised to > hear of any organization hoping to hurt free software development by > DoS'ing the sites - it'd be a futile gesture. At least for GNU toolchain we have never really blessed other clones. The only blessed way to get sources is via sourceware. Also a DoS is the least of our concerns. An unauthorized access could potentially end up compromising the integrity of *all* data on the system, which means multiple projects get affected in one fell swoop. Sid ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-10-03 13:26 ` Siddhesh Poyarekar @ 2022-10-03 13:53 ` Frank Ch. Eigler 2022-10-03 19:16 ` Mark Wielaard 2022-10-03 15:55 ` Christopher Faylor 1 sibling, 1 reply; 15+ messages in thread From: Frank Ch. Eigler @ 2022-10-03 13:53 UTC (permalink / raw) To: Overseers mailing list Cc: Carlos O'Donell, Siddhesh Poyarekar, Mark Wielaard Hi - > > We are fortunate to use fully decentralized source control systems, > > where full clones at developers - and at other services like github > > etc. - are routine, and permit work to continue. I'd be surprised to > > hear of any organization hoping to hurt free software development by > > DoS'ing the sites - it'd be a futile gesture. > > At least for GNU toolchain we have never really blessed other clones. The > only blessed way to get sources is via sourceware. This is easily corrected. Git mirrors at the FSF and other hosting systems can be stood up, today, at the projects' individual discretion. > Also a DoS is the least of our concerns. (And yet it was the example brought up.) > An unauthorized access could potentially end up compromising the > integrity of *all* data on the system, which means multiple projects > get affected in one fell swoop. We've discussed -integrity- previously, via git's native resistance, plus hypothetical per-project adoption of gpg signing & verification of hosted source content. https://sourceware.org/PR29615 - FChE ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-10-03 13:53 ` Frank Ch. Eigler @ 2022-10-03 19:16 ` Mark Wielaard 0 siblings, 0 replies; 15+ messages in thread From: Mark Wielaard @ 2022-10-03 19:16 UTC (permalink / raw) To: Overseers mailing list Hi, On Mon, Oct 03, 2022 at 09:53:17AM -0400, Frank Ch. Eigler via Overseers wrote: > > > We are fortunate to use fully decentralized source control systems, > > > where full clones at developers - and at other services like github > > > etc. - are routine, and permit work to continue. I'd be surprised to > > > hear of any organization hoping to hurt free software development by > > > DoS'ing the sites - it'd be a futile gesture. > > > > At least for GNU toolchain we have never really blessed other clones. The > > only blessed way to get sources is via sourceware. > > This is easily corrected. Git mirrors at the FSF and other hosting > systems can be stood up, today, at the projects' individual discretion. Note that sourceware git repos have an experimental mirror on sourcehut already https://git.sr.ht/~sourceware/ Which can also be used to sent patches through email from the webform as an alternative to git send-email or sending raw patches by email https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide18 Cheers, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Sourceware / GNU Toolchain at Cauldron 2022-10-03 13:26 ` Siddhesh Poyarekar 2022-10-03 13:53 ` Frank Ch. Eigler @ 2022-10-03 15:55 ` Christopher Faylor 1 sibling, 0 replies; 15+ messages in thread From: Christopher Faylor @ 2022-10-03 15:55 UTC (permalink / raw) To: Overseers mailing list On Mon, Oct 03, 2022 at 09:26:57AM -0400, Siddhesh Poyarekar wrote: >... You're bringing up concerns but, even if they are valid, they don't translate into requiring a wholesale transfer of control to another entity. It is not a given that the current overseers can't act to mitigate agreed-upon security issues, especially with the help of the SFC. Also, if these are really serious issues then this plan was developed in private for two years without raising the alarm. During that time, the people who claim that sourceware is in jeopardy have advanced the issues as bullet points in presentations to the LF and friends. IMO, if these really are serious concerns, they should have been discussed here much earlier, without prompting, so that we could work through what needs to be done. It's like noticing that your neighbor's windows are open and working in secret to acquire the house out from under them so that you can close them "for their own good". cgf ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-10-03 19:16 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-16 20:57 Sourceware / GNU Toolchain at Cauldron Zoë Kooyman 2022-09-16 21:10 ` Ian Kelling 2022-09-18 16:27 ` Mark Wielaard 2022-09-18 21:38 ` Mark Wielaard 2022-09-19 21:09 ` Mark Wielaard 2022-09-26 22:04 ` Carlos O'Donell 2022-09-27 1:31 ` Alexandre Oliva 2022-09-27 11:02 ` Mark Wielaard 2022-09-28 11:14 ` Frank Ch. Eigler 2022-09-30 13:38 ` Carlos O'Donell 2022-10-02 14:55 ` Frank Ch. Eigler 2022-10-03 13:26 ` Siddhesh Poyarekar 2022-10-03 13:53 ` Frank Ch. Eigler 2022-10-03 19:16 ` Mark Wielaard 2022-10-03 15:55 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).