191–200 of 214 posts
Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…
Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…
Some of the other commenters suggest adding git-dir and work-tree to the git commands, but there's a better solution: use the --separate-git-dir option when cloning the repository. For example: git clone --separate-git-dir= where is outside of any directory served by the web server and is the htdocs root. This option makes /.git a file whose content is: gitdir: The advantage is that all git commands work as usual, wi…
I disagree It may be possible that gitdir is still accessible through a misconfiguration or security issue (and you're giving them exactly where to look) Production servers have no business having the .git directory anywhere.
I agree with you in principle, but in practice this is not always possible, there are situations when having a git checkout in production is better than nothing.
I've seen WordPress sites where a semi-technical administrator updates plugins and themes directly in production: with that git checkout I would at least be able to track the changes and pull them in a dev or staging environment.
This could be the first step to a saner deployment workflow for those sites, where production gets changes that have been tested and validated elsewhere.
The model of exporting a Unix directory as the structure of a website is barely good enough for static sites (you'll get into all kinds of problems with URL management), and is completely unsuited for applications.
Now, of course, PHP was created as a tool to add a visitor counter at the bottom to your pages. With a bit of caution, it's indeed secure enough for that. Nowadays people create huge applications using the same security model, and PHP developers don't even think about changing it.
How can a project be accessed/downloaded with just the .git folder?
Wouldn't be terribly difficult to write a script to crawl it. Git's format is well known and documented.
(Is JSON an abstraction? Not really, as it's a concrete spec, but its general kind of serialization format is an (incomplete) abstraction.)
Earlier quoted context omitted.
I'm surprised this isn't higher up. Are there any arguments against ENV variables in favor of something else?
Here's my caution to this. If low level processes can do "ps aux", and they see something like: DB_USER=scott DB_PASSWORD=b3withm3pl3aze /usr/bin/python webapp.py That could be troublesome if an attacker figured out a way to run remote commands on your server even as an unprivileged user.
It would be kind of weird to include that considering how argv works.
Earlier quoted context omitted.
Very simple setup. You have: .git web/index.php src/*.php Make the document root /full/path/to/web/index.php. Edit: Also use a deployment tool like Capistrano which removes the .git directory as well.
Yes, it is easily avoided. But it is still violated by lots of PHP projects, including well-known projects with large userbases: * Wordpress * Tiki * ... and so on. I don't think this is by accident: This technique is too old and well-known to be ignored by large projects. Rather, they conciously don't do that to cause less hassle for the occasional admin: Those can simply dump it into some directory and don't have t…
Earlier quoted context omitted.
Yes, it is easily avoided. But it is still violated by lots of PHP projects, including well-known projects with large userbases: * Wordpress * Tiki * ... and so on. I don't think this is by accident: This technique is too old and well-known to be ignored by large projects. Rather, they conciously don't do that to cause less hassle for the occasional admin: Those can simply dump it into some directory and don't have t…
Drupal, MediaWiki, Laravel, Slim, it's a pretty long list, and it includes projects that target Serious Devlopers.
Look at any larger Python (Django/Flask/...) or Ruby (Rails/...) project, and you will always find a proper "public" directory, although it may be named differently.
Not sure about Perl though ...
Without directory browsing, is it exorbitantly difficult to rebuild the contents of a .git folder from the known parts of a repo, eg, .Git/config, .Git/HEAD? I'm a novice when it comes to git, been relying on the github GUI, so I don't really know where to start.
Thank you for any insight!