Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: [PATCH] Preserve the protection mode for the Git config files

From: Nanako Shiraishi <hidden>
Date: 2016-06-15 22:47:05

Quoting Junio C Hamano [off-list ref]
This change in behaviour is justifiable only because the only thing the
user who said "core.sharedrepository = true" cares about is that refs are
readable by the group members (otherwise s/he would have used a more
explicit setting like "core.sharedrepository = 0660", and the
adjust_shared_perm() code will do the right thing, with or without your
patch).

The patch description must defend itself a bit better, perhaps by saying
something like this at the end.

	This patch touches the codepath that affects not just .git/config
	but other files like the index and the loose refs, so they also
	inherit the original protection bits.  In a private repository,
	this is not an issue exactly because the repository is private,

	In a shared repository, a later call made in this function to
	adjust_shared_perm() widens the permission bits as configured.
	Because adjust_shared_perm() is designed to do so from any mode
	limited by user's umask, even though this patch changes the
	behaviour in the strict sense, it should not affect the outcome in
	a negative way and what is explicitly marked as allowed in the
	configuration will still be allowed.
I have two questions.

1. Why would you keep sensitive information in the config file in the first place? Wouldn't it be better to introduce a level of indirection, making a variable in the config file to point to a private file only you can read and store secrets in the latter?

2. Why is your config file more secret than your history? Wouldn't it solve your problem without any patch if you set core.sharedrepository to 0600?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help