Re: Re: [RFC] Migrating to GitHub issues
| From: | Matthew Weier O'Phinney | Date: | Thu, 18 Nov 2021 13:53:22 +0000 |
| Subject: | Re: Re: [RFC] Migrating to GitHub issues | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116448@lists.php.net to get a copy of this message | ||
On Thu, Nov 18, 2021, 7:32 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT <patrickallaert@php.net>
> wrote:
>
> > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker <cmbecker69@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
>