dangerous branch names in the security repository

[p5pRT]

Migrated from rt.perl.org#116839 (status was 'open')

Searchable as RT116839$

[p5pRT]

From @nwc10

Right now the branch names for blead and maint-* are the same in the
security repository. This makes it way to easy to push to the wrong one.
(As Yves accidentally demonstrated)

If we don't change this, that won't be the last time :-(

In another message, I suggested​:

1) change the branch names to sec-blead, sec-maint-5.16 etc in the security
  repository
2) put a hook in it to forbid branches that don't start /^sec-/
3) put a hook in the main repository to forbid branches that do start /^sec-/

I think that this will solve the problem, without making life too hard for
anyone working on stuff.

Should we do this?
Is there a better way?

Nicholas Clark

[p5pRT]

From @nwc10

On Mon Feb 18 07​:07​:35 2013, nicholas wrote​:

Forgot the PS - I think that this ticket can go public once
CVE-2013-1667 is public.

Nicholas Clark

[p5pRT]

@nwc10 - Status changed from 'new' to 'open'

[p5pRT]

From @demerphq

On Mon Feb 18 07​:07​:35 2013, nicholas wrote​:

Right now the branch names for blead and maint-* are the same in the
security repository. This makes it way to easy to push to the wrong
one.
(As Yves accidentally demonstrated)

If we don't change this, that won't be the last time :-(

In another message, I suggested​:

1) change the branch names to sec-blead, sec-maint-5.16 etc in the
security
repository
2) put a hook in it to forbid branches that don't start /^sec-/
3) put a hook in the main repository to forbid branches that do start
/^sec-/

I think that this will solve the problem, without making life too hard
for
anyone working on stuff.

Should we do this?
Is there a better way?

Well if people set up their remotes properly, unlike me, then it is less
likely to be an issue, but IMO yes we should.

I think as part of this ticket we should also figure out how to ensure
that certain branches, such as blead, stay up to date in the perlsec.git
repo.

Yves