From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 942943858D32 for ; Fri, 7 Apr 2023 20:44:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 942943858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680900260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FXGZ19XgzhOJnMynxA8PSgVa5iEWjaxSdozHDTOn6po=; b=WqABg624EnYgT51LA2Ue2jzYsmG0H9d9YYyjx8pN9i0sfK0pgcEVCLRi2lFJcHyrv/9Yw9 IEM/N2yEFrT8KDmz6R8QamS9NxhbWtUwPAcEDp3sPrDOHF3TO9XgrTnKuMJcAsIY0aCjxI tPUnED7Yyfph/dLcYUMG8+OsQp265+k= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-671-Q8Zrj84YMYG6gYlvsqMa2A-1; Fri, 07 Apr 2023 16:44:18 -0400 X-MC-Unique: Q8Zrj84YMYG6gYlvsqMa2A-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0848F3822DE3; Fri, 7 Apr 2023 20:44:18 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ECB91492B00; Fri, 7 Apr 2023 20:44:17 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1pkswT-0002nE-2Y; Fri, 07 Apr 2023 16:44:17 -0400 Date: Fri, 7 Apr 2023 16:44:17 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: Some ideas for process improvements/changes Message-ID: <20230407204417.GC10746@redhat.com> References: <11b1c515a2a0ed2af0c72ac6437aca81ba0806a7.camel@klomp.org> <20230406173420.GA10746@redhat.com> <20230406215749.GC18331@gnu.wildebeest.org> <20230407005600.GB10746@redhat.com> <20230407202631.GK18331@gnu.wildebeest.org> MIME-Version: 1.0 In-Reply-To: <20230407202631.GK18331@gnu.wildebeest.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi - > Very nice. I would not have been able to describe things so > nicely. Thanks. My pleasure! > > - email to > > - email to > > - email to > > I am happy to receive such reports. And I trust the secalert team at > Red Hat. But I would like to hear from other distro maintainers what > they think of this policy. I would like to not give one distro or > corporate entity preferred early notification of suspected security > issues. I believe there is an inter-company mailing list for high profile security issues. We'd eventually hear back from the RH reps on that list. Heck, our own RH reps could/would forward things there for high severity things that come initially to you or me. > Also I think we should explicitly add something like: > > We are happy to keep the security implication of a bug, or a proof > of concept exploit private. But unless the bug is critical we'll > resolve the underlying issue through the normal project development > processes, without mentioning the security vulnerability itself. I can't think of much harm to mentioning security vulnerabilities by name, should they rise to the levels to justify issuance of them at all. That is, we need not hide genuine security issues that happen to be low severity. We just wouldn't treat them with embargo or emergency haste, but that's okay. > To make clear we aren't going to play security embargo theater. Not sure that's fair -- in my experience, security embargos serve a useful purpose: in coordinating the release of a fix among distros. That minimizes the window of vulnerability of the entire user base between the problem becoming public and distributing its fix. They are thankfully rare. - FChE