You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Samuel Newson <rn...@apache.org> on 2020/05/22 11:38:01 UTC
[PROPOSAL] Future security announcement policy
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.
Re: [PROPOSAL] Future security announcement policy
Posted by Jan Lehnardt <ja...@apache.org>.
> On 22. May 2020, at 13:48, Jonathan Hall <fl...@flimzy.com> wrote:
>
> An alternative, if we think this is somehow too revealing, would be to include a generic "This may contain security-related fixes" blurb in _every_ release announcement, to serve as a constant reminder that upgrading to the latest patch version is always wise.
>
> That said, I'm in favor of the proposed change. Anyone serious about exploiting security holes will already know, by watching the code changes
This reminded me of something. For a particularly egregious vulnerability that we absolutely do not want to make public in advance, we have a fallback variant of making a release off of a private branch. We have used this once in the past. Give that we have that fallback, I’m +0.5 on making the change :)
I’m not sure the “might” message would do much good.
Best
Jan
–
> , so I see the upside of informing potential victims as much higher than any possible downside of informing bad actors.
>
> Maybe I'm overlooking something, though, so I'll keep my vote to +0 for now.
>
> Jonathan
>
>
> On 5/22/20 1:43 PM, 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 <rn...@apache.org> 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.
>>>
Re: [PROPOSAL] Future security announcement policy
Posted by Jonathan Hall <fl...@flimzy.com>.
An alternative, if we think this is somehow too revealing, would be to
include a generic "This may contain security-related fixes" blurb in
_every_ release announcement, to serve as a constant reminder that
upgrading to the latest patch version is always wise.
That said, I'm in favor of the proposed change. Anyone serious about
exploiting security holes will already know, by watching the code
changes, so I see the upside of informing potential victims as much
higher than any possible downside of informing bad actors.
Maybe I'm overlooking something, though, so I'll keep my vote to +0 for now.
Jonathan
On 5/22/20 1:43 PM, 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 <rn...@apache.org> 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.
>>
Re: [PROPOSAL] Future security announcement policy
Posted by Jan Lehnardt <ja...@apache.org>.
Thanks Mark, that’s why I asked for security@ to be CC’d here.
As Joan noted, we’d rather not maintain a separate private repo
just for security releases. While git makes it feasible, the
whole process is a bit more involved and error prone.
Either way, we will always have at least a 72 vote + 24 hour
mirroring delay where folks might notice we didn’t cut the
release from the public repo and start looking through the
RC tarballs.
If I were eager to find security issues, I’d use that time
window either way and a release announcement that explains that
there is a security issue/severity/mitigation, but not which
exactly doesn’t make much of a difference.
Am I missing something?
Best
Jan
—
> On 22. May 2020, at 19:27, Mark J Cox <mj...@apache.org> wrote:
>
> On Fri, May 22, 2020 at 6:15 PM Joan Touzet <wo...@apache.org> wrote:
>
>> I'm curious what the Apache Security team's opinion is on this (they are
>> cc'ed on every email to security@couchdb.apache.org)
>
>
> The policy that OpenSSL has works because OpenSSL doesn't release the
> update at the time of that prenotification and usually the fix for the
> issue isn't in the repo; instead it's handled in private with the final
> commits and tarball going live around the same time as the advisory is
> published (all within an hour or so anyway). As stated in the thread, if
> you notify your users there is a security issue (or worse if you tell them
> it's a 'critical' one) in a tarball you've already released then you'll
> end up with people looking through the commits to find it so they can
> publish it or exploit it and then it creates a disclosure mess which we
> would not recommend.
>
> Regards, Mark
Re: [PROPOSAL] Future security announcement policy
Posted by Mark J Cox <mj...@apache.org>.
On Fri, May 22, 2020 at 6:15 PM Joan Touzet <wo...@apache.org> wrote:
> I'm curious what the Apache Security team's opinion is on this (they are
> cc'ed on every email to security@couchdb.apache.org)
The policy that OpenSSL has works because OpenSSL doesn't release the
update at the time of that prenotification and usually the fix for the
issue isn't in the repo; instead it's handled in private with the final
commits and tarball going live around the same time as the advisory is
published (all within an hour or so anyway). As stated in the thread, if
you notify your users there is a security issue (or worse if you tell them
it's a 'critical' one) in a tarball you've already released then you'll
end up with people looking through the commits to find it so they can
publish it or exploit it and then it creates a disclosure mess which we
would not recommend.
Regards, Mark
Re: [PROPOSAL] Future security announcement policy
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <wo...@apache.org> wrote:
>
> I'm curious what the Apache Security team's opinion is on this (they are cc'ed on every email to security@couchdb.apache.org).
>
> 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 <rn...@apache.org> 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.
>>>
Re: [PROPOSAL] Future security announcement policy
Posted by Joan Touzet <wo...@apache.org>.
I'm curious what the Apache Security team's opinion is on this (they are
cc'ed on every email to security@couchdb.apache.org).
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 <rn...@apache.org> 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.
>>
>
Re: [PROPOSAL] Future security announcement policy
Posted by Jan Lehnardt <ja...@apache.org>.
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 <rn...@apache.org> 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.
>