Bug#652355: git-daemon-sysvinit: requires a switch to be flipped before it

January 06th, 2012 - 12:20 pm ET by Daniel Baumann | Report spam
sorry for the late answer.

first, the enable flag (and having it by default set to false is) is in
general a good thing. that way, a daemon does need to get manually
enabled by the admin. this appears to be specifically nice for daemons
such as git-daemon which might "suddenly" expose users data that he did
not necessarily want to in the first place. also, having no way to
disable the daemon but keeping it installed would be bad.

having said that, for git-daemon-sysvinit, the package doesn't actually
contain the daemon binaries but only the sysvinit integration, so it's
not necessarily required to have a switch off flag, a 'dpkg -P
git-daemon-sysvinit' or 'update-rc.d disable [...]' call would be
aequivalent. if a enabled=true/false flag should be kept for
convenience, rather than to trigger sysvinit or even packaging changes,
is your call.

the potential automatic exposure of user data doesn't seem to much of an
issue here, as git-daemon-sysvinit explicitly needs to be installed,
and, even if installed and enabled, it still needs to have a) some
repositories in the default location /var/cache/git *and* b) an
'attacker' would need to know the exact repo location.

[ unrelated to that, git-daemon-sysvinit actually doesn't work in the
default case anyway, due to a bug with the basepath, i'll send a patch
for that later these days; i had that in the original patch, but it got
dropped after some time during the process of getting it merged in the
git package itself. ]

or in other words, i personally don't really mind if there's a enable
flag or not.

if you intend to keep it, it should have a debconf question (priority
low) so that the package can be preseeded. this also holds true for the
directory location.

would you accept patches to add that support (for the directory
question, and, if you choose to keep it, also for the enable flag)?

Regards,
Daniel

Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/



To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 2 repliesReplies Make a reply

Similar topics

Replies

#1 Jonathan Nieder
January 06th, 2012 - 12:30 pm ET | Report spam
Hi Daniel,

Daniel Baumann wrote:

if a enabled=true/false flag should be kept for convenience,
rather than to trigger sysvinit or even packaging changes, is your call.



No, it's your call.

[...]
would you accept patches to add that support (for the directory question,
and, if you choose to keep it, also for the enable flag)?



I will accept any patches from you or approved by you concerning the
git-daemon-sysvinit package, unless they seem insane. It's yours. :)
(Of course Gerrit still has his say as co-maintainer.)

If I send a suggestion that seems like a bad idea to you, you can even
simply close it.

Thanks,
Jonathan



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Daniel Baumann
January 06th, 2012 - 12:30 pm ET | Report spam
On 01/06/2012 06:17 PM, Jonathan Nieder wrote:
if a enabled=true/false flag should be kept for convenience,
rather than to trigger sysvinit or even packaging changes, is your call.



No, it's your call.



i personally, for the interest of keeping daemon configs on the
principle of last surprise, and in the absent of any better debian-wide
unified mechanism for having a way to enable/disable daemons, i would
keep it, add a debconf question for it at priority low and defaulting to
yes. to me, that sounds like the best solution atm.

I will accept any patches from you or approved by you concerning the
git-daemon-sysvinit package, unless they seem insane.



heh, ok :)

i'll prepare a patch doing above then and attach it to this bug report
(probably tomorrow).

Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:
Internet: http://people.progress-technologies.net/~daniel.baumann/



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search