<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-ap... <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-ap...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.
$ 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.Unfortunately I can't seem to convince anyone that this is good practice. :-(
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!
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.
If the comparison is with using Git, then it is clear you're not so resource constrained that you can't countenance running MD5s, since Git would run shasum.
I think in our current laissez-faire climate w.r.t. security, I think recommending leaving security on the basis of saving a few cycles isn't very wise.
> It does not assume the version on the remote machine is "exactly how you left it"
I was ambiguous and sloppy, sorry. It doesn't not check for changes in a secure way, but assumes that, as long as the meta-data for the file matches, the content is as you left it.
When Linus built git, he specifically did so around sha1 to ensure that you ensure the data you think you have in the file, you do in fact have. rsync --checksum is thus a reasonable replacement for git deployment, but rsync --no-checksum isn't, imho.
Sorry if I was vague or misleading, thanks for the clarification.
Remember, git providers go down (i.e. DDOS to GitHub or internal fail at BitBucket). Don't depend on git being up to deploy your code or you'll look like a fool next time a DDOS at GH coincides with a deployment.
See also the nginx question: 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 :)
edit: sounded wayyy too snarky lol.
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...?