[bind10-dev] Subversion to Git conversion

[Shane Kerr]

Michal,

On Wed, 2010-10-20 at 07:59 +0200, Michal 'vorner' Vaner wrote:
> On Wed, Oct 20, 2010 at 12:47:19PM +0900, JINMEI Tatuya / 神明達哉 wrote:
> > Assuming my understanding is correct, can that be done easily and
> > without much risk of accidental disclosure?  I guess we run some cron
> > script that normally pulls "everything", but if the expected operation
> > is that someone sets up a filter when we start a security branch, I'm
> > afraid it's susceptible to human operational errors.  If we use a
> > specific convention on branch names such as "security-xxx" with a
> > filter rule that always works, it may be better than human
> > intervention, but there's still a risk that we misspelled the branch
> > name.
> 
> Well, I proposed a post-push hook, that would push it from the master
> repository. First, pull does full copy, push sends only what you tell it to, so
> you can just have something:

The current proposal uses a push for this reason.

Thinking about Jinmei's points, maybe it makes more sense to simply turn
off the push when we are working on a security issue. That way there
will be less chance of error and accidentally leaking the problem.

> > A related point is where/how we handle security bugs with trac.  If we
> > use the "sensitive" bit of the trac ticket system, it may have a
> > similar problem as not pulling the repository, that is, the fact that
> > we have a trac ticket that is invisible to everyone (while most of the
> > other tickets are open) may disclose some information.
> 
> We said we would have the sensitive set as default and unset it as developers if
> OK, I guess. And, maybe, having numbers chosen randomly would be nice too, if it
> is a reasonable option.

What we decided was that we will have all new tickets start off as
sensitive, and that it will be someone's job to go through these and
mark them as non-sensitive if they are.

We haven't implemented this yet, but we will do so either when we get a
production user, or sometime during the next year when I hope to
convince ISC's support team to do this (whichever comes first).

--
Shane