From dev-return-49382-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Fri May 22 11:43:46 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6CFF8180661 for ; Fri, 22 May 2020 13:43:46 +0200 (CEST) Received: (qmail 51448 invoked by uid 500); 22 May 2020 11:43:45 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 51369 invoked by uid 99); 22 May 2020 11:43:45 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.42) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 May 2020 11:43:45 +0000 Received: from [10.0.0.6] (business-90-187-221-197.pool2.vodafone-ip.de [90.187.221.197]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 062942E54; Fri, 22 May 2020 11:43:44 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: [PROPOSAL] Future security announcement policy From: Jan Lehnardt In-Reply-To: Date: Fri, 22 May 2020 13:43:43 +0200 Cc: security@couchdb.apache.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.3445.104.14) 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=E2=80=99d advocate to = include severity and mitigation information in broad strokes at least. I=E2=80=99m +0 on making the change. Best Jan =E2=80=94 > On 22. May 2020, at 13:38, Robert Samuel Newson = wrote: >=20 > Hi All, >=20 > We've just published a CVE and it made me think about our current = announcement policy. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > 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)? >=20 > B. >=20