On 2021-04-05 at 22:45:10, Albert Cui wrote: > Right, this entire proposal is trying to get to a "Git-blessed" solution, > and I should make the need clearer. A few reasons for standardizing > this come to mind: > > 1. Many existing "standard" solutions. A multitude of existing solutions for > this use case speaks to the fact that a basic config script is not sufficient. > I mentioned Husky above, but here are a few more; basically each > popular programming language environment has a solution for this. > > https://github.com/sds/overcommit - Ruby > https://github.com/pre-commit/pre-commit - Python > https://github.com/Arkweid/lefthook - Go > https://github.com/shibapm/Komondor - Swift > https://github.com/typicode/husky - Node > > These solutions all handle the installation and updating of hooks. A > "configure-hooks.sh" script doesn't handle hook updates, unless you go through > the trouble yourself of implementing and maintaining that. I think part of the problem is that an automated process to update hooks is generally a security vulnerability, since it means that untrusted remote code will automatically run on your computer. I want to be clear that I understand the desire for this feature, even though it's not a feature I would personally use, and the fact that there are many approaches means that clearly there are many people that do want this functionality. I have in the past shared hooks with others and we have mutually benefitted enormously from that fact. My concerns here are solely about the security aspects of this feature. > 3. Improving security. As you mentioned, hooks are difficult to get > right from a security > perspective, and standardizing on a single implementation allows us to > give developers > a well-vetted solution with a better security model than what exists > today. For example, > we're proposing making it very clear to users whenever there's a hook > update. This isn't > something that existing solutions do. I don't think this materially improves security. All of these options have the same security problems, and that's inherent in the solution. What we're doing here is basically giving people a built-in feature that is the equivalent of piping curl to bash and blessing it as secure when it's not. > I'll also say in general, the Git project is much more likely to get > security right than smaller > projects, where oftentimes even popular projects end up unmaintained. I agree that Git tries to be careful about security. It is for these reasons that I think Derrick and I have provided you the feedback we have here. > Agreed. We already did a security review internally at Google. The main > feedback was: > > * We need an explicit opt-in opposed to setting hooks up automatically, > e.g. a command line flag like --accept-hooks at minimum. This is primarily > to distinguish people who are just cloning a repository to browse the code > from people who are developing. > > * The average user doesn't have the ability to review hooks in general > (security is hard and obscuration is easy), and if the user has > already opted into > this feature because they are engaged in development, it's very likely > that they're > already running build scripts, so the additional attack vector here doesn't seem > like a big issue. I think you've hit the nail on the head here, but drawn a mistaken conclusion. The average user doesn't have the ability to review hooks in general and therefore cannot make an informed decision about whether to enable them, so the behavior we need to have is not to lead them to doing things which are risky from a security perspective. If my goal is to just build a product and not to run its tests, which I do with a decent number of projects, then I can audit a Go or Rust project trivially and determine if it executes arbitrary code or not during the build process and if so, inspect it and gain confidence in it. In fact, there are many projects which don't execute build scripts during the process, and therefore which are completely safe. This hook design changes that calculus dramatically. I also want to point out that people clone repositories for a variety of reasons. At GitHub, every team has its own repository with documentation. Literally every employee at the company, regardless of role, interacts with a Git repository, even people who do normally nontechnical tasks such as our in-house lawyers and our event planners. Many of these people are nontechnical, and almost none of these repositories has any software development involvement. There are also numerous people elsewhere who may work on projects such as books or other non-software in repositories who are nontechnical. Under the current model, the biggest problem these people face is accidentally corrupting their local repository and losing data. With a design that prompts them to install hooks, they face the possibility of arbitrary code execution. The reason I proposed the FAQ we have in our documentation is because I answer a decent number of questions on Stack Overflow, in addition to questions that involve users that I get pulled into at work. Overwhelmingly, the vast majority of users, even developers, are not completely comfortable with Git and are unsure about how to use it effectively (cf. https://ohshitgit.com/). If we propose to a user that they should do something like enable hooks by adding a prompt, many users will automatically say "yes" because (a) they don't understand and they trust that Git is prompting them to do something beneficial and (b) because they don't know or care and just want to get on with their lives. As a result, we're exposing people to giant social engineering attacks on behalf of potentially unscrupulous repository maintainers. This is made worse by the fact that we will prompt users even when cloning a repo that they have no intention of performing development on means that we will have users who are misled here where otherwise nothing would happen. There is a huge problem with social engineering attacks and phishing on the Internet today and I'm concerned that this is going in exactly the wrong direction. I would want to see a comprehensive security analysis feature taking into consideration social engineering attacks, the skill level and comfort with Git of the majority of Git users, and the fact that people clone repositories for many reasons other than software development. It's easy to look at this from the perspective of the typical employee at a major tech company and assume that users are generally security conscious, comfortable with Git, and primarily engaged in software development on the projects they clone, but I'm not sure any of those cases are generally true, and anyway there are many counterexamples in the real world whose use cases we need to take into account. I continue to have serious reservations about this series and approach, and I'm not sure that any proposal we can adopt here will address the security concerns. To be frank, I don't think this proposal should move forward in its current state or otherwise, since I think the security problems are inherent in this approach and fundamentally can't be fixed. This is, as should be obvious from my email address, my personal opinion, despite my reference to my employer above. Unless otherwise stated, I don't speak for my employer and they don't speak for me. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
