{"thread":{"id":"51289","subject":"cgit and global configuration","startedAt":"2019-06-11T15:09:47Z","lastAt":"2019-10-25T21:24:26Z","messageCount":6,"participants":["Christian Hesse","Junio C Hamano","Jeff Hostetler","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"377012","messageId":"20190611170401.15d43623@leda","threadId":"51289","inReplyTo":null,"subject":"cgit and global configuration","fromName":"Christian Hesse","fromEmail":"mail@eworm.de","sentAt":"2019-06-11T15:04:01Z","receivedAt":"2019-06-11T15:09:47Z","isPatch":false,"sender":{"key":"mail@eworm.de","avatar":"https://avatars.githubusercontent.com/u/970853?v=4"},"body":"Dear Jeff, dear Junio,\n\nfor cgit we use the static git library built into the executable. This used\nto work well, but breaks with latest release v2.22.0: Our code unsets HOME\nand XDG_CONFIG_HOME to mitigate loading arbitrary configuration.\nWe have tests that use strace to check for access to directories given by\nenvironment variables.\n\nWith the new trace2 code in place at least tracing configuration is loaded\nbefore cmd_main() kicks in. This happens in trace2_initialize_fl() ->\ntr2_sysenv_load() -> read_very_early_config(). The offending commit is\nbce9db6d (\"trace2: use system/global config for default trace2 settings\") [0].\n\nI had thought about adding a new option to struct config_options and making\nxdg_config_home() and expand_user_path() conditional in\ndo_git_config_sequence() when called from read_very_early_config(). However\nthis breaks the test suite as ptrace2 tests with global configuration depend\non HOME being set to a trash directory. Any hint about how to properly solve\nthis?\nOr can we be sure configuration read at this point can not do any harm and\nupdating out tests is sufficient? I guess no as file paths can be specified.\n\n[0] https://github.com/git/git/commit/bce9db6de97c95882a7c46836bb6cc90acf0fef0\n-- \nBest regards,\nChristian Hesse\n"},{"id":"377023","messageId":"xmqqblz3lwwm.fsf@gitster-ct.c.googlers.com","threadId":"51289","inReplyTo":"20190611170401.15d43623@leda","subject":"Re: cgit and global configuration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-06-11T19:55:21Z","receivedAt":"2019-06-11T19:55:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Hesse writes:\n\n> With the new trace2 code in place at least tracing configuration is loaded\n> before cmd_main() kicks in. This happens in trace2_initialize_fl() ->\n> tr2_sysenv_load() -> read_very_early_config().\n\nI think that is as designed.\n\n> The offending commit is\n> bce9db6d (\"trace2: use system/global config for default trace2 settings\") [0].\n\nSo it does not help very much to stop at calling it \"offending\",\nwithout explaining what problem exactly you are trying to complain\nabout, and why you do not want your code traceable from the\nconfiguration.\n"},{"id":"377026","messageId":"1cdb3444-fb39-66a4-fb27-01e1617e538a@jeffhostetler.com","threadId":"51289","inReplyTo":"20190611170401.15d43623@leda","subject":"Re: cgit and global configuration","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2019-06-11T20:22:32Z","receivedAt":"2019-06-11T20:22:36Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 6/11/2019 11:04 AM, Christian Hesse wrote:\n> Dear Jeff, dear Junio,\n> \n> for cgit we use the static git library built into the executable. This used\n> to work well, but breaks with latest release v2.22.0: Our code unsets HOME\n> and XDG_CONFIG_HOME to mitigate loading arbitrary configuration.\n> We have tests that use strace to check for access to directories given by\n> environment variables.\n> \n> With the new trace2 code in place at least tracing configuration is loaded\n> before cmd_main() kicks in. This happens in trace2_initialize_fl() ->\n> tr2_sysenv_load() -> read_very_early_config(). The offending commit is\n> bce9db6d (\"trace2: use system/global config for default trace2 settings\") [0].\n> \n> I had thought about adding a new option to struct config_options and making\n> xdg_config_home() and expand_user_path() conditional in\n> do_git_config_sequence() when called from read_very_early_config(). However\n> this breaks the test suite as ptrace2 tests with global configuration depend\n> on HOME being set to a trash directory. Any hint about how to properly solve\n> this?\n> Or can we be sure configuration read at this point can not do any harm and\n> updating out tests is sufficient? I guess no as file paths can be specified.\n> \n> [0] https://github.com/git/git/commit/bce9db6de97c95882a7c46836bb6cc90acf0fef0\n> \n\nI'm not sure I fully understand the problem here, so let me\nask a few questions.\n\nIf you're using the static git library (by that I assume you\nmean libgit.a) and the call to trace2_initialize_fl() is in\nmain() in common-main.c, how it is getting called? Don't you\nhave your own main()?\n\n Looking at your source in `https://git.zx2c4.com/cgit/tree/cgit.c`\n it looks like you're defining a cmd_main() and using the rest of\n Git's Makefile, so I'm guessing you're getting common-main.c too.\n\nI'm curious why a call to read_very_early_config() before cmd_main()\ncauses problems.\n\n Again, in `https://git.zx2c4.com/cgit/tree/cgit.c` I found\n the code in prepare_repo_env() where you unset the various\n HOME variables. And that is called during your cmd_main()\n sequence. That would explain why my read_very_early_config()\n causes you problems that a call to read_early_config() inside\n your cmd_main() does not.\n\n I'm not sure I understand the reasons for the unsets and the\n need for the strace guards, but that is not my business, so\n I'll just trust that you have your reasons. And I have to\n assume that you have security concerns that supersede the\n need to do any tracing or advanced logging.\n\nAdding a new bit to `struct config_options` doesn't really help\nbecause you don't know when (or even have an opportunity) to set\nit. You've abdicated main() to common code and so your application\ndoesn't start until cmd_main() is called.\n\n And you can't really have an environment or config variable\n to say to ignore mine, because they'd be just as vulnerable.\n\n I'm not sure what you meant by a `ptrace2` test -- unless\n that is just a typo and that you meant the t/t021*.sh tests.\n And yes, these tests do test the global config setting.\n\nAs for going forward, I see 3 options:\n\n[1] update your tests to allow this. (I didn't dig thru your\n tests to see how extensive this might be.)\n\n[2] define your own version of common-main.c and link with it\n instead of git/common-main.c and delete the calls to trace2_*()\n in it.\n\n[3] define your own version of common-main.c and then call your\n prepare_repo_env() prior to trace2_initialize().\n\nGranted, I've only spent 15 minutes looking at your code, so\nI may be mistaken about several things, but I think those are\nyour options.\n\nHope this helps,\nJeff\n"},{"id":"377103","messageId":"20190612190845.GA14949@sigill.intra.peff.net","threadId":"51289","inReplyTo":"1cdb3444-fb39-66a4-fb27-01e1617e538a@jeffhostetler.com","subject":"Re: cgit and global configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-06-12T19:08:46Z","receivedAt":"2019-06-12T19:08:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 11, 2019 at 04:22:32PM -0400, Jeff Hostetler wrote:\n\n> As for going forward, I see 3 options:\n> \n> [1] update your tests to allow this. (I didn't dig thru your\n> tests to see how extensive this might be.)\n> \n> [2] define your own version of common-main.c and link with it\n> instead of git/common-main.c and delete the calls to trace2_*()\n> in it.\n> \n> [3] define your own version of common-main.c and then call your\n> prepare_repo_env() prior to trace2_initialize().\n> \n> Granted, I've only spent 15 minutes looking at your code, so\n> I may be mistaken about several things, but I think those are\n> your options.\n\nAfter reading the original report, my instinct was that (2) or (3) is\nprobably the right way forward. We could make it a little easier for\nthem by splitting up common-main a bit into two parts:\n\n - put the actual setup bits into a callable run_cmd_main() that ends\n up in libgit.a\n\n - make common-main.c a tiny shim that does:\n\n int main(int argc, const char **argv)\n {\n\t\treturn run_cmd_main(argc, argv);\n }\n\nAnd that makes it easy for them to replace just that shim with some\nsetup steps, ending in calling run_cmd_main().\n\nAll that said, it sounds like cgit doesn't actually need to do any setup\nthat _must_ be in-process; it's just modifying state like environment\nvariables that is passed down to children.\n\nSo I think it would also be sufficient to simply wrap it with something\nlike:\n\n #!/bin/sh\n unset HOME\n unset XDG_CONFIG_HOME\n exec /path/to/cgit \"$@\"\n\nBut maybe there are reasons not to want the complexity of a wrapper.\n\n-Peff\n"},{"id":"384873","messageId":"20191025181015.50bf2b92@leda","threadId":"51289","inReplyTo":"20190612190845.GA14949@sigill.intra.peff.net","subject":"Re: cgit and global configuration","fromName":"Christian Hesse","fromEmail":"mail@eworm.de","sentAt":"2019-10-25T16:10:15Z","receivedAt":"2019-10-25T16:16:52Z","isPatch":false,"sender":{"key":"mail@eworm.de","avatar":"https://avatars.githubusercontent.com/u/970853?v=4"},"body":"Jeff King on Wed, 2019/06/12 15:08:\n> On Tue, Jun 11, 2019 at 04:22:32PM -0400, Jeff Hostetler wrote:\n> \n> > As for going forward, I see 3 options:\n> > \n> > [1] update your tests to allow this. (I didn't dig thru your\n> > tests to see how extensive this might be.)\n> > \n> > [2] define your own version of common-main.c and link with it\n> > instead of git/common-main.c and delete the calls to trace2_*()\n> > in it.\n> > \n> > [3] define your own version of common-main.c and then call your\n> > prepare_repo_env() prior to trace2_initialize().\n> > \n> > Granted, I've only spent 15 minutes looking at your code, so\n> > I may be mistaken about several things, but I think those are\n> > your options. \n> \n> After reading the original report, my instinct was that (2) or (3) is\n> probably the right way forward. We could make it a little easier for\n> them by splitting up common-main a bit into two parts:\n> [...]\n\nWe decided to go another way and introduced a constructor function which does\ninitial environment setup:\n\nhttps://git.zx2c4.com/cgit/commit/?id=034e3c7d56ba71ce281886fe8525b16d4559fac1\n\nEverything (including tests) is happy with that.\n-- \nBest regards,\nChris\n"},{"id":"384886","messageId":"20191025212424.GB25625@sigill.intra.peff.net","threadId":"51289","inReplyTo":"20191025181015.50bf2b92@leda","subject":"Re: cgit and global configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-25T21:24:24Z","receivedAt":"2019-10-25T21:24:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 25, 2019 at 06:10:15PM +0200, Christian Hesse wrote:\n\n> We decided to go another way and introduced a constructor function which does\n> initial environment setup:\n> \n> https://git.zx2c4.com/cgit/commit/?id=034e3c7d56ba71ce281886fe8525b16d4559fac1\n> \n> Everything (including tests) is happy with that.\n\nThanks for following up. I think that should be a fine solution. We'd\nperhaps have considered using __attribute__((constructor)) ourselves\n(which would presumably have a non-deterministic run order), but it's\nnot sufficiently portable for our purposes. So I don't think you'll run\ninto any issues going forward with that approach.\n\n-Peff\n"}]}