* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 7:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211071235.GL15329@elie.Belkin>
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in their home directory to begin
> with, no?
I know nothing of the security issues, but why not have a
/etc/git-shell-commands?
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Junio C Hamano @ 2013-02-11 7:17 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211071235.GL15329@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in their home directory to begin
> with, no?
You can give one set of commands to some users while restricting
others, no?
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 7:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vliavpc4q.fsf@alter.siamese.dyndns.org>
On Mon, Feb 11, 2013 at 2:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> And for the remaining 20% of those who do not like the canned
> message but still do not need any custom command, I think it is way
> suboptimal to force them to create git-shell-commands directory for
> 47 users his host gives git-shell access to, and copy the "help"
> script to all of them, only to get a customized message. It would
> help them quite a lot if you just called /etc/git/shell-disabled or
> some hook that generates a customized message; then there is no need
> to add any git-shell-commands directory and a "help" script every
> time he gets one new user, no?
>
> For those who _do_ want to give customized commands to their users,
> they can already have "help" script to give a friendly message. It
> just felt silly to force sites to create the directory only to
> refuse an access to the "custom commands" feature, especially when
> the existence of that directory is a signal that the site may want
> to give its users an acess to that feature.
Again, would it not be more elegant and powerful to A) have the
shell-disabled message/hook/etc specified by git-config on some level,
be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch
whereby ~/git-shell-commands/help returning non-zero closes the
connection? Have shell.c read for settings in the pattern:
[shell "disabled"]
message = "Hi, this is your server speaking. I've
replaced the usual message."
command = "/path/to/some/command"
If shell.disabled.command is defined, don't bother with the message.
If it is not, but shell.disabled.message is, display that. If neither
of them are, display the default message, and make that one more
friendly.
Even if that was implemented, there is still an argument for
Jonathan's patch. For example, I'm building a server where
~/git-shell-commands/help does something interesting. But sometimes,
something fails. When that something fails, I want to close the
connection for whatever reason.
So, any reason not to have both (on top of making a better default message)?
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command
From: Junio C Hamano @ 2013-02-11 7:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Sitaram Chamarty, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211055847.GG15329@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 4fe93203..60051e63 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or
> rename repositories, or change repository descriptions and
> permissions.
>
> +If the `help` command exists and exits with nonzero status, the
> +interactive shell is aborted.
> +
> +EXAMPLE
> +-------
> +
> +To disable interactive logins, displaying a greeting instead:
> ++
> +----------------
> +$ chsh -s /usr/bin/git-shell
> +$ mkdir $HOME/git-shell-commands
> +$ cat >$HOME/git-shell-commands/help <<\EOF
> +#!/bin/sh
> +printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
Where in the sshd to git-shell exec chain is $USER variable set for
the user? Just being curious if this is the simplest but one of the
more robust ways to get the user's name.
I still think forcing the site administrator create a directory for
each and every user only to house a single script that denies the
access is a wrong design, but the code seems to correctly implement
that design.
^ permalink raw reply
* Re: [PATCH 1/2] shell doc: emphasize purpose and security model
From: Jonathan Nieder @ 2013-02-11 7:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sitaram Chamarty, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vhaljpbpn.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> --- a/Documentation/git-shell.txt
>> +++ b/Documentation/git-shell.txt
>> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
>> SYNOPSIS
>> --------
>> [verse]
>> -'git shell' [-c <command> <argument>]
>> +'chsh' -s $(which git-shell) git
[...]
> "command -v"
Sounds good.
(chsh isn't in POSIX either, FWIW. ;-))
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 7:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vliavpc4q.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> The trouble is that I can't imagine a canned message that everyone
>> will like. (For example, I quite dislike the current one.) That's
>> exactly the situation in which some configurability is helpful.
>
> I am not saying we should have a perfect canned message everybody
> likes and not have any configurability. I however think we can aim
> to come up with a message that covers 80% of site administrators who
> do not care too much and just want git-shell to allow the standard
> services without giving any custom command.
Isn't the current message meant to be that? Just removing the "hint:"
line would be enough to leave me happy with it.
> And for the remaining 20% of those who do not like the canned
> message but still do not need any custom command, I think it is way
> suboptimal to force them to create git-shell-commands directory for
> 47 users his host gives git-shell access to, and copy the "help"
> script to all of them, only to get a customized message.
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login shell, then the
git-shell-commands should not go in their home directory to begin
with, no?
I think sharing a home directory is fine and the normal thing to do
with such a restricted account, fwiw, so I am not the one to guess
what people who do something different would find most useful. Maybe
I am not the right person to have proposed this patch in the first
place --- I saw something that looked wrong and proposed what I
thought was a reasonable fix, but I am not actively depending on
git-shell myself, so...
*shrug*
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/2] shell doc: emphasize purpose and security model
From: Junio C Hamano @ 2013-02-11 7:10 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Sitaram Chamarty, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211055752.GF15329@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 9b925060..4fe93203 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
> SYNOPSIS
> --------
> [verse]
> -'git shell' [-c <command> <argument>]
> +'chsh' -s $(which git-shell) git
<review type="nitpick" mode="posix-police">
Please don't use "which" in scripts. Perhaps "command -v" is more
suitable here.
</review>
Otherwise looks good to me. Thanks.
> +'git clone' `git@localhost:/path/to/repo.git`
> +'ssh' `git@localhost`
>
> DESCRIPTION
> -----------
>
> +This is a login shell for SSH accounts to provide restricted Git access.
> +It permits execution only of server-side Git commands implementing the
> +pull/push functionality, plus custom commands present in a subdirectory
> +named `git-shell-commands` in the user's home directory.
> +
> +COMMANDS
> +--------
> +
> +'git shell' accepts the following commands after the '-c' option:
> +
> +'git receive-pack <argument>'::
> +'git upload-pack <argument>'::
> +'git upload-archive <argument>'::
> + Call the corresponding server-side command to support
> + the client's 'git push', 'git fetch', or 'git archive --remote'
> + request.
> +'cvs server'::
> + Imitate a CVS server. See linkgit:git-cvsserver[1].
> +
> +If a `~/git-shell-commands` directory is present, 'git shell' will
> +also handle other, custom commands by running
> +"`git-shell-commands/<command> <arguments>`" from the user's home
> +directory.
> +
> +INTERACTIVE USE
> +---------------
> +
> +By default, the commands above can be executed only with the '-c'
> +option; the shell is not interactive.
> +
> +If a `~/git-shell-commands` directory is present, 'git shell'
> +can also be run interactively (with no arguments). If a `help`
> +command is present in the `git-shell-commands` directory, it is
> +run to provide the user with an overview of allowed actions. Then a
> +"`git> `" prompt is presented at which one can enter any of the
> +commands from the `git-shell-commands` directory, or `exit` to close
> +the connection.
> +
> +Generally this mode is used as an administrative interface to allow
> +users to list repositories they have access to, create, delete, or
> +rename repositories, or change repository descriptions and
> +permissions.
> +
> +SEE ALSO
> +--------
> +ssh(1),
> +linkgit:git-daemon[1],
> +contrib/git-shell-commands/README
>
> GIT
> ---
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Junio C Hamano @ 2013-02-11 7:01 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211061442.GI15329@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> Junio C Hamano wrote:
>
>>>> Are you shooting for customizability?
>>>
>>> Yes, and the ability to generate the message dynamically.
>>
>> Hmph, if that is the case, wouldn't it be a better direction to give
>> a better help for majority of the case where git-shell is used as
>> the login shell to allow push and fetch but not for interactive
>> access at all?
>>
>> The first step in that direction may be to give a better canned
>> message, followed by a mechanism (perhaps a hook) that lets a
>> message customized for the site's needs, no?
>
> The trouble is that I can't imagine a canned message that everyone
> will like. (For example, I quite dislike the current one.) That's
> exactly the situation in which some configurability is helpful.
I am not saying we should have a perfect canned message everybody
likes and not have any configurability. I however think we can aim
to come up with a message that covers 80% of site administrators who
do not care too much and just want git-shell to allow the standard
services without giving any custom command.
And for the remaining 20% of those who do not like the canned
message but still do not need any custom command, I think it is way
suboptimal to force them to create git-shell-commands directory for
47 users his host gives git-shell access to, and copy the "help"
script to all of them, only to get a customized message. It would
help them quite a lot if you just called /etc/git/shell-disabled or
some hook that generates a customized message; then there is no need
to add any git-shell-commands directory and a "help" script every
time he gets one new user, no?
For those who _do_ want to give customized commands to their users,
they can already have "help" script to give a friendly message. It
just felt silly to force sites to create the directory only to
refuse an access to the "custom commands" feature, especially when
the existence of that directory is a signal that the site may want
to give its users an acess to that feature.
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 6:22 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211061553.GJ15329@elie.Belkin>
On Mon, Feb 11, 2013 at 1:15 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> [administrivia: please don't top-post]
> Ethan Reesor wrote:
>
>> Why not have both? That way there is a way to get a customizable
>> response that avoids Junio's complaints and there is a way to do what
>> you are trying to achieve.
>
> What was Junio's complaint?
I was referring to the one you recently addressed:
On Mon, Feb 11, 2013 at 1:14 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> Junio C Hamano wrote:
>
>>>> Are you shooting for customizability?
>>>
>>> Yes, and the ability to generate the message dynamically.
>>
>> Hmph, if that is the case, wouldn't it be a better direction to give
>> a better help for majority of the case where git-shell is used as
>> the login shell to allow push and fetch but not for interactive
>> access at all?
>>
>> The first step in that direction may be to give a better canned
>> message, followed by a mechanism (perhaps a hook) that lets a
>> message customized for the site's needs, no?
>
> The trouble is that I can't imagine a canned message that everyone
> will like. (For example, I quite dislike the current one.) That's
> exactly the situation in which some configurability is helpful.
>
> Some configurability is nice for other situations, anyway. For
> example, sites serving a multilingual audience may want the message to
> vary based on the user's language (or even source IP). The message
> can include a list of available repositories or extra information that
> changes over time. And so on.
>
> Hope that helps,
> Jonathan
When I made my suggestion, I was tempted to say that both methods
(having help return non-zero and allowing a git-configurable response)
should be included, but I couldn't think of a reason to include both
until you brought your use case back up.
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Blind @ 2013-02-11 6:16 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <1360307982-20027-1-git-send-email-artagnon@gmail.com>
If I understand correctly,
in your scenario the branches with branch.<name>.pushremote
will be still included in the $git push <remote> --all?
Are you considering some way to exclude a branch from "push --all"
(branch.<name>.push = always, explicit, never... for example)?
Or maybe, if the branch is already marked as special
with branch.<name>.pushremote,
then it could be logical to push it only when is explicitly specified
on the command line (excluded from --all)?
Thanks,
Blind.
2013/2/8 Ramkumar Ramachandra <artagnon@gmail.com>:
> This new configuration variable overrides the remote in
> `branch.<name>.remote` for pushes. It is useful in the typical
> scenario, where the remote I'm pulling from is not the remote I'm
> pushing to. Although `remote.<name>.pushurl` is similar, it does not
> serve the purpose as the URL would lack corresponding remote tracking
> branches.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> This is a first cut. There's code duplication at the moment, but I'm
> currently trying to figure out which other remote_get() calls to
> replace with pushremote_get(). Comments are welcome.
>
> I will leave it to future patches to do the following things:
> 1. Fix the status output to be more meaningful when pushremote is
> set. At the moment, I'm thinking statuses like [pull: 4 behind,
> push: 3 ahead] will make sense.
> 2. Introduce a remote.pushDefault (peff)
> 3. Introduce a remote.default (peff)
>
> Documentation/config.txt | 6 ++++++
> builtin/push.c | 2 +-
> remote.c | 41 +++++++++++++++++++++++++++++++++++++++++
> remote.h | 2 ++
> 4 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9b11597..0b3b1f8 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -727,6 +727,12 @@ branch.<name>.remote::
> remote to fetch from/push to. It defaults to `origin` if no remote is
> configured. `origin` is also used if you are not on any branch.
>
> +branch.<name>.pushremote::
> + When in branch <name>, it tells 'git push' which remote to
> + push to. It falls back to `branch.<name>.remote`, and
> + defaults to `origin` if no remote is configured. `origin` is
> + also used if you are not on any branch.
> +
> branch.<name>.merge::
> Defines, together with branch.<name>.remote, the upstream branch
> for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
> diff --git a/builtin/push.c b/builtin/push.c
> index 42b129d..d447a80 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -322,7 +322,7 @@ static int push_with_options(struct transport *transport, int flags)
> static int do_push(const char *repo, int flags)
> {
> int i, errs;
> - struct remote *remote = remote_get(repo);
> + struct remote *remote = pushremote_get(repo);
> const char **url;
> int url_nr;
>
> diff --git a/remote.c b/remote.c
> index e53a6eb..d6fcfc0 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -48,6 +48,7 @@ static int branches_nr;
>
> static struct branch *current_branch;
> static const char *default_remote_name;
> +static const char *pushremote_name;
> static int explicit_default_remote_name;
>
> static struct rewrites rewrites;
> @@ -363,6 +364,12 @@ static int handle_config(const char *key, const char *value, void *cb)
> default_remote_name = branch->remote_name;
> explicit_default_remote_name = 1;
> }
> + } else if (!strcmp(subkey, ".pushremote")) {
> + if (!value)
> + return config_error_nonbool(key);
> + branch->pushremote_name = xstrdup(value);
> + if (branch == current_branch)
> + pushremote_name = branch->pushremote_name;
> } else if (!strcmp(subkey, ".merge")) {
> if (!value)
> return config_error_nonbool(key);
> @@ -700,6 +707,40 @@ struct remote *remote_get(const char *name)
> return ret;
> }
>
> +struct remote *pushremote_get(const char *name)
> +{
> + struct remote *ret;
> + int name_given = 0;
> +
> + read_config();
> + if (name)
> + name_given = 1;
> + else {
> + if (pushremote_name) {
> + name = pushremote_name;
> + name_given = 1;
> + } else {
> + name = default_remote_name;
> + name_given = explicit_default_remote_name;
> + }
> + }
> +
> + ret = make_remote(name, 0);
> + if (valid_remote_nick(name)) {
> + if (!valid_remote(ret))
> + read_remotes_file(ret);
> + if (!valid_remote(ret))
> + read_branches_file(ret);
> + }
> + if (name_given && !valid_remote(ret))
> + add_url_alias(ret, name);
> + if (!valid_remote(ret))
> + return NULL;
> + ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
> + ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
> + return ret;
> +}
> +
> int remote_is_configured(const char *name)
> {
> int i;
> diff --git a/remote.h b/remote.h
> index 251d8fd..aa42ff5 100644
> --- a/remote.h
> +++ b/remote.h
> @@ -51,6 +51,7 @@ struct remote {
> };
>
> struct remote *remote_get(const char *name);
> +struct remote *pushremote_get(const char *name);
> int remote_is_configured(const char *name);
>
> typedef int each_remote_fn(struct remote *remote, void *priv);
> @@ -130,6 +131,7 @@ struct branch {
> const char *refname;
>
> const char *remote_name;
> + const char *pushremote_name;
> struct remote *remote;
>
> const char **merge_name;
> --
> 1.8.1.2.545.g2f19ada.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 6:15 UTC (permalink / raw)
To: Ethan Reesor
Cc: Junio C Hamano, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <CAE_TNi=fN66+9WfMn86H6J_BVAjFP=xiE8m3JHe_4ANHB2V5wA@mail.gmail.com>
[administrivia: please don't top-post]
Ethan Reesor wrote:
> Why not have both? That way there is a way to get a customizable
> response that avoids Junio's complaints and there is a way to do what
> you are trying to achieve.
What was Junio's complaint?
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 6:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vpq07pgpy.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Junio C Hamano wrote:
>>> Are you shooting for customizability?
>>
>> Yes, and the ability to generate the message dynamically.
>
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of the case where git-shell is used as
> the login shell to allow push and fetch but not for interactive
> access at all?
>
> The first step in that direction may be to give a better canned
> message, followed by a mechanism (perhaps a hook) that lets a
> message customized for the site's needs, no?
The trouble is that I can't imagine a canned message that everyone
will like. (For example, I quite dislike the current one.) That's
exactly the situation in which some configurability is helpful.
Some configurability is nice for other situations, anyway. For
example, sites serving a multilingual audience may want the message to
vary based on the user's language (or even source IP). The message
can include a list of available repositories or extra information that
changes over time. And so on.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 6:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211060911.GH15329@elie.Belkin>
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
On Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ethan Reesor wrote:
>
>> That way, there's a default setting, there can
>> be a system-wide message, there can be a user specific message, and
>> those messages can be set via `git-commit`.
>
> That won't let me imitate gitolite's behavior without a lot of
> config file churn:
>
> $ ssh git@localhost
> Hello, jrn. This is git@elie running git-shell 1.8.1.3.
>
> R W path/to/one/repo
> R path/to/another/repo
> $
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 6:09 UTC (permalink / raw)
To: Ethan Reesor
Cc: Junio C Hamano, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <CAE_TNim2wrL3SWxy_2ugyGmEFDngBJ8+z04y2tJFzMo4N8mUug@mail.gmail.com>
Ethan Reesor wrote:
> That way, there's a default setting, there can
> be a system-wide message, there can be a user specific message, and
> those messages can be set via `git-commit`.
That won't let me imitate gitolite's behavior without a lot of
config file churn:
$ ssh git@localhost
Hello, jrn. This is git@elie running git-shell 1.8.1.3.
R W path/to/one/repo
R path/to/another/repo
$
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 6:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <CAE_TNim2wrL3SWxy_2ugyGmEFDngBJ8+z04y2tJFzMo4N8mUug@mail.gmail.com>
I noticed a typo I made. I meant `git-config` rather than
`git-commit`. Sorry for my mistake.
On Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor <firelizzard@gmail.com> wrote:
> On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Hmph, if that is the case, wouldn't it be a better direction to give
>> a better help for majority of the case where git-shell is used as
>> the login shell to allow push and fetch but not for interactive
>> access at all?
>>
>> The first step in that direction may be to give a better canned
>> message, followed by a mechanism (perhaps a hook) that lets a
>> message customized for the site's needs, no? Why should a site
>> administrator create an otherwise empty directory for each and every
>> user and add an executable in there that shows an error message,
>> only to improve the default message because it is not friendly
>> enough?
>
> Jonathan made the following comment on the thread I started that lead
> to this RFC:
>> You can disable interactive logins by removing the
>> ~/git-shell-commands/ directory. Unfortunately that doesn't let you
>> customize the message. Perhaps it would make sense to teach shell.c
>> to look for a
>>
>> [shell]
>> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'
>>
>> setting in git's config file.
>
> How is this for an alternative? Have shell.c look for
> [shell]
> missing_commands_directory = "Stuff is broke."
> setting. If the setting is missing, then it prints the default message
> (the current message). That way, there's a default setting, there can
> be a system-wide message, there can be a user specific message, and
> those messages can be set via `git-commit`.
>
> --
> Ethan Reesor
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command
From: Ethan Reesor @ 2013-02-11 6:06 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Sitaram Chamarty, Junio C Hamano, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211055847.GG15329@elie.Belkin>
I feel like the suggestion I posted in response to Junio C Hamano
<gitster@pobox.com>'s complaint on the RFC for this patch provides a
more elegant solution to the problem of administrators wanting to
prevent interactive sessions for users with their login shell set to
git-prompt. The suggestion was as follows:
> How is this for an alternative? Have shell.c look for a
> [shell]
> missing_commands_directory = "Stuff is broke."
> setting. If the setting is missing, then it prints the default message
> (the current message). That way, there's a default setting, there can
> be a system-wide message, there can be a user specific message, and
> those messages can be set via `git-config`.
On Mon, Feb 11, 2013 at 12:58 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> If I disable git-shell's interactive mode by removing the
> ~/git-shell-commands directory, then attempts to use 'ssh' with the
> git account interactively produce an error message intended for the
> administrator:
>
> $ ssh git@myserver
> fatal: Interactive git shell is not enabled.
> hint: ~/git-shell-commands should exist and have read and execute access.
> $
>
> That is helpful for the new admin who is wondering "What? Why isn't
> the git-shell I just set up working?", but once the site setup is
> finished, it is better to give the user a friendly hint that she is on
> the right track, like GitHub does:
>
> Hi <username>! You've successfully authenticated, but
> GitHub does not provide shell access.
>
> An appropriate greeting might even include more complex information,
> like a list of repositories the user has access to. If the
> git-shell-commands directory exists and contains a "help" script, we
> already run it when the shell is run without any commands, giving the
> server a chance to provide a custom message. Unfortunately, the
> presence of the git-shell-commands directory means we also enter an
> interactive mode, prompting and accepting commands (of which there may
> be none) from the user, which many servers would not want. To solve
> this, we abort the interactive shell on a non-zero exit code from the
> "help" script. This lets the server say whatever it likes, and then
> hang up.
>
> Downside: this will prevent interactive git-shell logins in existing
> setups where the "help" script exits with nonzero status by mistake.
> Hopefully those are rare enough to not cause much trouble in practice.
>
> Reported-by: Ethan Reesor <firelizzard@gmail.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> Improved-by: Jeff King <peff@peff.net>
> ---
> Documentation/git-shell.txt | 20 ++++++++++++++++++++
> shell.c | 10 ++++++++--
> 2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 4fe93203..60051e63 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or
> rename repositories, or change repository descriptions and
> permissions.
>
> +If the `help` command exists and exits with nonzero status, the
> +interactive shell is aborted.
> +
> +EXAMPLE
> +-------
> +
> +To disable interactive logins, displaying a greeting instead:
> ++
> +----------------
> +$ chsh -s /usr/bin/git-shell
> +$ mkdir $HOME/git-shell-commands
> +$ cat >$HOME/git-shell-commands/help <<\EOF
> +#!/bin/sh
> +printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
> +printf '%s\n' "provide interactive shell access."
> +exit 128
> +EOF
> +$ chmod +x $HOME/git-shell-commands/help
> +----------------
> +
> SEE ALSO
> --------
> ssh(1),
> diff --git a/shell.c b/shell.c
> index 84b237fe..3abc2b84 100644
> --- a/shell.c
> +++ b/shell.c
> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)
>
> static void run_shell(void)
> {
> - int done = 0;
> + int done = 0, status;
> static const char *help_argv[] = { HELP_COMMAND, NULL };
> /* Print help if enabled */
> - run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
> + status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
> + if (!status)
> + ; /* success */
> + else if (status == -1 && errno == ENOENT)
> + ; /* help disabled */
> + else
> + exit(status);
>
> do {
> struct strbuf line = STRBUF_INIT;
> --
> 1.8.1.3
>
--
Ethan Reesor (Gmail)
^ permalink raw reply
* [PATCH 2/2] shell: pay attention to exit status from 'help' command
From: Jonathan Nieder @ 2013-02-11 5:58 UTC (permalink / raw)
To: Jeff King
Cc: Sitaram Chamarty, Junio C Hamano, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211055604.GE15329@elie.Belkin>
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, then attempts to use 'ssh' with the
git account interactively produce an error message intended for the
administrator:
$ ssh git@myserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
$
That is helpful for the new admin who is wondering "What? Why isn't
the git-shell I just set up working?", but once the site setup is
finished, it is better to give the user a friendly hint that she is on
the right track, like GitHub does:
Hi <username>! You've successfully authenticated, but
GitHub does not provide shell access.
An appropriate greeting might even include more complex information,
like a list of repositories the user has access to. If the
git-shell-commands directory exists and contains a "help" script, we
already run it when the shell is run without any commands, giving the
server a chance to provide a custom message. Unfortunately, the
presence of the git-shell-commands directory means we also enter an
interactive mode, prompting and accepting commands (of which there may
be none) from the user, which many servers would not want. To solve
this, we abort the interactive shell on a non-zero exit code from the
"help" script. This lets the server say whatever it likes, and then
hang up.
Downside: this will prevent interactive git-shell logins in existing
setups where the "help" script exits with nonzero status by mistake.
Hopefully those are rare enough to not cause much trouble in practice.
Reported-by: Ethan Reesor <firelizzard@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Jeff King <peff@peff.net>
---
Documentation/git-shell.txt | 20 ++++++++++++++++++++
shell.c | 10 ++++++++--
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
index 4fe93203..60051e63 100644
--- a/Documentation/git-shell.txt
+++ b/Documentation/git-shell.txt
@@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or
rename repositories, or change repository descriptions and
permissions.
+If the `help` command exists and exits with nonzero status, the
+interactive shell is aborted.
+
+EXAMPLE
+-------
+
+To disable interactive logins, displaying a greeting instead:
++
+----------------
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat >$HOME/git-shell-commands/help <<\EOF
+#!/bin/sh
+printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
+printf '%s\n' "provide interactive shell access."
+exit 128
+EOF
+$ chmod +x $HOME/git-shell-commands/help
+----------------
+
SEE ALSO
--------
ssh(1),
diff --git a/shell.c b/shell.c
index 84b237fe..3abc2b84 100644
--- a/shell.c
+++ b/shell.c
@@ -63,10 +63,16 @@ static void cd_to_homedir(void)
static void run_shell(void)
{
- int done = 0;
+ int done = 0, status;
static const char *help_argv[] = { HELP_COMMAND, NULL };
/* Print help if enabled */
- run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ if (!status)
+ ; /* success */
+ else if (status == -1 && errno == ENOENT)
+ ; /* help disabled */
+ else
+ exit(status);
do {
struct strbuf line = STRBUF_INIT;
--
1.8.1.3
^ permalink raw reply related
* [PATCH 1/2] shell doc: emphasize purpose and security model
From: Jonathan Nieder @ 2013-02-11 5:57 UTC (permalink / raw)
To: Jeff King
Cc: Sitaram Chamarty, Junio C Hamano, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211055604.GE15329@elie.Belkin>
The original git-shell(1) manpage emphasized that the shell
supports only git transport commands, and as the shell gained
features that emphasis and focus in the manual has been lost.
Bring it back by splitting the manpage into a few short sections
and fleshing out each:
- SYNOPSIS, describing how the shell gets used in practice
- DESCRIPTION, which gives an overview of the purpose and
guarantees provided by this restricted shell
- COMMANDS, listing supported commands and restrictions on the
arguments they accept
- INTERACTIVE USE, describing the interactive mode
Also add a "see also" section with some relevant related reading.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
New text. Split off from patch 2 --- this is just documenting
existing behavior.
Documentation/git-shell.txt | 66 ++++++++++++++++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
index 9b925060..4fe93203 100644
--- a/Documentation/git-shell.txt
+++ b/Documentation/git-shell.txt
@@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
SYNOPSIS
--------
[verse]
-'git shell' [-c <command> <argument>]
+'chsh' -s $(which git-shell) git
+'git clone' `git@localhost:/path/to/repo.git`
+'ssh' `git@localhost`
DESCRIPTION
-----------
-A login shell for SSH accounts to provide restricted Git access. When
-'-c' is given, the program executes <command> non-interactively;
-<command> can be one of 'git receive-pack', 'git upload-pack', 'git
-upload-archive', 'cvs server', or a command in COMMAND_DIR. The shell
-is started in interactive mode when no arguments are given; in this
-case, COMMAND_DIR must exist, and any of the executables in it can be
-invoked.
-
-'cvs server' is a special command which executes git-cvsserver.
-
-COMMAND_DIR is the path "$HOME/git-shell-commands". The user must have
-read and execute permissions to the directory in order to execute the
-programs in it. The programs are executed with a cwd of $HOME, and
-<argument> is parsed as a command-line string.
+This is a login shell for SSH accounts to provide restricted Git access.
+It permits execution only of server-side Git commands implementing the
+pull/push functionality, plus custom commands present in a subdirectory
+named `git-shell-commands` in the user's home directory.
+
+COMMANDS
+--------
+
+'git shell' accepts the following commands after the '-c' option:
+
+'git receive-pack <argument>'::
+'git upload-pack <argument>'::
+'git upload-archive <argument>'::
+ Call the corresponding server-side command to support
+ the client's 'git push', 'git fetch', or 'git archive --remote'
+ request.
+'cvs server'::
+ Imitate a CVS server. See linkgit:git-cvsserver[1].
+
+If a `~/git-shell-commands` directory is present, 'git shell' will
+also handle other, custom commands by running
+"`git-shell-commands/<command> <arguments>`" from the user's home
+directory.
+
+INTERACTIVE USE
+---------------
+
+By default, the commands above can be executed only with the '-c'
+option; the shell is not interactive.
+
+If a `~/git-shell-commands` directory is present, 'git shell'
+can also be run interactively (with no arguments). If a `help`
+command is present in the `git-shell-commands` directory, it is
+run to provide the user with an overview of allowed actions. Then a
+"`git> `" prompt is presented at which one can enter any of the
+commands from the `git-shell-commands` directory, or `exit` to close
+the connection.
+
+Generally this mode is used as an administrative interface to allow
+users to list repositories they have access to, create, delete, or
+rename repositories, or change repository descriptions and
+permissions.
+
+SEE ALSO
+--------
+ssh(1),
+linkgit:git-daemon[1],
+contrib/git-shell-commands/README
GIT
---
--
1.8.1.3
^ permalink raw reply related
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Ethan Reesor @ 2013-02-11 5:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Sitaram Chamarty, Jeff King, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vpq07pgpy.fsf@alter.siamese.dyndns.org>
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of the case where git-shell is used as
> the login shell to allow push and fetch but not for interactive
> access at all?
>
> The first step in that direction may be to give a better canned
> message, followed by a mechanism (perhaps a hook) that lets a
> message customized for the site's needs, no? Why should a site
> administrator create an otherwise empty directory for each and every
> user and add an executable in there that shows an error message,
> only to improve the default message because it is not friendly
> enough?
Jonathan made the following comment on the thread I started that lead
to this RFC:
> You can disable interactive logins by removing the
> ~/git-shell-commands/ directory. Unfortunately that doesn't let you
> customize the message. Perhaps it would make sense to teach shell.c
> to look for a
>
> [shell]
> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'
>
> setting in git's config file.
How is this for an alternative? Have shell.c look for
[shell]
missing_commands_directory = "Stuff is broke."
setting. If the setting is missing, then it prints the default message
(the current message). That way, there's a default setting, there can
be a system-wide message, there can be a user specific message, and
those messages can be set via `git-commit`.
--
Ethan Reesor
^ permalink raw reply
* [PATCH 0/2 v2] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 5:56 UTC (permalink / raw)
To: Jeff King
Cc: Sitaram Chamarty, Junio C Hamano, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211043322.GA12735@sigill.intra.peff.net>
Jeff King wrote:
> I think what threw me off was reading the documentation part of the
> patch, which adds a note that we run "help" on startup, and then
> elaborates on the exit value. I didn't realize that the first half was
> documenting what already happened.
>
> Tweaking the third paragraph of the commit message to:
Very nice. How about this version?
Jonathan Nieder (2):
shell doc: emphasize purpose and security guarantees
shell: pay attention to exit status from 'help' command
Documentation/git-shell.txt | 86 +++++++++++++++++++++++++++++++++++++--------
shell.c | 10 ++++--
2 files changed, 79 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Junio C Hamano @ 2013-02-11 5:22 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211043247.GD15329@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help for majority of the case where git-shell is used as
the login shell to allow push and fetch but not for interactive
access at all?
The first step in that direction may be to give a better canned
message, followed by a mechanism (perhaps a hook) that lets a
message customized for the site's needs, no? Why should a site
administrator create an otherwise empty directory for each and every
user and add an executable in there that shows an error message,
only to improve the default message because it is not friendly
enough?
I may be being slower than usual, but I am still not convinced...
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jeff King @ 2013-02-11 4:45 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sitaram Chamarty, Junio C Hamano, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211012016.GA13243@elie.Belkin>
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
> diff --git a/shell.c b/shell.c
> index 84b237fe..3abc2b84 100644
> --- a/shell.c
> +++ b/shell.c
> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)
>
> static void run_shell(void)
> {
> - int done = 0;
> + int done = 0, status;
> static const char *help_argv[] = { HELP_COMMAND, NULL };
> /* Print help if enabled */
> - run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
> + status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
> + if (!status)
> + ; /* success */
> + else if (status == -1 && errno == ENOENT)
> + ; /* help disabled */
> + else
> + exit(status);
One final comment on this. I believe we convert an exit code of 127 from
the child into ENOENT. So something like:
#!/bin/sh
echo >&2 "Sorry, no interactive shells allowed."
exti 1
would actually go into the "help disabled" code path and accidentally
run an interactive shell. I wondered if this is something that might
happen accidentally (since the old semantics of "help" were that exit
code did not matter), and if there might be security implications to
entering an interactive shell. But I think we are OK for two reasons:
1. An old script would not be trying to exit with failure and
expecting to abort the interactive session; that is a new feature
you are adding. So even if we accidentally exit 127 (because the
old script relied on a missing command), it is not changing the
semantics.
2. Even if we accidentally do enter the interactive prompt, it should
not be a security issue. It is not like you can then run arbitrary
commands; unless you have put something else into
~/git-shell-commands, the user can only run "help" over and over.
Maybe obvious, but I wanted to note it as part of the review. I think we
need to be extra careful with thinking through git-shell security
implications, since it is a major potential attack surface for many git
setups.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jeff King @ 2013-02-11 4:36 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sitaram Chamarty, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211043247.GD15329@elie.Belkin>
On Sun, Feb 10, 2013 at 08:32:47PM -0800, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
As far as the default goes, I think the current one is OK, provided
there is an option to customize it (e.g., like your patch). Right now it
is just nonsensical to random users ("What? What in the world is
~/git-shell-commands?"). But once it is customizable, the main consumer
of the message is admins who say "What? Why isn't the git-shell I just
set up working?". The current message helps them diagnose the problem,
and when they are ready to accept connections from random users, they'll
want something customizable anyway.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jeff King @ 2013-02-11 4:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sitaram Chamarty, Junio C Hamano, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130211042609.GC15329@elie.Belkin>
On Sun, Feb 10, 2013 at 08:26:09PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
>
> >> Only interactive connections. That's the existing behavior.
> >
> > Ah, sorry. I misread the patch. I see now that we already run help, and
> > this is just making the exit value significant. In that case, yeah, I
> > think it's fine.
>
> No problem --- the description was unclear. Would retitling the patch
> to "shell: pay attention to exit status from 'help' command" work?
I think what threw me off was reading the documentation part of the
patch, which adds a note that we run "help" on startup, and then
elaborates on the exit value. I didn't realize that the first half was
documenting what already happened.
Tweaking the third paragraph of the commit message to:
An appropriate greeting might even include more complex information,
like a list of repositories the user has access to. If the
git-shell-commands directory exists and contains a "help" script, we
already run it when the shell is run without any commands, giving the
server a chance to provide a custom message. Unfortunately, the
presence of the git-shell-commands directory means we also enter an
interactive mode, prompting and accepting commands (of which there may
be none) from the user, which many servers would not want. To solve
this, we abort the interactive shell on a non-zero exit code from the
"help" script. This lets the server say whatever it likes, and then
hangup.
makes it more clear to me. But once you explained it, I realize that I
also could have just read the C code part of the patch more carefully. :)
So I'm fine with or without that change.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
From: Jonathan Nieder @ 2013-02-11 4:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sitaram Chamarty, Jeff King, Ethan Reesor, git,
Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <7vwqufpj50.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox