5 ms·

For Apache, <Directorymatch "^/.*/\.git+/"> Order deny,allow Deny from all </Directorymatch> <Files ~ "^\.git"> Order allow,deny

For Apache, <Directorymatch "^/.*/\.git+/"> Order deny,allow Deny from all </Directorymatch> <Files ~ "^\.git"> Order allow,deny Deny from all </Files> https://serverfault.com/questions/128069/how-do-i-prevent-apache-from-serving-the-git-directory https://serverfault.com/questions/128069/how-do-i-prevent-ap...

TheDong 11y ago
Probably better to link to the stackoverflow you quite possibly copied this from so that people can see discussion / alternatives, etc: https://serverfault.com/questions/128069/how-do-i-prevent-apache-from-serving-the-git-directory https://serverfault.com/questions/128069/how-do-i-prevent-ap... See also the nginx question: https://stackoverflow.com/questions/2999353/how-do-you-hide-git-project-directories https://stackoverflow.com/questions/2999353/how-do-you-hide-... Note, if you actually did take it from the stackoverflow, you just infringed on someone's copyright; SO's user content is 'creative commons, attribution required'. Edit: Thanks for adding the attribution, all clear with copyright now :)
- markwakeford 11y ago
  I was busy editing it, thanks though. edit: sounded wayyy too snarky lol.
  - deleted 11y ago
    [deleted]
    - lambda 11y ago
      HN does not use standard Markdown. It uses a very simple markup language possibly inspired by Markdown, but with much more limited functionality. On HN, only two spaces are necessary for code: example And it only supports asterisks for italics, two blank lines for paragraphs, and turning URLs into links; it doesn't support any of the rest of Markdown.
- userbinator 11y ago
  Note, if you actually did take it from the stackoverflow, you just infringed on someone's copyright Does a simple access rule, which I can't see there being many sane ways to express, meet the minimum level of creativity/originality to be eligible for copyright...?
  - morninj 11y ago
    Probably not, but it depends on the court and the skill of the lawyers.
bsg75 11y ago
Would it be safer to not put .git within the reach of the webserver, and separate the development path from the production host path?
- bbcbasic 11y ago
  It certainly would, however like another comment I replied to ITT security doesn't have to be either-or it can be "do all the secure things". I.e. * No secrets in your repo * Only copy to the server what you need (and automate this) * Add conditions to your web server to not serve up .git, in-case the previous two checks failed. When working in teams I think having additional checks and balances and not one 'perfect solution' is vital.
  - danieltillett 11y ago
    Extremely good point - we should always aim for security in depth and especially don’t rely on people not doing stupid things, because if it is possible then someone will at some point.
jqm 11y ago
Don't you specifically have to configure Apache to allow access to dot directories in the first place? (disclaimer, I didn't read the article... but if access to dot directories were enabled.. ya, .git would be exposed, but I'm pretty sure it isn't the default Apache setting.)
- markwakeford 11y ago
  As far as I knew .ht* is the only file(s) not accessible.
morninj 11y ago
Better yet: $ rm -rf .git/ It's way safer to delete the repo history from the production server than to rely on Apache rules copied from a forum.
- thaumaturgy 11y ago
  Better better yet, don't use git to move code from test to prod. Use rsync, and exclude .git and other nuisance files. Unfortunately I can't seem to convince anyone that this is good practice. :-(
  - sago 11y ago
    Amen! Use rsync --checksum --ignore="..." unless you have a damn good reason not to (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place). rsync is even easier than SSHing to git pull, or opening up a pushable repo on a server. For once the simple approach is clearly better!
    - notduncansmith 11y ago
      One approach that I've found works well (YMMV, etc) is deploying with Ansible. It has a Git module built in (so it's almost 0 work to configure), and you can set up SSH agent forwarding so you never have put keys on the server that have access to your source control, nor manually SSH in and pull.
    - beagle3 11y ago
      > (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place) That's not true (though not completely wrong). rsync is stateless. It does not assume the version on the remote machine is "exactly how you left it"; Rather, it compares file size and file modification time; if either changed, it will do a transfer -- efficient delta transfer, usually - which might be as little as 6 bytes if the contents is exactly the same. --checksum makes it ignore file size or modification time, and compare the file checksum in order to decide if it's time for a transfer (delta or not). A malicious actor, or bad memory chips, might change your file's contents, but keep the file size and time/date the same. In that case, --checksum will overwrite that file with your source version, and a --no-checksum wouldn't. So it's not bad advice. Whether the cost in disk activity is worth it depends on your thread model, data size, and disk activity costs. (Though, if corruption is due to bad memory, this is the least of your problems) However, a corruption because of a program error / incompetent edit to the file is very unlikely to leave both the size and modification date intact - and a standard rsync will figure that out as well.

