From: "Jakub Narebski" <jnareb@xxxxxxxxx> Sent: Friday, February 10, 2012
7:38 PM
On Tue, 7 Feb 2012, Johan Herland wrote:
(we are pretty much in violent agreement, so I will only comment where
I find it necessary)
So now comes the hard part: actually implementing (well, designing and
implementing) prototypes for 'secret' trait and 'public' trait...
It all sounds very sensible.
The one additional implemenation idea I'd like is to have, which is somewhat
at a tangent to the secrecy issue, is having some record of what was pushed
(made Public). For the sub-module case this is so that its super project can
know if its submodules are public or not. A public super project that has
'secret' sub-modules is awkward to say the least.
That's my thought anyway...
On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> Also, when thinking about different scenarios of why one would like to
> mark commit as 'secret', we might want to be able to mark commit as
> secret / unpublishable with respect to _subset_ of remotes, so e.g.
> I am prevented from accidentally publishing commits marked as 'secret'
> to public repository, or to CI/QA repository, but I can push (perhaps
> with warning) to group repository, together with 'secret'-ness state
> of said commit...
>
> ... though it wouldn't be as much 'secret' as 'confidential' ;-)
Another way to achieve this would be to have a config flag to control
whether Git checks for the 'secret' flag before pushing. This config
flag could be set at the system/user level (to enable/disable the
feature as a whole), at the repo level (to enable/disable it in a
given repo), at the remote level (to enable/disable it on a given
repo), and finally at the branch level (to enable-disable it for a
given branch (and its upstream)). Thus you could have a .git/config
that looked like this:
[core]
refusePushSecret = true
[remote "foo"]
refusePushSecret = false
url = ...
fetch = ...
[branch "baz"]
remote = foo
merge = refs/heads/baz
refusePushSecret = true
This config would:
- refuse to push 'secret' commits from branch 'baz'
(branch.baz.refusePushSecret == true)
- but allow to push other branches with 'secret' commits to remote
'foo' (remote.foo.refusePushSecret == false)
- but refuse to push 'secret' commits to other remotes
(core.refusePushSecret == true)
(The order of precedence would be: branch config > remote config >
repo config > user config > system config > default when unset)
You read my mind.
I am unsure whether the 'secret'-ness of a commit should follow across
the push, but if you do (assuming we store the 'secret' flag using
git-notes) this is simply a matter of synchronizing the
refs/notes/secret to the same remote.
I think it should, so that 'secret' commit would not escape by accident
via a group secret repository.
What makes it hard (I think) is that we would prefer to transfer
'secret'-ness only for pushed commits. That might be problem for notes
based implementation of 'secret' annotation and 'secret'-ness transfer...
though I guess knowing that there exist 'secret' commit with given SHA1
which we do not have and should not have is not much breach of
confidentiality. Still...
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4801 - Release Date: 02/10/12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html