develooper Front page | perl.perl5.porters | Postings from July 2019

Re: We plan to transition from RT to GitHub

Thread Previous | Thread Next
From:
Richard Leach
Date:
July 8, 2019 16:06
Subject:
Re: We plan to transition from RT to GitHub
Message ID:
CADWSe2ccSVA9TE3LwZi7TOpF5p5O7TfFq_HrFC6dL4X9VuRF+w@mail.gmail.com
On Fri, Jul 5, 2019 at 10:22 AM <hv@crypt.org> wrote:
> - where will security issues go, how will they get there, from whom will
> they be secure?

Issues can't be marked as private. Many people seem to have asked or
+1 this, but it's still not a thing.

https://github.com/go-gitea/gitea/issues/7278
https://github.com/go-gitea/gitea/issues/3217
https://github.com/isaacs/github/issues/37

There is the model where you have a private repo for code and a
separate public repo for issues. Don't know if that model could be
flipped around to have a public code & issues repo, plus a separate
private security issues repo, but not sure how reporting would work.
Perhaps security bugs would still have to be reported by email, which
gets turned into a private repo issue? But it's unclear then how much
work it would be for the security team to move/copy a resolved
security issue to the public queue. :-(

> - where will git branches for security issues go, from whom will they be
> secure?

Same as above? If the private repo is a fork of the public one, Pull
Requests could be made from private->public at least.

>
> - in particular, at a github corporate/infrastructure level, who will have
> access to information relating to perl security issues?
>
> Also, if we start to accept (or even encourage) patch submission by means
> of pull request, I imagine github provides a handy merge button that would
> merge the branch to blead without rebasing it over blead.
>
> Though I'm aware there are strongly held opinions on both sides of this
> issue, I hope we won't start allowing such non-linear merges: IIRC we saw
> a bit of havoc the last time one was done (manually) in blead, and in
> various work projects I've found such merges to be a regular and significant
> source of bugs, and also substantially to impede the ability to discover
> historic information when you need it (eg by bisection).
>
> Hugo

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About