{"thread":{"id":"54204","subject":"Proposal: server-advertised config options","startedAt":"2020-09-07T17:03:20Z","lastAt":"2020-09-10T04:28:06Z","messageCount":9,"participants":["Drew DeVault","Christian Couder","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"405128","messageId":"C5HAJYI9RDPU.1CPN4E1JCQCAQ@homura","threadId":"54204","inReplyTo":null,"subject":"Proposal: server-advertised config options","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-09-07T16:52:12Z","receivedAt":"2020-09-07T17:03:20Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"The basic idea is that the server could advertise some config options\nwhich it recommends the client sets for a given repo after a fetch. Some\npossible use-cases for this feature include setting:\n\n- format.subjectPrefix to 'PATCH my-project'\n- sendemail.to to the mailing list address\n- push.pushOption to recommended push options\n\nUpon cloning, each recommended config option would be displayed to the\nuser, and they would be prompted ([Y/n]) to agree to set that value in\nthe config file for that repository. Additionally, there would be a\nconfig option which white-lists a list of config options which are\nautomatically agreed to without prompting, and each config option would\nhave one of the following states:\n\n- accept-silent: set the option without printing a message\n- accept-verbose: set the option and display a message\n- prompt: prompt the user to set this config option\n- reject-silent: silently refuse to set this config option\n- reject-verbose: refuse to set this config option and display a message\n\nWe would default to reject-verbose for all unknown config options and\ninclude a set of defaults which specifies the appropriate trust level\nfor various useful benign options (such as the examples above).\n\nThe implementation would involve advertising config-advertisement in the\nfetch protocol. Both the client and server would have to agree to use\nit. If the server supports it but the client does not (in the case of an\nold client), it could fall back to printing the list of recommended\noptions to stderr.\n\nTo choose which config options to advertise, a new option would be\nintroduced (uploadpack.advertiseOptions) for example, which has a list\nof .git/config options from the remote repository to forward to the\nclient.\n\nThis would be a lot of work so I'd like to float it for discussion\nbefore getting started. What do you guys think?\n"},{"id":"405132","messageId":"CAP8UFD1wS9GDhek0Rbo=E+csf_u32D+22EsLom=AFu5D1pAYYg@mail.gmail.com","threadId":"54204","inReplyTo":"C5HAJYI9RDPU.1CPN4E1JCQCAQ@homura","subject":"Re: Proposal: server-advertised config options","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-09-07T18:49:03Z","receivedAt":"2020-09-07T18:49:22Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Sep 7, 2020 at 7:06 PM Drew DeVault <sir@cmpwn.com> wrote:\n>\n> The basic idea is that the server could advertise some config options\n> which it recommends the client sets for a given repo after a fetch. Some\n> possible use-cases for this feature include setting:\n>\n> - format.subjectPrefix to 'PATCH my-project'\n> - sendemail.to to the mailing list address\n> - push.pushOption to recommended push options\n\nIt could be useful to suggest promisor/partial clone remote config options too.\n\n> Upon cloning, each recommended config option would be displayed to the\n> user, and they would be prompted ([Y/n]) to agree to set that value in\n> the config file for that repository.\n\nMaybe the default should be \"N\" instead of \"Y\" for more security. Also\nwhen not using a terminal, it should do nothing by default too.\n\n> Additionally, there would be a\n> config option which white-lists a list of config options which are\n> automatically agreed to without prompting,\n\nThis might be dangerous if this option can also be proposed by the\nserver, as it could first propose a big list of white listed options\nto the client.\n\n> and each config option would\n> have one of the following states:\n>\n> - accept-silent: set the option without printing a message\n> - accept-verbose: set the option and display a message\n> - prompt: prompt the user to set this config option\n> - reject-silent: silently refuse to set this config option\n> - reject-verbose: refuse to set this config option and display a message\n>\n> We would default to reject-verbose for all unknown config options and\n> include a set of defaults which specifies the appropriate trust level\n> for various useful benign options (such as the examples above).\n>\n> The implementation would involve advertising config-advertisement in the\n> fetch protocol. Both the client and server would have to agree to use\n> it. If the server supports it but the client does not (in the case of an\n> old client), it could fall back to printing the list of recommended\n> options to stderr.\n>\n> To choose which config options to advertise, a new option would be\n> introduced (uploadpack.advertiseOptions) for example, which has a list\n> of .git/config options from the remote repository to forward to the\n> client.\n>\n> This would be a lot of work so I'd like to float it for discussion\n> before getting started. What do you guys think?\n\nMy opinion is that you might not want to start working on all the\nabove at once. It might be better to start small and safe while\nleaving the door open to further improvements.\n"},{"id":"405134","messageId":"C5HD1Z4AEVWJ.2QPVVNIQGBAM7@homura","threadId":"54204","inReplyTo":"CAP8UFD1wS9GDhek0Rbo=E+csf_u32D+22EsLom=AFu5D1pAYYg@mail.gmail.com","subject":"Re: Proposal: server-advertised config options","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-09-07T18:49:46Z","receivedAt":"2020-09-07T18:51:10Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Mon Sep 7, 2020 at 2:49 PM EDT, Christian Couder wrote:\n> > Upon cloning, each recommended config option would be displayed to the\n> > user, and they would be prompted ([Y/n]) to agree to set that value in\n> > the config file for that repository.\n>\n> Maybe the default should be \"N\" instead of \"Y\" for more security. Also\n> when not using a terminal, it should do nothing by default too.\n\nAck, ack.\n\n> > Additionally, there would be a config option which white-lists a\n> > list of config options which are automatically agreed to without\n> > prompting,\n>\n> This might be dangerous if this option can also be proposed by the\n> server, as it could first propose a big list of white listed options\n> to the client.\n\nAye, I think we'd prevent the server from advertising that option\nperiod, as a hard-coded restriction.\n\n> My opinion is that you might not want to start working on all the\n> above at once. It might be better to start small and safe while\n> leaving the door open to further improvements.\n\nWhile this work could easily be (and ought to be) broken up into small\ncommits which introduce it one piece at a time, I'm not sure that any\nsubset of the pieces is *shippable*. Do you have a suggestion for how it\ncould be broken up into small, shippable pieces?\n"},{"id":"405135","messageId":"xmqqimcp1kvf.fsf@gitster.c.googlers.com","threadId":"54204","inReplyTo":"C5HAJYI9RDPU.1CPN4E1JCQCAQ@homura","subject":"Re: Proposal: server-advertised config options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-07T18:51:00Z","receivedAt":"2020-09-07T18:51:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> The basic idea is that the server could advertise some config options\n> which it recommends the client sets for a given repo after a fetch. Some\n> possible use-cases for this feature include setting:\n>\n> - format.subjectPrefix to 'PATCH my-project'\n> - sendemail.to to the mailing list address\n> - push.pushOption to recommended push options\n>\n> Upon cloning, each recommended config option would be displayed to the\n> user, and they would be prompted ([Y/n]) to agree to set that value in\n> the config file for that repository. Additionally, there would be a\n> config option which white-lists a list of config options which are\n> automatically agreed to without prompting, and each config option would\n> have one of the following states:\n>\n> - accept-silent: set the option without printing a message\n> - accept-verbose: set the option and display a message\n> - prompt: prompt the user to set this config option\n> - reject-silent: silently refuse to set this config option\n> - reject-verbose: refuse to set this config option and display a message\n>\n> We would default to reject-verbose for all unknown config options and\n> include a set of defaults which specifies the appropriate trust level\n> for various useful benign options (such as the examples above).\n>\n> The implementation would involve advertising config-advertisement in the\n> fetch protocol. Both the client and server would have to agree to use\n> it. If the server supports it but the client does not (in the case of an\n> old client), it could fall back to printing the list of recommended\n> options to stderr.\n>\n> To choose which config options to advertise, a new option would be\n> introduced (uploadpack.advertiseOptions) for example, which has a list\n> of .git/config options from the remote repository to forward to the\n> client.\n>\n> This would be a lot of work so I'd like to float it for discussion\n> before getting started. What do you guys think?\n\nAssuming I am among the guys (do you solicit opinions from gals, by\nthe way?), here are a few unconnected random thoughts.\n\nI do not want to see this as a \"server\" thing.  All the examples are\n\"per project preference\" and I do agree it would be nice to have a\nstandardised way for projects to communicate their preference to\ntheir participants.  Regardless of the hosting site I clone and\nfetch my project from, I'd want to see it communicated consistently\nto them.\n\nWhich means that it must not be a patch to the \"server\" component to\nwhat responds to your \"git fetch\" and \"git clone\" (i.e. upload-pack)\nas some hosting sites do not even use upload-pack.\n\nAlso, I do not want to see this as a \"git\" thing and I mean it in\ntwo ways.  \n\nIn addition to your examples of \"per project preference\", there are\nprojects' coding style guides, etc., that we do not enforce as git\nconfig at all, e.g. how wide your editors TAB and single level of\nindentation should be.  It will unnecessarily narrow your view to\nassume that the kind of \"per project preference\" you convey from the\nproject to its participants need to be the Git configuration and\nnothing else.\n\nAnd this should not be a \"git the SCM\" thing.  If you download and\nextract a release tarball and write a patch on top of it, you should\nbe able to learn what the project convention of what the \"[PATCH]\"\nprefix looks like and what the mailing list address is, even though\nyou did not clone with \"git\".\n\nAll of the above leads to a design to have a common convention\nwidely shared among projects to express project preferences over\ndifferent kind of tools, among which Git is one of them, and store\nit in a known location in the projects' trees.  Most importantly,\nthere must not be any Git protocol extension for doing this kind of\nthing.  \n\nDon't limit the user's choice in either of these two ways.  The\npreferences for tools other than Git should be sharable with the\nsame ease as preference for Git, and the preference should be\nsharable with the same ease to those who use Git and those who\ndon't.\n\nPerhaps have a .project-preference/ directory at the root level of\nthe project tree, talk with other SCM vendors and editor vendors to\ndesign what kind of information are recorded in that directory and\nhow, and write a script to work on that to map the project\npreference information to git configuration while other SCM vendors\nand editor vendors write their scripts to help their users to map\nthe project preference information to the configuration files that\ntheir tools use.  Then you can either write a wrapper around \"git\nclone\" to first run \"git clone\" and then run these scripts you\nprepare to process the contents of the .project-preference\ndirectory, or perhaps trigger these scripts from the post-clone hook.\n"},{"id":"405138","messageId":"C5HDRLX7ZPR5.1TFS72T7PBXSJ@homura","threadId":"54204","inReplyTo":"xmqqimcp1kvf.fsf@gitster.c.googlers.com","subject":"Re: Proposal: server-advertised config options","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-09-07T19:23:15Z","receivedAt":"2020-09-07T19:45:35Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Mon Sep 7, 2020 at 2:51 PM EDT, Junio C Hamano wrote:\n> Assuming I am among the guys (do you solicit opinions from gals, by\n> the way?), here are a few unconnected random thoughts.\n\nGuys is gender netural where I'm from, of course guys and gals and\nanyone else are invited to comment :)\n\n> I do not want to see this as a \"server\" thing. All the examples are\n> \"per project preference\" and I do agree it would be nice to have a\n> standardised way for projects to communicate their preference to\n> their participants. Regardless of the hosting site I clone and\n> fetch my project from, I'd want to see it communicated consistently\n> to them.\n\nThe server I have in mind (git.sr.ht) is a little bit different in that\nmost of those examples I gave would be configured automatically on the\nserver side. My server software knows where your mailing list is, for\nexample. My goal is to try and make this as hands-off and \"it just\nworks\" as possible.\n\n> In addition to your examples of \"per project preference\", there are\n> projects' coding style guides, etc., that we do not enforce as git\n> config at all, e.g. how wide your editors TAB and single level of\n> indentation should be. It will unnecessarily narrow your view to\n> assume that the kind of \"per project preference\" you convey from the\n> project to its participants need to be the Git configuration and\n> nothing else.\n\nI think there's a difference between preferences regarding the contents\nof the repository (e.g. style guide), and preferences regarding the\nadministration and usage of the repository itself (e.g. this feature I'm\nproposing). I think the argument for integration with git is much\nstronger for the latter.\n\n> All of the above leads to a design to have a common convention\n> widely shared among projects to express project preferences over\n> different kind of tools, among which Git is one of them, and store\n> it in a known location in the projects' trees. Most importantly,\n> there must not be any Git protocol extension for doing this kind of\n> thing.\n\nStoring a file in your project tree to handle this configuration would\neliminate the \"hands off\" feature I was aiming for. We also have a\npolicy which forbids our software from making any automated changes to\nthe contents of your git repository - we just don't consider it\nappropriate in the domain of our server software's responsibilities.\n\nSome sort of common config file for this purpose, in-tree, would perhaps\nbe useful, but it would remove a lot of the value-add that I'm seeking\nto provide. I already posess most of the necessary information\nserver-side and I can offer it to clients without any explicit\ninvolvement from the project maintainers.\n\nAlso, the conventions for tooling-related files in-tree like this is\ncurrently very disorganized within the ecosystem. Between .editorconfig,\n.gitattributes, .github/funding.yml, a dozen CI systems, and who knows\nwhat else, there's no common consensus on where to put files like this\nor what they should look like. I think that securing consensus for this\nwould involve reaching out to these projects, and the scope of that\neffort and the necessary follow-up developments and compatibility\nplanning on behalf of these projects would be...  astonishingly large.\n\nAnd, ultimately, even with a common configuration, we'd end up having to\nadd vendor-specific extensions, for example to support the example of\npush options given in the initial mail.\n\nSo, in summary, based on your suggestions this proposal could grow\n10x-100x in scope and lose no small degree of the desired utility. Maybe\nyours is a worthwhile idea, but it poorly solves the particular problem\nI set out to solve and I lack the time/motivation to work on that\napproach.\n"},{"id":"405140","messageId":"20200907205242.GF241078@camp.crustytoothpaste.net","threadId":"54204","inReplyTo":"C5HDRLX7ZPR5.1TFS72T7PBXSJ@homura","subject":"Re: Proposal: server-advertised config options","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-09-07T20:52:42Z","receivedAt":"2020-09-07T20:52:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-09-07 at 19:23:15, Drew DeVault wrote:\n> On Mon Sep 7, 2020 at 2:51 PM EDT, Junio C Hamano wrote:\n> > I do not want to see this as a \"server\" thing. All the examples are\n> > \"per project preference\" and I do agree it would be nice to have a\n> > standardised way for projects to communicate their preference to\n> > their participants. Regardless of the hosting site I clone and\n> > fetch my project from, I'd want to see it communicated consistently\n> > to them.\n> \n> The server I have in mind (git.sr.ht) is a little bit different in that\n> most of those examples I gave would be configured automatically on the\n> server side. My server software knows where your mailing list is, for\n> example. My goal is to try and make this as hands-off and \"it just\n> works\" as possible.\n\nThe Git security model doesn't permit untrusted config options, so I\nthink it's risky to add support for config options from the server\nside.  We need to consider not only advanced users who are going to be\nable to make a good decision here, but novice users who are struggling\nto understand how Git works and are prone to social engineering.  Just\nbecause your server is not malicious does not mean that others aren't.\n\nIn addition, if I'm cloning a repository just to build it, I don't want\nto be prompted to set those configuration options at all.  My experience\nin Git hosting is that clones and fetches far, far outnumber pushes, so\nadding a prompting feature adds a bunch of impediment with little gain\nfor the vast majority of users.\n\n> > All of the above leads to a design to have a common convention\n> > widely shared among projects to express project preferences over\n> > different kind of tools, among which Git is one of them, and store\n> > it in a known location in the projects' trees. Most importantly,\n> > there must not be any Git protocol extension for doing this kind of\n> > thing.\n> \n> Storing a file in your project tree to handle this configuration would\n> eliminate the \"hands off\" feature I was aiming for. We also have a\n> policy which forbids our software from making any automated changes to\n> the contents of your git repository - we just don't consider it\n> appropriate in the domain of our server software's responsibilities.\n\nThat doesn't mean you can't provide a downloadable shell script that\npeople could check into their repositories to configure this for the\nuser.  That's the typical way that projects that use standardized hooks\nwork, for example, and it lets the user decide whether they want to\nconfigure these things (by running the script) or not (by not running\nit).  Users who are not interested in becoming contributors need not\never be bothered with it at all.\n\nIt doesn't automatically \"just work\", but it also lets projects decide\nfor themselves what their settings should be.  Just because a site\noffers, say, mailing lists, doesn't mean that folks will want to use\nthose mailing lists.  For example, the Go language repository is hosted\non GitHub, but uses Gerrit for code review, not GitHub pull requests.\n\n> Also, the conventions for tooling-related files in-tree like this is\n> currently very disorganized within the ecosystem. Between .editorconfig,\n> .gitattributes, .github/funding.yml, a dozen CI systems, and who knows\n> what else, there's no common consensus on where to put files like this\n> or what they should look like. I think that securing consensus for this\n> would involve reaching out to these projects, and the scope of that\n> effort and the necessary follow-up developments and compatibility\n> planning on behalf of these projects would be...  astonishingly large.\n\nYou can try to standardize all repository dotfiles, or you can just\nprovide a configuration file and documentation and let people adopt it\nas you go, which is how most of these work.  If your design is\ndesirable, people will adopt it and spread it across projects.\n-- \nbrian m. carlson: Houston, Texas, US\n"},{"id":"405191","messageId":"C5I1TZ1OCN40.2BHKV9GD572FL@homura","threadId":"54204","inReplyTo":"20200907205242.GF241078@camp.crustytoothpaste.net","subject":"Re: Proposal: server-advertised config options","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-09-08T14:14:47Z","receivedAt":"2020-09-08T20:00:07Z","isPatch":false,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Mon Sep 7, 2020 at 4:52 PM EDT, brian m. carlson wrote:\n> The Git security model doesn't permit untrusted config options, so I\n> think it's risky to add support for config options from the server\n> side. We need to consider not only advanced users who are going to be\n> able to make a good decision here, but novice users who are struggling\n> to understand how Git works and are prone to social engineering. Just\n> because your server is not malicious does not mean that others aren't.\n\nHm. If we view some of these use-cases as legitimate, maybe it would\nmake sense to only permit a hard-coded list of config options to be\nadvertised, removing all other configurability to avoid letting users\nconfigure themselves into a compromised system (potentially via social\nengineering). For example, project policies like sendmail.to and config\noptions in the server's domain like push options would be in-scope, but\nsomething like core.editor would be out of scope.\n\n> In addition, if I'm cloning a repository just to build it, I don't want\n> to be prompted to set those configuration options at all. My experience\n> in Git hosting is that clones and fetches far, far outnumber pushes, so\n> adding a prompting feature adds a bunch of impediment with little gain\n> for the vast majority of users.\n\nThat alternative approach would also eliminate the need for prompting.\n\n> That doesn't mean you can't provide a downloadable shell script that\n> people could check into their repositories to configure this for the\n> user.\n\nYeah, but that also eliminates most of the convenience factor and is\neven more of a risk.\n\n> It doesn't automatically \"just work\", but it also lets projects decide\n> for themselves what their settings should be. Just because a site\n> offers, say, mailing lists, doesn't mean that folks will want to use\n> those mailing lists. For example, the Go language repository is hosted\n> on GitHub, but uses Gerrit for code review, not GitHub pull requests.\n\nNote that in the case of sourcehut, mailing lists are optional. It's not\nlike GitHub where you can't turn off pull requests and have to deal with\nrejecting them manually or set up a bot to auto-close them or something.\n"},{"id":"405297","messageId":"20200910014520.GJ241078@camp.crustytoothpaste.net","threadId":"54204","inReplyTo":"C5I1TZ1OCN40.2BHKV9GD572FL@homura","subject":"Re: Proposal: server-advertised config options","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-09-10T01:45:20Z","receivedAt":"2020-09-10T02:00:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-09-08 at 14:14:47, Drew DeVault wrote:\n> On Mon Sep 7, 2020 at 4:52 PM EDT, brian m. carlson wrote:\n> > The Git security model doesn't permit untrusted config options, so I\n> > think it's risky to add support for config options from the server\n> > side. We need to consider not only advanced users who are going to be\n> > able to make a good decision here, but novice users who are struggling\n> > to understand how Git works and are prone to social engineering. Just\n> > because your server is not malicious does not mean that others aren't.\n> \n> Hm. If we view some of these use-cases as legitimate, maybe it would\n> make sense to only permit a hard-coded list of config options to be\n> advertised, removing all other configurability to avoid letting users\n> configure themselves into a compromised system (potentially via social\n> engineering). For example, project policies like sendmail.to and config\n> options in the server's domain like push options would be in-scope, but\n> something like core.editor would be out of scope.\n\nsendmail.to would potentially leak information if you cloned a\nrepository from one server but intended to use it internally to send\npatches elsewhere, especially if you'd already set that option globally.\nI'm pretty sure that other scenarios exist where even mundane config\noptions can be leveraged as an attack vector.\n\nThat's the problem: we as the defenders have to come up with every\npossible scenario to allow a trusted config item, and an attacker just\nhas to come up with one scenario to exploit it.  We've seen security\nproblems in the past with .gitmodules multiple times because it's\nserver-sent config (in the repository).  Vim has also seen multiple CVEs\nfrom untrusted configuration (modelines).  It's just a minefield waiting\nto happen.\n\nAs a result, I'm very much opposed to allowing any config options to be\ncopied from the server.\n\n> > In addition, if I'm cloning a repository just to build it, I don't want\n> > to be prompted to set those configuration options at all. My experience\n> > in Git hosting is that clones and fetches far, far outnumber pushes, so\n> > adding a prompting feature adds a bunch of impediment with little gain\n> > for the vast majority of users.\n> \n> That alternative approach would also eliminate the need for prompting.\n\nAre you suggesting that we just accept the server's settings without\nprompting?  I certainly don't think that's a viable approach.\n\n> > That doesn't mean you can't provide a downloadable shell script that\n> > people could check into their repositories to configure this for the\n> > user.\n> \n> Yeah, but that also eliminates most of the convenience factor and is\n> even more of a risk.\n\nIt's also the standard approach that every project uses already, and it\nhas the benefit that the user can inspect it at their leisure before\nrunning it.\n-- \nbrian m. carlson: Houston, Texas, US\n"},{"id":"405310","messageId":"xmqqr1ras1bn.fsf@gitster.c.googlers.com","threadId":"54204","inReplyTo":"20200910014520.GJ241078@camp.crustytoothpaste.net","subject":"Re: Proposal: server-advertised config options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-10T04:27:56Z","receivedAt":"2020-09-10T04:28:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> ...  We've seen security\n> problems in the past with .gitmodules multiple times because it's\n> server-sent config (in the repository).\n\nExactly.  For some reason some people still seem to think that it is\nwasteful that we force users to approve/reject copying from .gitmodules\nto .git/config and push to read and use settings directly from the\nformer---I think it is a huge mistake.\n\n> As a result, I'm very much opposed to allowing any config options to be\n> copied from the server.\n\n+1.\n\n> It's also the standard approach that every project uses already, and it\n> has the benefit that the user can inspect it at their leisure before\n> running it.\n\n+100 ;-)\n"}]}