![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
There was an excellent article about the growing interest of Russia and China in open source. I am shocked by the lack of reaction in our community -- we need to face the question: what we will do when (when! not if) hackers appear with interests closely alligned with those governments? It's not impossible their dayjob will be core hacking -- ie they will have the time the ordinal core hacker doesn't. We have already shown that we are willing to give up something good (namely compatibility in one direction with other phpass using systems) for the sake of one government (the USA, in this case) in this issue. How do we continue?
Commenting on this Story is closed.
I can still feel the knot in my gut re-reading that issue almost a year later.
Plenty of core patches, contrib patches, and contrib modules start off fixing a specific issue for a specific client, that includes some of my own patches, particularly since I started working on Drupal full time. Sometimes changes benefit particular kinds of sites (single user blog on shared hosting vs. a large installation on multiple servers) more than others. Sometimes patches will penalise certain kinds of installs at the expense of others as well - although this is often realised after the fact (i.e. with the registry, which was a net loss for CPU on sites running APC).
Neither of those issues are specific to patches that are prompted by paying work, they apply to completely volunteer efforts as well - since we all have our assumptions about what sort of sites we want to run on Drupal. It's more a byproduct of many of the people working on contributed code, doing so alongside work building real websites, and in most cases it's driven by trying to generalise lessons learned from site building into the wider community.
However in every case that I can think of, they are always proposed and argued on their technical merits, not the 'business needs' of the client that originally prompted the submission of the patch. Currently that issue is the exception rather than the rule (as far as I know it's the only issue that's gone in like this, otherwise you'd see a lot more posts like http://drupal.org/node/723802#comment-2863740 from me).
It is a good question to ask whether we will see more of this in the future, although there's a slight implication in your post that the US government is any better than Russia or China, interference from any of them is unwelcome.
I am not sure whether it's welcome or not welcome but for sure that patch sacrificed something good without having any real technical merits to it. Another tricky question -- say, something like OpenID comes along with complex calculations. How we are going to judge whether it's good or has some ... backdoors?
I think some best practice adoption on the security front could be beneficial. In SE Asian countries, there is demand for and awareness about security measures in websites.
Next to coding standards for Drupal core, perhaps some best practice security modules could be moved into core or recommended on Drupal.org. I think this is a good opportunity. I have pointed out to prospect clients the security benefits of Drupal over Joomla, which has gotten bad press on occasions where certain fundamentalist groups hacked a great number of Joomla sites.
As the general webdesign demanding audience becomes more aware, security practices will add to the overall 'competative edge' of Drupal.
I don't know that we will have such a problem. If there are conflicting interests I imagine we would make the thing pluggable and let contrib work it out. I think we are capable of working this out.
password.inc is already pluggable - If you must have phppass you can easily implement it. Just like you can use bcrypt or MD2 or hell plaintext if you really want.
It's also not true that the SHA patch had no technical benefit - it fixed numerous security weaknesses resulting from cryptographic use of md5 (for example XSRF form tokens). And it made the DX just a little better for citizens of any country, not just the U.S.
The main concern in the linked article - that governments are pressuring software vendors into inserting secret backdoors - is really only possible in proprietary software and network protocols. The Drupal community has already shown it will react swiftly to hostile contributions, for example http://drupal.org/node/847952 .
There was no technical benefit from moving away from phppass in password.inc, none was offered in the issue, none has been offered since. It was a cosmetic change so that scanners won't see 'md5', which took out compatibility in the process. Not to mention that the author of phppass posted in that issue and was more or less shouted down.
While it is true that the SHA patch fixed md5 weaknesses in sessions/tokens - there is *no* demonstrable improvement in going from md5 to SHA for the purposes of password hashing, and it this change had a huge negative effect on the DX for any system that wants to migrate either to or from Drupal, or integrate with the Drupal user table. See http://drupal.org/node/1003758 for an example. While I do think there was reasonable "business" logic behind the change, and it does make life easier for US government contractors, I think a clear well argued, research based, technical defense in the documentation would have been a preferable community response.
There were a number of changes in that issue not just password and it'd be a challenge to make everything pluggable -- if you need to store a hash in the db, the length of it matters.
While it will be a challenge to make everything pluggable, I think that's also the best defence against this kind of issue, and it's one we're slowly working towards anyway.
Also between git and install profile packaging, it might be nice to let d.o hosted install profiles ship without certain core files (i.e. it might make sense for a single user blog profile not to have blog module anywhere on the file system).
While it will be a challenge to make everything pluggable, I think that's also the best defence against this kind of issue, and it's one we're slowly working towards anyway.
Also between git and install profile packaging, it might be nice to let d.o hosted install profiles ship without certain core files (i.e. it might make sense for a single user blog profile not to have blog module anywhere on the file system).