Jarek,
On 10/14/24 3:25 PM, Jarek Potiuk wrote:
Surely - there are different cases.
As usual we are humans and can make different decisions - if we see a high
profile case that is risky we might take a different decision. It's more
about "default" handling that we are talking about but it does not mean we
will compile it into executable and execute it exactly the same way every
time. There are lots of variations and inputs to the whole process - how
important and popular the project is, how important and severe the problem
is, what's the probability it is going to be high profile and exploited,
whether reporters actually ask for it etc. etc.
I think that's the role of the committee to make the decision eventually -
because that is the committee responsibility - but having a "default
blueprint" is a good thing.
I am not sure if we can foresee all the circumstances and cases - but maybe
indeed there is a way to build-in some kind framework with some exceptions
- maybe you could propose something there?
I think a proposal coming from me would look like what Phil came close
to proposing: that a project-on-the-stairs or even a project actually in
the Attic should, by default, get a response from the ASF that says "we
are really sorry but there isn't going to be a fix for your issue."
I guess it comes down to the process.
1. Security report is sent by the reporter to ASF sec or project-sec (or
both)
2. ASF sec waits X days for a response from project-sec.
3. If no response, ASF sec gives project-sec Y days to engage.
4. After Y days, ASF sec notifies the reporter that there will be no
fix[*], forcibly pushing the project into the Attic
* unless someone volunteers to resuscitate the project. Not sure how
that would work. If Amazon offers to "bring the project back to life" by
staffing it themselves, that's not probably something we are interested
in doing since we'll have a corporate-backed project at that point.
If the project was already in the Attic, I think the process is the
same. It might be tough to locate the PMC of the old project, so we'd
have to think about how that process works. But it's common to have PMCs
from one project also PMCs on another project, so even though the
project may be in the Attic, those PMC members might still be around and
reachable. Otherwise... #4.
-chris
On Mon, Oct 14, 2024 at 8:26 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
Jarek,
On 10/13/24 7:19 AM, Jarek Potiuk wrote:
How do we manage expectations for projects that might still release but
probably won’t and are in practice just waiting for somebody motivated
enough to call for a formal vote.
Maybe the right approach is to give such a project the last chance to
make a release and if they fail, move it to the attic (forcefully) if the
issue is "important" and the users are put in danger? That would be very
much in-line in our "for the public good" part of the mission of the ASF
-
protecting the users from harm being done.
I would agree with this decision, but we might have to be prepared for
"bad optics" in these situations.
Imagine this:
A CVE (or other security report) is announced against Apache
Problematic™ which is on the staircase. After X days, Apache
Problematic™ PMC hasn't responded in a meaningful way, and ASF has to
step-in. Users are asking what's up. Downstream projects are asking
what's up. Reporters are asking what's up.
ASF Security (or similar) makes an announcement that Apache Problematic™
is suddenly moving into the attic, there will be no fix. "Sorry,
everyone is out of luck."
I think this could make the ASF look bad in general. People might get
the idea that "ASF projects can disappear at any moment!". This is, of
course, already entirely true but not in the way that should cause concern.
I just don't want people to stop trusting Apache Commendable™ because we
have had a few Apache Problematic™-like incidents.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail:
security-discuss-h...@community.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
