On Thu, Nov 18, 2021, 7:32 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT <patrickalla...@php.net> > wrote: > > > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecke...@gmx.de> a > > écrit : > > > Right. An alternative might be to let users report security issues to > > > the security mailing list, where, if the issue turns out not to be a > > > security issue, the reporter could still be asked to submit a GH issue > > > about the bug. In that case it might be useful to add more devs to the > > > security mailing list. > > > > I was thinking about the same. Can't we work with security issues with > > mailing list *only*? > > It doesn't feel optimal to keep bugs.php.net active for just security > > ones. > > I miss seeing the motivation for it. > > > > The problem with the security mailing list is that it's ephemeral -- > someone new can't look at past discussions before they were subscribed. > Additionally, it's not possible to make the issue and the whole > conversation around it public after the issue has been fixed. > With Laminas, we use an email alias to allow researchers to report to us. We then post the full report as a security issue on GitHub - it's a feature they rolled out late 2019/early 2020 that restricts visibility to maintainers initially, but allows inviting others to collaborate (we invite the reporter immediately, for instance). It also creates a private branch for collaboration. When the patch has been merged, you can mark the issue public. If the plan is to move to GH anyways, this could solve security reporting. > Regards, > Nikita >
