{"thread":{"id":"35965","subject":"[PATCH] archive: add archive.restrictRemote option","startedAt":"2014-02-27T04:05:05Z","lastAt":"2014-02-28T17:54:52Z","messageCount":8,"participants":["Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"235436","messageId":"20140227040504.GA2242@sigill.intra.peff.net","threadId":"35965","inReplyTo":null,"subject":"[PATCH] archive: add archive.restrictRemote option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-27T04:05:05Z","receivedAt":"2014-02-27T04:05:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"From: Scott J. Goldman \n\nIn commit ee27ca4, we started restricting remote git-archive\ninvocations to only accessing reachable commits. This\nmatches what upload-pack allows, but does restrict some\nuseful cases (e.g., HEAD:foo). We loosened this in 0f544ee,\nwhich allows `foo:bar` as long as `foo` is a ref tip.\nHowever, that still doesn't allow many useful things, like:\n\n 1. Commits accessible from a ref, like `foo^:bar`, which\n is reachable\n\n 2. Arbitrary sha1s, even if they are reachable.\n\nWe can do a full object-reachability check for these cases,\nbut it can be quite expensive if the client has sent us the\nsha1 of a tree; we have to visit every sub-tree of every\ncommit in the worst case.\n\nLet's instead give site admins an escape hatch, in case they\nprefer the more liberal behavior. For many sites, the full\nobject database is public anyway (e.g., if you allow dumb\nwalker access), or the site admin may simply decide the\nsecurity/convenience tradeoff is not worth it.\n\nThis patch adds a new config option to turn off the\nrestrictions added in ee27ca4. It defaults to on, meaning\nthere is no change in behavior by default.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-archive.txt | 7 +++++++\n archive.c | 13 +++++++++++--\n t/t5000-tar-tree.sh | 9 +++++++++\n 3 files changed, 27 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\nindex b97aaab..486cb08 100644\n--- a/Documentation/git-archive.txt\n+++ b/Documentation/git-archive.txt\n@@ -121,6 +121,13 @@ tar..remote::\n \tuser-defined formats, but true for the \"tar.gz\" and \"tgz\"\n \tformats.\n \n+archive.restrictRemote::\n+\tIf true, archives can only be requested by refnames. If false,\n+\tallows remote archive requests from arbitrary revisions. This\n+\tcan be a security hazard, as archives could be requested for\n+\tunreachable commits that have been pruned from the repository.\n+\tDefaults to true.\n+\n [[ATTRIBUTES]]\n ATTRIBUTES\n ----------\ndiff --git a/archive.c b/archive.c\nindex 346f3b2..13eb23a 100644\n--- a/archive.c\n+++ b/archive.c\n@@ -17,6 +17,7 @@ static char const * const archive_usage[] = {\n static const struct archiver **archivers;\n static int nr_archivers;\n static int alloc_archivers;\n+static int git_archive_restrict_remote = 1;\n \n void register_archiver(struct archiver *ar)\n {\n@@ -257,7 +258,7 @@ static void parse_treeish_arg(const char **argv,\n \tunsigned char sha1[20];\n \n \t/* Remotes are only allowed to fetch actual refs */\n-\tif (remote) {\n+\tif (remote && git_archive_restrict_remote) {\n \t\tchar *ref = NULL;\n \t\tconst char *colon = strchr(name, ':');\n \t\tint refnamelen = colon ? colon - name : strlen(name);\n@@ -401,6 +402,14 @@ static int parse_archive_args(int argc, const char **argv,\n \treturn argc;\n }\n \n+static int git_default_archive_config(const char *var, const char *value,\n+\t\t\t\t void *cb)\n+{\n+\tif (!strcmp(var, \"archive.restrictremote\"))\n+\t\tgit_archive_restrict_remote = git_config_bool(var, value);\n+\treturn git_default_config(var, value, cb);\n+}\n+\n int write_archive(int argc, const char **argv, const char *prefix,\n \t\t int setup_prefix, const char *name_hint, int remote)\n {\n@@ -411,7 +420,7 @@ int write_archive(int argc, const char **argv, const char *prefix,\n \tif (setup_prefix && prefix == NULL)\n \t\tprefix = setup_git_directory_gently(&nongit);\n \n-\tgit_config(git_default_config, NULL);\n+\tgit_config(git_default_archive_config, NULL);\n \tinit_tar_archiver();\n \tinit_zip_archiver();\n \ndiff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\nindex 05f011d..eba285f 100755\n--- a/t/t5000-tar-tree.sh\n+++ b/t/t5000-tar-tree.sh\n@@ -213,6 +213,15 @@ test_expect_success 'clients cannot access unreachable commits' '\n \ttest_must_fail git archive --remote=. $sha1 >remote.tar\n '\n \n+test_expect_success 'clients can access unreachable commits' '\n+\ttest_commit unreachable1 &&\n+\tsha1=`git rev-parse HEAD` &&\n+\tgit reset --hard HEAD^ &&\n+\tgit archive $sha1 >remote.tar &&\n+\ttest_config archive.restrictRemote false &&\n+\tgit archive --remote=. $sha1 >remote.tar\n+'\n+\n test_expect_success 'setup tar filters' '\n \tgit config tar.tar.foo.command \"tr ab ba\" &&\n \tgit config tar.bar.command \"tr ab ba\" &&\n-- \n1.8.5.2.500.g8060133\n"},{"id":"235488","messageId":"xmqqtxbkz9jp.fsf@gitster.dls.corp.google.com","threadId":"35965","inReplyTo":"20140227040504.GA2242@sigill.intra.peff.net","subject":"Re: [PATCH] archive: add archive.restrictRemote option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-27T18:37:30Z","receivedAt":"2014-02-27T18:37:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> From: Scott J. Goldman \n>\n> In commit ee27ca4, we started restricting remote git-archive\n> invocations to only accessing reachable commits. This\n> matches what upload-pack allows, but does restrict some\n> useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,\n> which allows `foo:bar` as long as `foo` is a ref tip.\n> However, that still doesn't allow many useful things, like:\n>\n> 1. Commits accessible from a ref, like `foo^:bar`, which\n> is reachable\n>\n> 2. Arbitrary sha1s, even if they are reachable.\n>\n> We can do a full object-reachability check for these cases,\n> but it can be quite expensive if the client has sent us the\n> sha1 of a tree; we have to visit every sub-tree of every\n> commit in the worst case.\n>\n> Let's instead give site admins an escape hatch, in case they\n> prefer the more liberal behavior. For many sites, the full\n> object database is public anyway (e.g., if you allow dumb\n> walker access), or the site admin may simply decide the\n> security/convenience tradeoff is not worth it.\n>\n> This patch adds a new config option to turn off the\n> restrictions added in ee27ca4. It defaults to on, meaning\n> there is no change in behavior by default.\n>\n> Signed-off-by: Jeff King \n\nThanks.\n\nDo GitHub people have general aversion against signing off (or\nsending out, for that matter) their own patches, unless they were\nalready active here before they joined GitHub, by the way?\n\nI like the general idea and this escape hatch would be a good thing\nto have.\n\nA few comments:\n\n - Seeing the word combination \"restrict\"+\"remote\" before reading\n the explanation made me think \"hmph, only allow remote archive\n from certain hosts but not from others?\" We are restricting the\n objects and only on the remote usage, not restricting remotes, so\n somebody else may be able to come up with a less misleading name.\n\n - It might be better to call the escape hatch \"allow something\"\n that defaults to \"false\". It is merely the issue of perception,\n but having a knob to be limiting that defaults to true gives a\n wrong impression that in an ideal world remote archive ought to\n be loose and we are artificially limiting it by default.\n\nBut these are just my \"reactions\"; neither is an objection to the\nposted patch as-is.\n\n> ---\n> Documentation/git-archive.txt | 7 +++++++\n> archive.c | 13 +++++++++++--\n> t/t5000-tar-tree.sh | 9 +++++++++\n> 3 files changed, 27 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\n> index b97aaab..486cb08 100644\n> --- a/Documentation/git-archive.txt\n> +++ b/Documentation/git-archive.txt\n> @@ -121,6 +121,13 @@ tar..remote::\n> \tuser-defined formats, but true for the \"tar.gz\" and \"tgz\"\n> \tformats.\n> \n> +archive.restrictRemote::\n> +\tIf true, archives can only be requested by refnames. If false,\n\nAs this does not affect local use of \"git archive\", \"requested by\nrefnames\" may need to be clarified further. Perhaps \"remote\narchives can be requested only for published refnames\" or something.\n\nJust to help starting further discussion to pick brains of others,\nthis paragraph could have been like this, I would think.\n\n archive.serveArbitraryObjectToRemote::\n\n By default, remote archives can be requested only for\n published refnames (e.g. \"git archive --remote=origin\n master\" is OK, but \"git archive --remote=origin ae9677f\" is\n not), to prevent peeking into unreachable commits that have\n been pruned from the repository. This configuration\n variable can be set to bypass this security measure.\n\nThe phrase \"serve arbitrary object to remote\" would reflect the\npurpose of the escape hatch better, I would think, but it is not a\ngreat short-and-sweet name.\n\nThanks.\n"},{"id":"235562","messageId":"20140228090709.GB11709@sigill.intra.peff.net","threadId":"35965","inReplyTo":"xmqqtxbkz9jp.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] archive: add archive.restrictRemote option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T09:07:09Z","receivedAt":"2014-02-28T09:07:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:\n\n> > Signed-off-by: Jeff King \n> \n> Thanks.\n> \n> Do GitHub people have general aversion against signing off (or\n> sending out, for that matter) their own patches, unless they were\n> already active here before they joined GitHub, by the way?\n\nMostly it is that I clean up the patches and commit messages before\nsending them out. Michael sends out his own patches because they are\nalready perfect by the time I see them. :)\n\nI can certainly get S-O-B from GitHubbers, but my impression of the DCO\nis that it does not matter; as the first link in the signoff chain, I am\ncertifying that the patch meets the licensing requirements. Of course, I\nknow that because of my relationship to the author and our employer,\nwhich is something that isn't encoded in the headers. A S-O-B from the\nauthor would perhaps make it more obvious what happened.\n\n> I like the general idea and this escape hatch would be a good thing\n> to have.\n> \n> A few comments:\n> \n> - Seeing the word combination \"restrict\"+\"remote\" before reading\n> the explanation made me think \"hmph, only allow remote archive\n> from certain hosts but not from others?\" We are restricting the\n> objects and only on the remote usage, not restricting remotes, so\n> somebody else may be able to come up with a less misleading name.\n>\n> - It might be better to call the escape hatch \"allow something\"\n> that defaults to \"false\". It is merely the issue of perception,\n> but having a knob to be limiting that defaults to true gives a\n> wrong impression that in an ideal world remote archive ought to\n> be loose and we are artificially limiting it by default.\n\nAfter reading your first point, I came up with\n\"archive.allowRemoteUnreachable\", which also satisfies the second. I do\nnot have a strong opinion.\n\n> > +archive.restrictRemote::\n> > +\tIf true, archives can only be requested by refnames. If false,\n> \n> As this does not affect local use of \"git archive\", \"requested by\n> refnames\" may need to be clarified further. Perhaps \"remote\n> archives can be requested only for published refnames\" or something.\n\nI was hoping to be vague. If we really want to get into specifics, we\nshould probably document the current rules (refnames, and sub-trees of\nrefnames). It might be a good thing to document that anyway, though. And\nby doing so, it would become obvious why one would want to set this\noption. I'll see what I can come up with.\n\n-Peff\n"},{"id":"235584","messageId":"20140228095619.GA11803@sigill.intra.peff.net","threadId":"35965","inReplyTo":"20140228090709.GB11709@sigill.intra.peff.net","subject":"[PATCH v2 0/2] lifting upload-archive restrictions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T09:56:19Z","receivedAt":"2014-02-28T09:56:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 28, 2014 at 04:07:09AM -0500, Jeff King wrote:\n\n> > As this does not affect local use of \"git archive\", \"requested by\n> > refnames\" may need to be clarified further. Perhaps \"remote\n> > archives can be requested only for published refnames\" or something.\n> \n> I was hoping to be vague. If we really want to get into specifics, we\n> should probably document the current rules (refnames, and sub-trees of\n> refnames). It might be a good thing to document that anyway, though. And\n> by doing so, it would become obvious why one would want to set this\n> option. I'll see what I can come up with.\n\nHere's a series to handle this; I think the end result is much nicer. I\nended up calling the option \"uploadarchive.allowUnreachable\". By moving\nit there instead of under \"archive\", it is more clear that this is about\nthe _serving_ end of the remote connection, and the word \"remote\"\nbecomes redundant.\n\n [1/2]: docs: clarify remote restrictions for git-upload-archive\n [2/2]: add uploadarchive.allowUnreachable option\n\n-Peff\n"},{"id":"235585","messageId":"20140228100128.GA13169@sigill.intra.peff.net","threadId":"35965","inReplyTo":"20140228095619.GA11803@sigill.intra.peff.net","subject":"[PATCH v2 1/2] docs: clarify remote restrictions for git-upload-archive","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T10:01:29Z","receivedAt":"2014-02-28T10:01:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Commits ee27ca4 and 0f544ee introduced rules by which\ngit-upload-archive would restrict clients from accessing\nunreachable objects. However, we never documented those\nrules anywhere, nor their reason for being. Let's do so now.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-archive.txt | 5 ++++-\n Documentation/git-upload-archive.txt | 26 ++++++++++++++++++++++++++\n 2 files changed, 30 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\nindex b97aaab..cfa1e4e 100644\n--- a/Documentation/git-archive.txt\n+++ b/Documentation/git-archive.txt\n@@ -65,7 +65,10 @@ OPTIONS\n \n --remote=::\n \tInstead of making a tar archive from the local repository,\n-\tretrieve a tar archive from a remote repository.\n+\tretrieve a tar archive from a remote repository. Note that the\n+\tremote repository may place restrictions on which sha1\n+\texpressions may be allowed in ``. See\n+\tlinkgit:git-upload-archive[1] for details.\n \n --exec=::\n \tUsed with --remote to specify the path to the\ndiff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt\nindex d09bbb5..8ae65d8 100644\n--- a/Documentation/git-upload-archive.txt\n+++ b/Documentation/git-upload-archive.txt\n@@ -20,6 +20,32 @@ This command is usually not invoked directly by the end user. The UI\n for the protocol is on the 'git archive' side, and the program pair\n is meant to be used to get an archive from a remote repository.\n \n+SECURITY\n+--------\n+\n+In order to protect the privacy of objects that have been removed from\n+history but may not yet have been pruned, `git-upload-archive` avoids\n+serving archives for commits and trees that are not reachable from the\n+repository's refs. However, because calculating object reachability is\n+computationally expensive, `git-upload-archive` implements a stricter\n+but easier-to-check set of rules:\n+\n+ 1. Clients may request a commit or tree that is pointed to directly by\n+ a ref. E.g., `git archive --remote=origin v1.0`.\n+\n+ 2. Clients may request a sub-tree within a commit or tree using the\n+ `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`.\n+\n+ 3. Clients may _not_ use other sha1 expressions, even if the end\n+ result is reachable. E.g., neither a relative commit like `master^`\n+ nor a literal sha1 like `abcd1234` is allowed, even if the result\n+ is reachable from the refs.\n+\n+Note that rule 3 disallows many cases that do not have any privacy\n+implications. These rules are subject to change in future versions of\n+git, and the server accessed by `git archive --remote` may or may not\n+follow these exact rules.\n+\n OPTIONS\n -------\n ::\n-- \n1.8.5.2.500.g8060133\n"},{"id":"235586","messageId":"20140228100418.GA18092@sigill.intra.peff.net","threadId":"35965","inReplyTo":"20140228095619.GA11803@sigill.intra.peff.net","subject":"[PATCH v2 2/2] add uploadarchive.allowUnreachable option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T10:04:19Z","receivedAt":"2014-02-28T10:04:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"From: Scott J. Goldman \n\nIn commit ee27ca4, we started restricting remote git-archive\ninvocations to only accessing reachable commits. This\nmatches what upload-pack allows, but does restrict some\nuseful cases (e.g., HEAD:foo). We loosened this in 0f544ee,\nwhich allows `foo:bar` as long as `foo` is a ref tip.\nHowever, that still doesn't allow many useful things, like:\n\n 1. Commits accessible from a ref, like `foo^:bar`, which\n are reachable\n\n 2. Arbitrary sha1s, even if they are reachable.\n\nWe can do a full object-reachability check for these cases,\nbut it can be quite expensive if the client has sent us the\nsha1 of a tree; we have to visit every sub-tree of every\ncommit in the worst case.\n\nLet's instead give site admins an escape hatch, in case they\nprefer the more liberal behavior. For many sites, the full\nobject database is public anyway (e.g., if you allow dumb\nwalker access), or the site admin may simply decide the\nsecurity/convenience tradeoff is not worth it.\n\nThis patch adds a new config option to disable the\nrestrictions added in ee27ca4. It defaults to off, meaning\nthere is no change in behavior by default.\n\nSigned-off-by: Jeff King \n---\n Documentation/config.txt | 7 +++++++\n Documentation/git-upload-archive.txt | 6 ++++++\n archive.c | 13 +++++++++++--\n t/t5000-tar-tree.sh | 9 +++++++++\n 4 files changed, 33 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 040197b..62f0a4e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -2334,6 +2334,13 @@ transfer.unpackLimit::\n \tnot set, the value of this variable is used instead.\n \tThe default value is 100.\n \n+uploadarchive.allowUnreachable::\n+\tIf true, allow clients to use `git archive --remote` to request\n+\tany tree, whether reachable from the ref tips or not. See the\n+\tdiscussion in the `SECURITY` section of\n+\tlinkgit:git-upload-archive[1] for more details. Defaults to\n+\t`false`.\n+\n uploadpack.hiderefs::\n \tString(s) `upload-pack` uses to decide which refs to omit\n \tfrom its initial advertisement. Use more than one\ndiff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt\nindex 8ae65d8..cbef61b 100644\n--- a/Documentation/git-upload-archive.txt\n+++ b/Documentation/git-upload-archive.txt\n@@ -46,6 +46,12 @@ implications. These rules are subject to change in future versions of\n git, and the server accessed by `git archive --remote` may or may not\n follow these exact rules.\n \n+If the config option `uploadArchive.allowUnreachable` is true, these\n+rules are ignored, and clients may use arbitrary sha1 expressions.\n+This is useful if you do not care about the privacy of unreachable\n+objects, or if your object database is already publicly available for\n+access via non-smart-http.\n+\n OPTIONS\n -------\n ::\ndiff --git a/archive.c b/archive.c\nindex 346f3b2..7d0976f 100644\n--- a/archive.c\n+++ b/archive.c\n@@ -17,6 +17,7 @@ static char const * const archive_usage[] = {\n static const struct archiver **archivers;\n static int nr_archivers;\n static int alloc_archivers;\n+static int remote_allow_unreachable;\n \n void register_archiver(struct archiver *ar)\n {\n@@ -257,7 +258,7 @@ static void parse_treeish_arg(const char **argv,\n \tunsigned char sha1[20];\n \n \t/* Remotes are only allowed to fetch actual refs */\n-\tif (remote) {\n+\tif (remote && !remote_allow_unreachable) {\n \t\tchar *ref = NULL;\n \t\tconst char *colon = strchr(name, ':');\n \t\tint refnamelen = colon ? colon - name : strlen(name);\n@@ -401,6 +402,14 @@ static int parse_archive_args(int argc, const char **argv,\n \treturn argc;\n }\n \n+static int git_default_archive_config(const char *var, const char *value,\n+\t\t\t\t void *cb)\n+{\n+\tif (!strcmp(var, \"uploadarchive.allowunreachable\"))\n+\t\tremote_allow_unreachable = git_config_bool(var, value);\n+\treturn git_default_config(var, value, cb);\n+}\n+\n int write_archive(int argc, const char **argv, const char *prefix,\n \t\t int setup_prefix, const char *name_hint, int remote)\n {\n@@ -411,7 +420,7 @@ int write_archive(int argc, const char **argv, const char *prefix,\n \tif (setup_prefix && prefix == NULL)\n \t\tprefix = setup_git_directory_gently(&nongit);\n \n-\tgit_config(git_default_config, NULL);\n+\tgit_config(git_default_archive_config, NULL);\n \tinit_tar_archiver();\n \tinit_zip_archiver();\n \ndiff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh\nindex 05f011d..1cf0a4e 100755\n--- a/t/t5000-tar-tree.sh\n+++ b/t/t5000-tar-tree.sh\n@@ -213,6 +213,15 @@ test_expect_success 'clients cannot access unreachable commits' '\n \ttest_must_fail git archive --remote=. $sha1 >remote.tar\n '\n \n+test_expect_success 'upload-archive can allow unreachable commits' '\n+\ttest_commit unreachable1 &&\n+\tsha1=`git rev-parse HEAD` &&\n+\tgit reset --hard HEAD^ &&\n+\tgit archive $sha1 >remote.tar &&\n+\ttest_config uploadarchive.allowUnreachable true &&\n+\tgit archive --remote=. $sha1 >remote.tar\n+'\n+\n test_expect_success 'setup tar filters' '\n \tgit config tar.tar.foo.command \"tr ab ba\" &&\n \tgit config tar.bar.command \"tr ab ba\" &&\n-- \n1.8.5.2.500.g8060133\n"},{"id":"235647","messageId":"xmqqa9dbw2fl.fsf@gitster.dls.corp.google.com","threadId":"35965","inReplyTo":"20140228090709.GB11709@sigill.intra.peff.net","subject":"Re: [PATCH] archive: add archive.restrictRemote option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-28T17:51:42Z","receivedAt":"2014-02-28T17:51:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:\n>\n>> > Signed-off-by: Jeff King \n>> \n>> Thanks.\n>> \n>> Do GitHub people have general aversion against signing off (or\n>> sending out, for that matter) their own patches, unless they were\n>> already active here before they joined GitHub, by the way?\n>\n> Mostly it is that I clean up the patches and commit messages before\n> sending them out. Michael sends out his own patches because they are\n> already perfect by the time I see them. :)\n>\n> I can certainly get S-O-B from GitHubbers, but my impression of the DCO\n> is that it does not matter...\n> ... A S-O-B from the\n> author would perhaps make it more obvious what happened.\n\nOh, I was not saying the practice was not legit. It was just that I\nexpected a bit more from GitHub, a leading company that evangelises\nuse of Git ;-)\n\n> I was hoping to be vague. If we really want to get into specifics, we\n> should probably document the current rules (refnames, and sub-trees of\n> refnames). It might be a good thing to document that anyway, though. And\n> by doing so, it would become obvious why one would want to set this\n> option. I'll see what I can come up with.\n\nThanks.\n"},{"id":"235649","messageId":"xmqq61nzw2ab.fsf@gitster.dls.corp.google.com","threadId":"35965","inReplyTo":"20140228095619.GA11803@sigill.intra.peff.net","subject":"Re: [PATCH v2 0/2] lifting upload-archive restrictions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-28T17:54:52Z","receivedAt":"2014-02-28T17:54:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Here's a series to handle this; I think the end result is much nicer. I\n> ended up calling the option \"uploadarchive.allowUnreachable\". By moving\n> it there instead of under \"archive\", it is more clear that this is about\n> the _serving_ end of the remote connection, and the word \"remote\"\n> becomes redundant.\n\nYeah, the original was already good but I like this version much\nbetter. I'm glad I bikeshedded ;-)\n\nThanks.\n"}]}