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
Thanks Joan, I’m looking forward to Infra feedback.
Best
Jan
—
> On 22. May 2020, at 19:31, Joan Touzet wrote:
>
> I haven't gotten a lot of feedback on this proposal. (I know a lot of people
> are marching towards deadlines right now.) I also don't want to take it to
> users@, unless there's
On 2020-05-22 13:31, Joan Touzet wrote:
I haven't gotten a lot of feedback on this proposal. (I know a lot of
people are marching towards deadlines right now.) I also don't want to
take it to users@, unless there's a reality of it happening.
In the interest of moving this forward, I'm going to
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 releas
I haven't gotten a lot of feedback on this proposal. (I know a lot of
people are marching towards deadlines right now.) I also don't want to
take it to users@, unless there's a reality of it happening.
In the interest of moving this forward, I'm going to open an exploratory
issue with Infra to
On Fri, May 22, 2020 at 6:15 PM Joan Touzet wrote:
> I'm curious what the Apache Security team's opinion is on this (they are
> cc'ed on every email to secur...@couchdb.apache.org)
The policy that OpenSSL has works because OpenSSL doesn't release the
update at the time of that prenotification a
I'm curious what the Apache Security team's opinion is on this (they are
cc'ed on every email to secur...@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 agre
> On 22. May 2020, at 13:48, Jonathan Hall 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
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 pr
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 th
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 public
11 matches
Mail list logo
