Hi, I side with Jan that the "we've always got security patches in every release" idea is pointless. The purpose of this thread is whether we should tell users that a release has a security fix, to encourage them to upgrade urgently.
Unless we can hide security commits entirely until the release is published, there's only shades of grey here. All our security related fixes are visible for days or weeks ahead of any release. We don't draw attention to them, and erlang is a dark and obscure art (if done correctly), but even so, they are public. I take your point, and Mark's, but I do think it's a little optimistic to think that folks aren't looking at the commits as they happen, and scrutinising the releases, if they are motivated to find exploitable security issues. That said, perhaps we can find, or invent, an ASF approved means to delay publication of security related fixes until the release. The voting period does seem to make that impossible, though. Is the current situation the best we, or any Apache project, can do? B. > On 22 May 2020, at 18:15, Joan Touzet <[email protected]> wrote: > > I'm curious what the Apache Security team's opinion is on this (they are > cc'ed on every email to [email protected]). > > The detailed policy for the ASF is here: > > https://www.apache.org/security/committers.html > > The only reference here to public/private is step 11: > > > The project team agrees the fix, the announcement and the release > > schedule with the reporter. > > And then in step 15, the vulnerability release is announced: > > > after, or at the same time as, the release announcement. > > It says nothing about saying "something's coming," for or against. > > The problem I see is that if people know a problem is about to be resolved, > they will look at version control closely to see if they can spot what the > fix is. Because the release process takes a minimum of 4 days - 3 days for > the vote to pass, and 24 hours for the mirrors to update - this could leave > unpatched people more exposed for longer than they would with a "0-day". > > To work around this and always give people a heads up on a release, we'd be > forced into preparing all high-profile security releases in private. I did > *not* enjoy when we had to do this last time (2.3.0 or 2.3.1, I think), and > I'm sure no one else in the process did, either. > > The "we've always got security patches in every release" isn't a bad one, but > it could be a lie. We don't always fix security things. Personally I'd rather > be honest (and surprise people with a patch) than lie and tell people there's > patches when there aren't any. > > -Joan "would like to know more from security@ first" Touzet > > > On 2020-05-22 7:43, Jan Lehnardt wrote: >> I like the OpenSSL announcements and their categorisation. They allow me to >> decide, whether I have to pencil in an upgrade for the date of the release >> or not. So *if* we decide to do this, I’d advocate to include severity and >> mitigation information in broad strokes at least. >> I’m +0 on making the change. >> Best >> Jan >> — >>> On 22. May 2020, at 13:38, Robert Samuel Newson <[email protected]> wrote: >>> >>> Hi All, >>> >>> We've just published a CVE and it made me think about our current >>> announcement policy. >>> >>> Currently, when we receive notice of a security issue, the PMC investigate >>> it, fix it if it's genuine, then we prepare and publish a release without >>> mentioning the security issue. A week after publication we publish the CVE. >>> >>> I think we can do better. I follow haproxy and openssl announcements for >>> security reasons and have found their early warning very helpful. I wonder >>> if we can do something similar? >>> >>> My proposal is modest. Everything stays the same as today except we >>> announce that there is a security fix in the release _at the time we >>> publish it_. The details are withheld for the regular 7 day period. >>> >>> Are there objections to that step? Should we do more? Would it useful to >>> categorise the security issue (low, medium, high. whether it is present in >>> the default config. whether it can be mitigated without taking the upgrade)? >>> >>> B. >>>
