Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: On reporting issues with potential security implications
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <CAE5jQCeQfyPu7T4mHutYwUjK04P8MyYS8NmTC8pm4sZkHQRRNA@mail.gmail.com>
Date:   Thu, 5 Mar 2020 12:07:53 +0100
Cc:     Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <BE6FA083-5826-4A77-8EF3-D5485D421AA9@holtmann.org>
References: <CAE5jQCeQfyPu7T4mHutYwUjK04P8MyYS8NmTC8pm4sZkHQRRNA@mail.gmail.com>
To:     Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Anatoly,

> Many projects have some private mail list or some other policies for
> reporting issues with possible security implications. I mean some bugs
> that the reporter cannot qualify for sure as a "safe to publicly
> disclose" (still, they can turn out to be not security-related after
> review).
> 
> BlueZ, on the other hand, has a policy of "never write to them
> [developers] directly" and no easily grep-able guidelines on reporting
> possibly security-related issues. So, what is the preferred way for
> reporting such things?

unless they are high severity issues that are remotely exploitable to gain root access, I personally have no problem if they are reporting directly to the public mailing list.

For example we have test utilities and development utilities that don’t normally run in production systems. We will fix every issue reported, but they are just bugs and not security issues.

Regards

Marcel