{"thread":{"id":"50223","subject":"[PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","startedAt":"2019-01-14T23:09:07Z","lastAt":"2019-01-22T18:19:20Z","messageCount":7,"participants":["Jonathan Nieder","Jeff King","Junio C Hamano","Ramsay Jones"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"366686","messageId":"20190114230902.GG162110@google.com","threadId":"50223","inReplyTo":null,"subject":"[PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-01-14T23:09:02Z","receivedAt":"2019-01-14T23:09:07Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"From: Jeff King <peff@peff.net>\nDate: Sun, 13 May 2018 14:14:34 -0400\n\nThis case is already forbidden by verify_path(), so let's\ncheck it in fsck. It's easier to handle than .gitmodules,\nbecause we don't care about checking the blob content. This\nis really just about whether the name and mode for the tree\nentry are valid.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\nHi,\n\nThis patch is from the 2.20.0 era, from the same series as\n\n fsck: detect submodule urls starting with dash\n\nIt was omitted from that series because it does not address any known\nexploit, but to me it seems worthwhile anyway:\n\n- if a client enables transfer.fsckObjects, this helps them protect\n  themselves against weird input that does *not* have a known exploit\n  attached, to\n\n- it generally feels more simple and robust.  Git-related tools can\n  benefit from this kind of check as an indication of input they can\n  bail out on instead of trying to support.\n\nPeff checked it against repos in the wild and found this to be very\nrare but existent (e.g. https://github.com/acquia/blt has a\n.gitattributes symlink).  Linus suggested that we may want it to be\nINFO instead of ERROR, so that people can at least notice that their\n.gitattributes symlink is likely to have no effect.  This patch still\nuses ERROR because I suspect that this is rare enough in the wild that\npeople will be able to cope.\n\nThoughts?\n\nThanks,\nJonathan\n\n fsck.c | 15 +++++++++++++++\n 1 file changed, 15 insertions(+)\n\ndiff --git a/fsck.c b/fsck.c\nindex 68502ce85b..850363fc8e 100644\n--- a/fsck.c\n+++ b/fsck.c\n@@ -68,6 +68,8 @@ static struct oidset gitmodules_done = OIDSET_INIT;\n \tFUNC(GITMODULES_SYMLINK, ERROR) \\\n \tFUNC(GITMODULES_URL, ERROR) \\\n \tFUNC(GITMODULES_PATH, ERROR) \\\n+\tFUNC(GITIGNORE_SYMLINK, ERROR) \\\n+\tFUNC(GITATTRIBUTES_SYMLINK, ERROR) \\\n \t/* warnings */ \\\n \tFUNC(BAD_FILEMODE, WARN) \\\n \tFUNC(EMPTY_NAME, WARN) \\\n@@ -627,6 +629,19 @@ static int fsck_tree(struct tree *item, struct fsck_options *options)\n \t\t\t\t\t\t \".gitmodules is a symbolic link\");\n \t\t}\n \n+\t\tif (S_ISLNK(mode)) {\n+\t\t\tif (is_hfs_dotgitignore(name) ||\n+\t\t\t    is_ntfs_dotgitignore(name))\n+\t\t\t\tretval += report(options, &item->object,\n+\t\t\t\t\t\t FSCK_MSG_GITIGNORE_SYMLINK,\n+\t\t\t\t\t\t \".gitignore is a symlink\");\n+\t\t\tif (is_hfs_dotgitattributes(name) ||\n+\t\t\t    is_ntfs_dotgitattributes(name))\n+\t\t\t\tretval += report(options, &item->object,\n+\t\t\t\t\t\t FSCK_MSG_GITATTRIBUTES_SYMLINK,\n+\t\t\t\t\t\t \".gitattributes is a symlink\");\n+\t\t}\n+\n \t\tif (update_tree_entry_gently(&desc)) {\n \t\t\tretval += report(options, &item->object, FSCK_MSG_BAD_TREE, \"cannot be parsed as a tree\");\n \t\t\tbreak;\n-- \n2.20.1.97.g81188d93c3\n\n"},{"id":"367004","messageId":"20190117170005.GA27667@sigill.intra.peff.net","threadId":"50223","inReplyTo":"20190114230902.GG162110@google.com","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-17T17:00:06Z","receivedAt":"2019-01-17T17:00:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 14, 2019 at 03:09:02PM -0800, Jonathan Nieder wrote:\n\n> From: Jeff King <peff@peff.net>\n> Date: Sun, 13 May 2018 14:14:34 -0400\n> \n> This case is already forbidden by verify_path(), so let's\n> check it in fsck. It's easier to handle than .gitmodules,\n> because we don't care about checking the blob content. This\n> is really just about whether the name and mode for the tree\n> entry are valid.\n\nHmm. I think this commit message isn't quite right, because we also\nskipped the patches to touch gitignore/gitattributes in verify_path().\n\nAre you thinking we should resurrect that behavior[1], too, or just\nprotect at the fsck level?\n\n> It was omitted from that series because it does not address any known\n> exploit, but to me it seems worthwhile anyway:\n> \n> - if a client enables transfer.fsckObjects, this helps them protect\n>   themselves against weird input that does *not* have a known exploit\n>   attached, to\n> \n> - it generally feels more simple and robust.  Git-related tools can\n>   benefit from this kind of check as an indication of input they can\n>   bail out on instead of trying to support.\n\nI think I may just be restating your two points above, but what I'd\nargue is:\n\n  - even though there's no known-interesting exploit, this can cause Git\n    to unexpectedly read arbitrary files outside of the repository\n    directory. That in itself isn't necessarily evil, but it's weird.\n\n  - there are potentially non-malicious bugs here, where we try to read\n    .gitattributes out of the index, but obviously don't follow symlinks\n    there\n\n-Peff\n\n[1] This wasn't a separate patch, but just an early iteration of the\n    \"ban symlinks in .gitmodules\" patch. I think the incremental is\n    just:\n\ndiff --git a/read-cache.c b/read-cache.c\nindex bfff271a3d..121c0bec69 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -937,7 +937,9 @@ static int verify_dotfile(const char *rest, unsigned mode)\n \t\t\treturn 0;\n \t\tif (S_ISLNK(mode)) {\n \t\t\trest += 3;\n-\t\t\tif (skip_iprefix(rest, \"modules\", &rest) &&\n+\t\t\tif ((skip_iprefix(rest, \"modules\", &rest) ||\n+\t\t\t     skip_iprefix(rest, \"ignore\", &rest) ||\n+\t\t\t     skip_iprefix(rest, \"attributes\", &rest)) &&\n \t\t\t    (*rest == '\\0' || is_dir_sep(*rest)))\n \t\t\t\treturn 0;\n \t\t}\n@@ -966,7 +968,9 @@ int verify_path(const char *path, unsigned mode)\n \t\t\t\tif (is_hfs_dotgit(path))\n \t\t\t\t\treturn 0;\n \t\t\t\tif (S_ISLNK(mode)) {\n-\t\t\t\t\tif (is_hfs_dotgitmodules(path))\n+\t\t\t\t\tif (is_hfs_dotgitmodules(path) ||\n+\t\t\t\t\t    is_hfs_dotgitignore(path) ||\n+\t\t\t\t\t    is_hfs_dotgitattributes(path))\n \t\t\t\t\t\treturn 0;\n \t\t\t\t}\n \t\t\t}\n@@ -974,7 +978,9 @@ int verify_path(const char *path, unsigned mode)\n \t\t\t\tif (is_ntfs_dotgit(path))\n \t\t\t\t\treturn 0;\n \t\t\t\tif (S_ISLNK(mode)) {\n-\t\t\t\t\tif (is_ntfs_dotgitmodules(path))\n+\t\t\t\t\tif (is_ntfs_dotgitmodules(path) ||\n+\t\t\t\t\t    is_ntfs_dotgitignore(path) ||\n+\t\t\t\t\t    is_ntfs_dotgitattributes(path))\n \t\t\t\t\t\treturn 0;\n \t\t\t\t}\n \t\t\t}\n"},{"id":"367018","messageId":"xmqq1s5bniuf.fsf@gitster-ct.c.googlers.com","threadId":"50223","inReplyTo":"20190117170005.GA27667@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-17T20:13:12Z","receivedAt":"2019-01-17T20:13:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Hmm. I think this commit message isn't quite right, because we also\n> skipped the patches to touch gitignore/gitattributes in verify_path().\n>\n> Are you thinking we should resurrect that behavior[1], too, or just\n> protect at the fsck level?\n>\n>> It was omitted from that series because it does not address any known\n>> exploit, but to me it seems worthwhile anyway:\n>> \n>> - if a client enables transfer.fsckObjects, this helps them protect\n>>   themselves against weird input that does *not* have a known exploit\n>>   attached, to\n>> \n>> - it generally feels more simple and robust.  Git-related tools can\n>>   benefit from this kind of check as an indication of input they can\n>>   bail out on instead of trying to support.\n>\n> I think I may just be restating your two points above, but what I'd\n> argue is:\n>\n>   - even though there's no known-interesting exploit, this can cause Git\n>     to unexpectedly read arbitrary files outside of the repository\n>     directory. That in itself isn't necessarily evil, but it's weird.\n>\n>   - there are potentially non-malicious bugs here, where we try to read\n>     .gitattributes out of the index, but obviously don't follow symlinks\n>     there\n\nFWIW, you two can count me as the third person who agrees with the\nabove points.\n\n> [1] This wasn't a separate patch, but just an early iteration of the\n>     \"ban symlinks in .gitmodules\" patch. I think the incremental is\n>     just:\n>\n> diff --git a/read-cache.c b/read-cache.c\n> index bfff271a3d..121c0bec69 100644\n> --- a/read-cache.c\n> +++ b/read-cache.c\n> @@ -937,7 +937,9 @@ static int verify_dotfile(const char *rest, unsigned mode)\n>  \t\t\treturn 0;\n>  \t\tif (S_ISLNK(mode)) {\n>  \t\t\trest += 3;\n> -\t\t\tif (skip_iprefix(rest, \"modules\", &rest) &&\n> +\t\t\tif ((skip_iprefix(rest, \"modules\", &rest) ||\n> +\t\t\t     skip_iprefix(rest, \"ignore\", &rest) ||\n> +\t\t\t     skip_iprefix(rest, \"attributes\", &rest)) &&\n>  \t\t\t    (*rest == '\\0' || is_dir_sep(*rest)))\n>  \t\t\t\treturn 0;\n>  \t\t}\n\nOK.\n\n> @@ -966,7 +968,9 @@ int verify_path(const char *path, unsigned mode)\n>  \t\t\t\tif (is_hfs_dotgit(path))\n>  \t\t\t\t\treturn 0;\n>  \t\t\t\tif (S_ISLNK(mode)) {\n> -\t\t\t\t\tif (is_hfs_dotgitmodules(path))\n> +\t\t\t\t\tif (is_hfs_dotgitmodules(path) ||\n> +\t\t\t\t\t    is_hfs_dotgitignore(path) ||\n> +\t\t\t\t\t    is_hfs_dotgitattributes(path))\n>  \t\t\t\t\t\treturn 0;\n>  \t\t\t\t}\n>  \t\t\t}\n> @@ -974,7 +978,9 @@ int verify_path(const char *path, unsigned mode)\n>  \t\t\t\tif (is_ntfs_dotgit(path))\n>  \t\t\t\t\treturn 0;\n>  \t\t\t\tif (S_ISLNK(mode)) {\n> -\t\t\t\t\tif (is_ntfs_dotgitmodules(path))\n> +\t\t\t\t\tif (is_ntfs_dotgitmodules(path) ||\n> +\t\t\t\t\t    is_ntfs_dotgitignore(path) ||\n> +\t\t\t\t\t    is_ntfs_dotgitattributes(path))\n>  \t\t\t\t\t\treturn 0;\n\nCurious that we already have these helpers, nobody seems to call\nthem in the current codebase, and we haven't seen the \"these are\nunused\" linter message on the list for a while ;-).\n\n\n"},{"id":"367033","messageId":"20190117212448.GA13100@sigill.intra.peff.net","threadId":"50223","inReplyTo":"xmqq1s5bniuf.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-17T21:24:48Z","receivedAt":"2019-01-17T21:24:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 17, 2019 at 12:13:12PM -0800, Junio C Hamano wrote:\n\n> > @@ -966,7 +968,9 @@ int verify_path(const char *path, unsigned mode)\n> >  \t\t\t\tif (is_hfs_dotgit(path))\n> >  \t\t\t\t\treturn 0;\n> >  \t\t\t\tif (S_ISLNK(mode)) {\n> > -\t\t\t\t\tif (is_hfs_dotgitmodules(path))\n> > +\t\t\t\t\tif (is_hfs_dotgitmodules(path) ||\n> > +\t\t\t\t\t    is_hfs_dotgitignore(path) ||\n> > +\t\t\t\t\t    is_hfs_dotgitattributes(path))\n> >  \t\t\t\t\t\treturn 0;\n> >  \t\t\t\t}\n> >  \t\t\t}\n> > @@ -974,7 +978,9 @@ int verify_path(const char *path, unsigned mode)\n> >  \t\t\t\tif (is_ntfs_dotgit(path))\n> >  \t\t\t\t\treturn 0;\n> >  \t\t\t\tif (S_ISLNK(mode)) {\n> > -\t\t\t\t\tif (is_ntfs_dotgitmodules(path))\n> > +\t\t\t\t\tif (is_ntfs_dotgitmodules(path) ||\n> > +\t\t\t\t\t    is_ntfs_dotgitignore(path) ||\n> > +\t\t\t\t\t    is_ntfs_dotgitattributes(path))\n> >  \t\t\t\t\t\treturn 0;\n> \n> Curious that we already have these helpers, nobody seems to call\n> them in the current codebase, and we haven't seen the \"these are\n> unused\" linter message on the list for a while ;-).\n\nHeh. Yeah, I was surprised by that, too. They were added by e7cb0b4455\n(is_ntfs_dotgit: match other .git files, 2018-05-11). The original\nversion of my series had the hunks quoted above, and then we backed off\non handling them as part of the emergency fix, but I never re-rolled the\npreparatory patch to get rid of them.\n\nI think they got overlooked because they're not file-local statics, and\nit's much harder to say \"this is never called by any function in another\ntranslation unit\". You probably have to do analysis on the complete\nbinaries using \"nm\" or similar. I think maybe Ramsay does that from time\nto time, but I don't offhand know the correct incantation.\n\nAnyway, it sounds like you like the overall direction. Does that include\nthese verify_path() bits, as well as the fsck part?\n\n-Peff\n"},{"id":"367042","messageId":"a0aef5a7-eb69-8dd8-abb7-4db6d1de4a26@ramsayjones.plus.com","threadId":"50223","inReplyTo":"20190117212448.GA13100@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2019-01-18T01:41:08Z","receivedAt":"2019-01-18T01:41:15Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 17/01/2019 21:24, Jeff King wrote:\n> On Thu, Jan 17, 2019 at 12:13:12PM -0800, Junio C Hamano wrote:\n> \n>>> @@ -966,7 +968,9 @@ int verify_path(const char *path, unsigned mode)\n>>>  \t\t\t\tif (is_hfs_dotgit(path))\n>>>  \t\t\t\t\treturn 0;\n>>>  \t\t\t\tif (S_ISLNK(mode)) {\n>>> -\t\t\t\t\tif (is_hfs_dotgitmodules(path))\n>>> +\t\t\t\t\tif (is_hfs_dotgitmodules(path) ||\n>>> +\t\t\t\t\t    is_hfs_dotgitignore(path) ||\n>>> +\t\t\t\t\t    is_hfs_dotgitattributes(path))\n>>>  \t\t\t\t\t\treturn 0;\n>>>  \t\t\t\t}\n>>>  \t\t\t}\n>>> @@ -974,7 +978,9 @@ int verify_path(const char *path, unsigned mode)\n>>>  \t\t\t\tif (is_ntfs_dotgit(path))\n>>>  \t\t\t\t\treturn 0;\n>>>  \t\t\t\tif (S_ISLNK(mode)) {\n>>> -\t\t\t\t\tif (is_ntfs_dotgitmodules(path))\n>>> +\t\t\t\t\tif (is_ntfs_dotgitmodules(path) ||\n>>> +\t\t\t\t\t    is_ntfs_dotgitignore(path) ||\n>>> +\t\t\t\t\t    is_ntfs_dotgitattributes(path))\n>>>  \t\t\t\t\t\treturn 0;\n>>\n>> Curious that we already have these helpers, nobody seems to call\n>> them in the current codebase, and we haven't seen the \"these are\n>> unused\" linter message on the list for a while ;-).\n> \n> Heh. Yeah, I was surprised by that, too. They were added by e7cb0b4455\n> (is_ntfs_dotgit: match other .git files, 2018-05-11). The original\n> version of my series had the hunks quoted above, and then we backed off\n> on handling them as part of the emergency fix, but I never re-rolled the\n> preparatory patch to get rid of them.\n> \n> I think they got overlooked because they're not file-local statics, and\n> it's much harder to say \"this is never called by any function in another\n> translation unit\". You probably have to do analysis on the complete\n> binaries using \"nm\" or similar. I think maybe Ramsay does that from time\n> to time, but I don't offhand know the correct incantation.\n\nI don't do this \"from time to time\", but *every* build on all\nplatforms! :-D\n\nAs I have mentioned before, I run the script on 'master', 'next'\nand 'pu', but I don't look at the results for 'master', I simply\nlook at the diffs master->next and next->pu.\n\nI put the output of 'static-check.pl' in the sc, nsc and psc files\n(guess which files are for which branches!). For example, tonight\nI find:\n\n    $ wc -l sc nsc psc\n      90 sc\n      90 nsc\n     100 psc\n     280 total\n    $ diff sc nsc\n    $ diff nsc psc\n    29a30,32\n    > config.o\t- repo_config_set\n    > config.o\t- repo_config_set_gently\n    > config.o\t- repo_config_set_worktree_gently\n    32a36\n    > fuzz-commit-graph.o\t- LLVMFuzzerTestOneInput\n    37a42,43\n    > hex.o\t- hash_to_hex\n    > hex.o\t- hash_to_hex_algop_r\n    74a81,83\n    > sha1-file.o\t- hash_algo_by_id\n    > sha1-file.o\t- hash_algo_by_name\n    > sha1-file.o\t- repo_has_sha1_file_with_flags\n    80a90\n    > strbuf.o\t- strbuf_vinsertf\n    $ \n\nBTW, if my memory serves (and it may not), the symbols you\nrefer to came directly into 'master' (via 'maint') as a\nresult of security updates - so I would never have seen\nthem in 'pu' or 'next'. They are, indeed, currently noted\nin the 'master' branch:\n\n    $ grep is_ntfs_ sc\n    path.o\t- is_ntfs_dotgitattributes\n    path.o\t- is_ntfs_dotgitignore\n    $ grep is_hfs_ sc\n    utf8.o\t- is_hfs_dotgitattributes\n    utf8.o\t- is_hfs_dotgitignore\n    $ \n    \nATB,\nRamsay Jones\n\n"},{"id":"367286","messageId":"20190122072359.GE28555@sigill.intra.peff.net","threadId":"50223","inReplyTo":"a0aef5a7-eb69-8dd8-abb7-4db6d1de4a26@ramsayjones.plus.com","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-22T07:23:59Z","receivedAt":"2019-01-22T07:24:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 18, 2019 at 01:41:08AM +0000, Ramsay Jones wrote:\n\n> I don't do this \"from time to time\", but *every* build on all\n> platforms! :-D\n> \n> As I have mentioned before, I run the script on 'master', 'next'\n> and 'pu', but I don't look at the results for 'master', I simply\n> look at the diffs master->next and next->pu.\n\nAh, ok, that explains it, then. As you noted, these made it straight to\nmaster because of the security embargo.\n\nThanks for satisfying my curiosity (and for running your script!).\n\nI do wonder if you might be better off comparing master@{1} to master to\nsee if anything new appears (since I assume the whole point is ignoring\nhistorical false positives, and just looking at patches under active\ndevelopment).\n\n-Peff\n"},{"id":"367332","messageId":"8ea563e7-8b3f-dc38-3aec-02253690b6b7@ramsayjones.plus.com","threadId":"50223","inReplyTo":"20190122072359.GE28555@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2019-01-22T18:19:14Z","receivedAt":"2019-01-22T18:19:20Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 22/01/2019 07:23, Jeff King wrote:\n> On Fri, Jan 18, 2019 at 01:41:08AM +0000, Ramsay Jones wrote:\n> \n>> I don't do this \"from time to time\", but *every* build on all\n>> platforms! :-D\n>>\n>> As I have mentioned before, I run the script on 'master', 'next'\n>> and 'pu', but I don't look at the results for 'master', I simply\n>> look at the diffs master->next and next->pu.\n> \n> Ah, ok, that explains it, then. As you noted, these made it straight to\n> master because of the security embargo.\n> \n> Thanks for satisfying my curiosity (and for running your script!).\n> \n> I do wonder if you might be better off comparing master@{1} to master to\n> see if anything new appears (since I assume the whole point is ignoring\n> historical false positives, and just looking at patches under active\n> development).\n\nHmm, well it's not so much 'historical false positives' as 'oh dear,\nthey managed to get through' (along with a promise to myself to get\naround to tidying up the symbols in master - yet again!). ;-)\n\nI try to make people aware of the issues, when they appear in 'pu',\nso that we have a chance not to make things worse. However, it is\nnever as simple as 'this symbol is not used/local to this file,\nplease fix' (despite what it looks like, I don't like to annoy\ncontributors with those emails :-D ). Many recent large changes\nhave been split into several series with earlier series introducing\nsymbols which 'will be used later'. Sometimes later never comes. ;-)\n\nRecently, Brian's 'bc/sha-256' branch merged into 'next', so now:\n\n  $ diff sc nsc\n  37a38,39\n  > hex.o\t- hash_to_hex\n  > hex.o\t- hash_to_hex_algop_r\n  74a77,78\n  > sha1-file.o\t- hash_algo_by_id\n  > sha1-file.o\t- hash_algo_by_name\n  $ \n\nBrian has already indicated [1] that future patches will add uses\nfor these symbols.\n\n[1] https://public-inbox.org/git/20181114021118.GN890086@genre.crustytoothpaste.net/\n\n[Just to be clear, my script only notes symbols that are not\nreferenced outside of the object file which contains its\ndefinition - so that includes file-local and unused symbols].\n\nThere are currently 90 symbols in the 'sc' file, some of which\nshould be added to the outdated 'skip list'. Just FYI, the file\nwhich has the most hits is:\n\n  $ cut -f1 sc | sort | uniq -c | sort -rn\n       26 config.o\n        6 sha1dc/sha1.o\n        6 refs.o\n        6 json-writer.o\n        3 utf8.o\n        3 sha1-file.o\n        3 revision.o\n        3 refs/ref-cache.o\n        2 vcs-svn/fast_export.o\n        2 refs/packed-backend.o\n        2 path.o\n        2 parse-options.o\n        2 graph.o\n        2 attr.o\n        1 worktree.o\n        1 trace.o\n        1 tmp-objdir.o\n        1 tempfile.o\n        1 strbuf.o\n        1 serve.o\n        1 sequencer.o\n        1 refspec.o\n        1 refs/iterator.o\n        1 read-cache.o\n        1 pkt-line.o\n        1 oidmap.o\n        1 line-log.o\n        1 ident.o\n        1 hex.o\n        1 gettext.o\n        1 fuzz-pack-idx.o\n        1 fuzz-pack-headers.o\n        1 editor.o\n        1 credential.o\n        1 convert.o\n        1 builtin/pack-objects.o\n  $ \n\n... and the symbols in that file:\n\n  $ grep config.o sc\n  config.o\t- git_config_copy_section_in_file\n  config.o\t- git_config_from_file_with_options\n  config.o\t- git_config_from_parameters\n  config.o\t- git_config_get_bool_or_int\n  config.o\t- git_config_get_maybe_bool\n  config.o\t- git_config_get_pathname\n  config.o\t- git_config_include\n  config.o\t- git_config_key_is_valid\n  config.o\t- git_configset_get_bool\n  config.o\t- git_configset_get_bool_or_int\n  config.o\t- git_configset_get_int\n  config.o\t- git_configset_get_maybe_bool\n  config.o\t- git_configset_get_pathname\n  config.o\t- git_configset_get_string\n  config.o\t- git_configset_get_string_const\n  config.o\t- git_configset_get_ulong\n  config.o\t- git_config_set_multivar_in_file\n  config.o\t- git_config_system\n  config.o\t- git_die_config_linenr\n  config.o\t- repo_config\n  config.o\t- repo_config_get_bool_or_int\n  config.o\t- repo_config_get_int\n  config.o\t- repo_config_get_maybe_bool\n  config.o\t- repo_config_get_pathname\n  config.o\t- repo_config_get_ulong\n  config.o\t- repo_config_get_value\n  $ \n  \n\nATB,\nRamsay Jones\n"}]}