public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
* 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: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

* 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

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).