I'd love to hear—maybe I missed another blog post—why they went with the single release manager, where only one person can merge and deploy. What happens if Doug is sick or on vacation? Or even just in a meeting? What is a typical amount of time for a change to sit in "ready for merge" or merged but not deployed?
The primary benefit is that it creates a single point of communication for the developers, the designers, and the QA. It also helps with prioritizing changes that could be conflicting and, in the same vein, helps prevent bad releases or merges. And, of course, anyone can do this job. If I'm not available, someone picks up the slack. I just volunteered because I was interested and available.
All that said, I think that letting every developer deploy would not be a bad idea at all. The problem is that our team is too big to do that without creating more robust deployment tools and too small to dedicate enough time to doing so. My hope is that one day we can get there, though.
This task used to be more distributed over the server-side devs, but having a single release manager who does this most of the time and other people who do it occasionally and/or when the release manager isn't working seems to work well.
I don't really see why a developer couldn't also merge changes into "the official Build repo". Or is the "release manager" just a term for the person deciding what gets released when?
(Disclaimer: I'm the other guy behind BundleScout.)
The Django project does a fantastic job with announcements. (So does Rails.) And if every open source project had the infrastructure to make that much noise, the world would be a better place. But of the 100k or so Python/Ruby/NPM projects I know about, only a small handful do, or could even manage it.
And if they did, would you want to be on every one of their mailing lists?
Bleach, for example, has more users than I have twitter followers, so I doubt most of them heard about v1.2.1. (Out today! Go get it!)
> but it kinda sucks that you'd make people pay to hear about security issues
Well, like you said, there are other ways to hear about updates, at least from the big projects. This is the convenience of not needing to join dozens of mailing lists and/or check dozens of websites periodically.
Would you maybe consider making a distinction between security releases and regular run-of-the-mill update releases?
I see a real value in a service to let me know that there's a new version of one of the dozens of things I depend on. But like I said, it seems janky to rely on a for-pay service to find out about security vulnerabilities. So what about making the security notification free to all users, with the non-security update notifications a for-pay addon? Seems like a good way to strike a balance between developing a self-sustaining business and helping out a community.
I agree with all of your advice about hardening most servers, but a couple of things...
> In the case of PHP, there is no security concern by it just sitting on your hard drive.
It's a surface area question. I could go into more details of the history of why it was there and configured (if you read further, you'd see that it was part of our puppet manifests, and for a reason). But you reduce the surface area of attack by reducing the number of things that can execute arbitrary code. And if you aren't using PHP at all, "yum remove php" saves you disk space and surface area, even if you have another colossal screw up (like we did).
> The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.
Well, the most it could do is, if you've screwed up someplace else, execute arbitrary code as the webserver user on the machine, thanks to the backtick operator.
If you've got a backtick operator, you are already running code, thus game over. And if puppet is mis-configuring your system, well that's got implications that go beyond just what software is installed.
Advocating a smaller surface area in your example is the same thing as telling someone to buy a bigger/better lock to protect their door. Sure, it makes your door more secure by reducing the "surface area" of a lesser-designed lock. But if you had done the basic auditing of the outside of the building, you'd see the huge glass window fitted next to the door - which may not be "exploited" yet, but all someone needs is the right size rock.
Tuning your services and filesystem perms is equivalent to putting bars on the window. It doesn't make penetration impossible, but it does a lot more general good than a bigger lock.
>> Are directories only writeable by the web server user?
NB: The next point is "Do all of them even need to be? Are you sure?"
> A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.
I am not sure that's so obvious. Most web servers will serve a .ini or .yml file as plain text, if it's in the wrong spot. On the other hand, a PHP file like https://gist.github.com/3177788, even if it's in the web directory, can't leak the data without some other compromise--and the type of compromise required would generally give you access to any of the values in the .ini file, anyway.
But, see also #5: "Are your firewall rules restrictive enough?" If I can even connect, let alone authenticate, to your database from the web, you have bigger problems.
I get the impression you're thinking "secure" is a boolean, if anything it's a floating point. By that I mean "is it secure?" could be viewed as a naive question, a better question could be "how secure is it?".
>> NB: The next point is
Yes but I didn't want to write a counter point to each point. I'd taken the view from the listing of possible problems presented that the basics weren't being considered. It reads as a list of random points in a large space rather than a comprehensive listing.
To give a specific example, the article talks about writable concerns when really we want to be ensuring readable gets the same treatment.
>> even if it's in the web directory, can't leak the data without some other compromise
Or a config error (a botched upgrade disabling mod_php could do the trick, or more obscurely a content negotiation oversight), or a leaked backup (another common one - storing random backups under www root)... There's more than one way to skin a cat as they say.
>> If I can even connect
You're often better to view security as something you provide in layers. I wouldn't expect to be able to hit port 3306 from here, but if you're not expecting me to ever be inside your network, then priviledge escalation is going to be fairly quick for me once i surprise you by getting in.
We keep making more junior devs. It's important to drown out the w3schools and bad practices with good practices, so when they look up how to do it, they learn the right way.
Like I said elsewhere, that's a major cost/benefit calculation in terms of both real cost and user experience/conversion rate cost. If it makes sense for your app, do it, but it's not part of the basics, at least not yet.
