[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231014125330.72sxum33ud5sizix@yuggoth.org>
Date: Sat, 14 Oct 2023 12:53:30 +0000
From: Jeremy Stanley <fungi@...goth.org>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list membership application - CIQ
Rocky Linux Security Team
On 2023-10-13 23:19:18 -0400 (-0400), Neal Gompa wrote:
[...]
> The point I'm making is that SIGs do not count because they cannot
> obey embargo regulations. No open project or community project can
> do that without having some mechanism for private controls, which
> is antithetical to the community process. They fundamentally are
> ineligible to join because they cannot keep anything secret.
This is the part of your argument I understand the least. Is your
objection specific to the Rocky Linux community's definition of the
term "Special Interest Group," or a preconceived notion on your part
as to what that term means more generally, or an opinion that
volunteer community members are simply incapable of maintaining
embargoes and only people employed by a company to that purpose are
able to do so reliably?
I participate in an open software community, as a member of subteam
on a SIG with a mandate to perform vulnerability management on
behalf of the rest of the community. We set and manage the project's
embargoes and coordinate its public disclosure process (including
supplying advance notice to the linux-distros list as well as other
downstream stakeholders).
When we've experienced premature disclosures, it's been because
developers under the employ of a particular distribution have felt
pressured to notify their managers or employer's security group
about the fixes they're writing, reviewing or testing in violation
of our embargo policies, not because of a failure on the part of of
SIG members. If anything, involving people employed by a commercial
distribution is a greater liability than involving community
volunteers who are not under those same sorts of pressures.
There are a number of tools which help provide long-term
transparency for such activities, including using a defect tracker
that supports eventually switching private reports to public,
following a published process for intake and coordination efforts,
community maintenance of testsuites which can be run locally on
developers' systems to test proposed fixes in private, agreeing on
conventions for a private code review process, etc.
Yes, trying to maintain the secrecy of embargoes is at odds to
participating in an open community project with publicly accessible
code review and CI/CD systems, it's been the subject of conference
talks I've given in the past, but it's not impossible to balance
these competing forces. I don't see how that would be different in a
GNU/Linux distribution than for any other large project.
--
Jeremy Stanley
Download attachment "signature.asc" of type "application/pgp-signature" (964 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