TheDong 11y ago

Probably better to link to the stackoverflow you quite possibly copied this from so that people can see discussion / alternatives, etc: https://serverfault.com/questions/128069/how-do-i-prevent-apache-from-serving-the-git-directory https://serverfault.com/questions/128069/how-do-i-prevent-ap... See also the nginx question: https://stackoverflow.com/questions/2999353/how-do-you-hide-git-project-directories https://stackoverflow.com/questions/2999353/how-do-you-hide-... Note, if you actually did take it from the stackoverflow, you just infringed on someone's copyright; SO's user content is 'creative commons, attribution required'. Edit: Thanks for adding the attribution, all clear with copyright now :)

markwakeford 11y ago
I was busy editing it, thanks though. edit: sounded wayyy too snarky lol.
- deleted 11y ago
  [deleted]
  - lambda 11y ago
    HN does not use standard Markdown. It uses a very simple markup language possibly inspired by Markdown, but with much more limited functionality. On HN, only two spaces are necessary for code: example And it only supports asterisks for italics, two blank lines for paragraphs, and turning URLs into links; it doesn't support any of the rest of Markdown.
userbinator 11y ago
Note, if you actually did take it from the stackoverflow, you just infringed on someone's copyright Does a simple access rule, which I can't see there being many sane ways to express, meet the minimum level of creativity/originality to be eligible for copyright...?
- morninj 11y ago
  Probably not, but it depends on the court and the skill of the lawyers.

bsg75 11y ago

Would it be safer to not put .git within the reach of the webserver, and separate the development path from the production host path?

bbcbasic 11y ago
It certainly would, however like another comment I replied to ITT security doesn't have to be either-or it can be "do all the secure things". I.e. * No secrets in your repo * Only copy to the server what you need (and automate this) * Add conditions to your web server to not serve up .git, in-case the previous two checks failed. When working in teams I think having additional checks and balances and not one 'perfect solution' is vital.
- danieltillett 11y ago
  Extremely good point - we should always aim for security in depth and especially don’t rely on people not doing stupid things, because if it is possible then someone will at some point.

jqm 11y ago

Don't you specifically have to configure Apache to allow access to dot directories in the first place? (disclaimer, I didn't read the article... but if access to dot directories were enabled.. ya, .git would be exposed, but I'm pretty sure it isn't the default Apache setting.)

markwakeford 11y ago
As far as I knew .ht* is the only file(s) not accessible.

morninj 11y ago

Better yet: $ rm -rf .git/ It's way safer to delete the repo history from the production server than to rely on Apache rules copied from a forum.

thaumaturgy 11y ago
Better better yet, don't use git to move code from test to prod. Use rsync, and exclude .git and other nuisance files. Unfortunately I can't seem to convince anyone that this is good practice. :-(
- sago 11y ago
  Amen! Use rsync --checksum --ignore="..." unless you have a damn good reason not to (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place). rsync is even easier than SSHing to git pull, or opening up a pushable repo on a server. For once the simple approach is clearly better!
  - notduncansmith 11y ago
    One approach that I've found works well (YMMV, etc) is deploying with Ansible. It has a Git module built in (so it's almost 0 work to configure), and you can set up SSH agent forwarding so you never have put keys on the server that have access to your source control, nor manually SSH in and pull.
  - beagle3 11y ago
    > (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place) That's not true (though not completely wrong). rsync is stateless. It does not assume the version on the remote machine is "exactly how you left it"; Rather, it compares file size and file modification time; if either changed, it will do a transfer -- efficient delta transfer, usually - which might be as little as 6 bytes if the contents is exactly the same. --checksum makes it ignore file size or modification time, and compare the file checksum in order to decide if it's time for a transfer (delta or not). A malicious actor, or bad memory chips, might change your file's contents, but keep the file size and time/date the same. In that case, --checksum will overwrite that file with your source version, and a --no-checksum wouldn't. So it's not bad advice. Whether the cost in disk activity is worth it depends on your thread model, data size, and disk activity costs. (Though, if corruption is due to bad memory, this is the least of your problems) However, a corruption because of a program error / incompetent edit to the file is very unlikely to leave both the size and modification date intact - and a standard rsync will figure that out as well.