4 ms·

No, I don't care what computer they are on. I want anyone that pulls my repo to have my hooks etc by default. Even me! Listen, I know there are workarounds, I k

No, I don't care what computer they are on. I want anyone that pulls my repo to have my hooks etc by default. Even me! Listen, I know there are workarounds, I know there are ways to solve this. My point is they suck.

cesarb 5y ago
> I want anyone that pulls my repo to have my hooks etc by default. That would be a security vulnerability. Hooks in git are not sandboxed, so you'd have arbitrary code execution in the machine of anyone that pulls your repository. In fact, some of the worst security issues the git project has had were ways of tricking it (usually through case-insensitive or normalizing filesystems) into setting arbitrary hooks.
- jayd16 5y ago
  It doesn't need to be without user approval. I would be more than happy to email out a trustable commit hash or what have you.
  - chrisandchris 5y ago
    Having an option to opt-out of some enforcement is somehow not much better than no enforcement at all.
- blackoil 5y ago
  Which may be an issue in open-source, but not so much in a captive environment. When I clone an internal repo and run it on local, I myself don't do a security review of it. I trust rest of the people in company to have reviewed the code before committing to main branch. Company has the remote root access on the device it provided and we have internal binaries/scripts regularly used on laptops.
- tptacek 5y ago
  How is this risk any different from that of a Makefile?
  - cesarb 5y ago
    When one executes code from a Makefile, one expects arbitrary code execution. When cloning a repository, or updating a clone of a repository, one does not expect arbitrary code execution. Moreover, one can inspect a Makefile before running code from it, by cloning the repository and looking at the Makefile with a text editor; but one cannot inspect what will be cloned before cloning it (and even if you could, for instance by looking at it through a web interface, there's an obvious TOCTOU risk).
    - tptacek 5y ago
      I see the problem with hooks that run when a repository is cloned. I don't see it with hooks that run when code is committed.
      - tedunangst 5y ago
        I might consider fixing a readme typo in somebody's project while taking less precautions than I would running make.

cesarb 5y ago

> I want anyone that pulls my repo to have my hooks etc by default. That would be a security vulnerability. Hooks in git are not sandboxed, so you'd have arbitrary code execution in the machine of anyone that pulls your repository. In fact, some of the worst security issues the git project has had were ways of tricking it (usually through case-insensitive or normalizing filesystems) into setting arbitrary hooks.

jayd16 5y ago
It doesn't need to be without user approval. I would be more than happy to email out a trustable commit hash or what have you.
- chrisandchris 5y ago
  Having an option to opt-out of some enforcement is somehow not much better than no enforcement at all.
blackoil 5y ago
Which may be an issue in open-source, but not so much in a captive environment. When I clone an internal repo and run it on local, I myself don't do a security review of it. I trust rest of the people in company to have reviewed the code before committing to main branch. Company has the remote root access on the device it provided and we have internal binaries/scripts regularly used on laptops.
tptacek 5y ago
How is this risk any different from that of a Makefile?
- cesarb 5y ago
  When one executes code from a Makefile, one expects arbitrary code execution. When cloning a repository, or updating a clone of a repository, one does not expect arbitrary code execution. Moreover, one can inspect a Makefile before running code from it, by cloning the repository and looking at the Makefile with a text editor; but one cannot inspect what will be cloned before cloning it (and even if you could, for instance by looking at it through a web interface, there's an obvious TOCTOU risk).
  - tptacek 5y ago
    I see the problem with hooks that run when a repository is cloned. I don't see it with hooks that run when code is committed.
    - tedunangst 5y ago
      I might consider fixing a readme typo in somebody's project while taking less precautions than I would running make.