PHP repository moved to GitHub after malicious code inserted under creator Rasmus Lerdorf's name The main code repository for PHP, which powers nearly 80 per cent of the internet, was breached to add malicious code and is now being moved to GitHub as a precaution. "Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this …
"Write access to PHP repositories will now require membership of the PHP organisation as well as enabling two-factor authentication for GitHub."
Considering the extent to which the web has relied on PHP for so long, it seems a little surprising that only now is secure access being implemented,
Because, as the article points out, that requires time and money, something small projects like PHP don't have.
This is not the first malware injection in a Linux repository and it won't be the last. Ultimately, Google's solution of creating their own canonical version with no direct outside commits allowed may be the future. Although having it maintained by Google would be, shall we say, suboptimal.
a) silicon valley & the tech industry at large wasn't making $beellions of cash off the back of them; or
b) silicon valley & the tech industry at large contributed some chump change actual engineer time to their maintenance
When our (dev-)infrastructure is concentrated at one or few sites, such as github, then we make ourselves just as or even more vulnerable as when using our own infrastructure. These companies only provide "free" as long as they profit from it in some way. When the wind changes or new management comes along, then you might be in an even worse situation than before. A breach also has more impact at a centralized place.
Building infrastructure costs money and requires a lot of expertise. Yes, it is easy to outsource this. It may even be cheap at first. The costs will come eventually and probably be higher than expected. That we have seen in the history of IT administration already. Here the short-term vs. long-term must be considered. But this is very difficult for most, apparently. And then, proper procedure is always a thing to have in place.
Maybe these large public projects should charge for the commits people want to make into the code-base. Most development is already steered by commercial entities. Why not have them pay their part?
> Most development is already steered by commercial entities. Why not have them pay their part?
I think you are confusing how PHP is developed.
It's not a large project, it's perilously small, with no funding at all except for some donated servers and maybe a couple of people paid to maintain it as part of their day job.
Commercial entities have little to no say over PHP's development path, it's all done via RFC vote among current / former contributors, of which 50 to 60 usually vote, each person having a single vote.
"I think you are confusing how PHP is developed."
No-one who remembers the classic code in the source for PHP that came down to..
int size;
size = EXPR;
if (size > INT_MAX || size <= 0) {
return NULL;
}
.. could be confused as to how PHP is developed.
PHP is the equivalent of running Flash on the server.
Charge for commits?
Well that's killed Open Source.
What you would end up with is high profit companies being the only driving force. Small scale, but essential projects would become unsupported and in themselves become bigger security holes than any thing like GitHub would ever be.
So no, it's a bad idea.
Open Source is a wonderful learning environment, but it's poor when all you do is download some code and start using it without even considering that it may have been hacked. When the Internet first appeared it was normal to trust Open Source code but these days you would have to be crazy to just download it and use it without even looking at it.
Who's hacking code these days? It's not just criminals, it's national governments agencies, and corporations tracking our actions on websites too ... would it be easier to ask, "Who's not hacking code these days?"
"The malicious code is a backdoor into servers running the modified version"
Sooo... SNAFU, to use the military term?
(Anon, cause I've used PGP to write some Internet-facing but supposedly internal only utility pages that had more holes that a block of fine Swiss cheese... I'm not proud, I was young and I needed the money)
"The main code repository for PHP, which powers nearly 80 per cent of the internet, was breached to add malicious code..."
then
"The PHP project is notoriously bad with infrastructure, it just doesn't have the funds to dedicate someone to it at the level necessary," said Mark Randall, a software engineer, on StackOverflow...
That's a little concerning then.
There's a lot of hated towards PHP, and I've have joined you if we were talking about early versions and some of the horrors and awful, unmaintainable 'code' munged with HTML that people used to produce.
But the language has transformed an modernised a lot and I feel it deserves a new look.
It's not a perfect language by any means but modern OO PHP is pretty decent.
Ok, so Wordpress is pretty evil but Drupal is much cleaner and I believe that it underpins most of the UK Gov websites (not that they're much cop, but I doubt that's Drupal's fault), and then big PHP Frameworks like Symphony and Laravel have become immensely popular. They have a wide range of features, excellent testability, tidy structure, a mature toolset, are generally very performant, and they typically do
best practice security straight out of the box.
Personally I'm far more worried about the idea of people using JavaScript to write server side code.
For me, an especially important value of PHP is that it's ubiquitous - pretty much any Linux distro has it available as a native package along with your preferred choice of web server. Likewise, there's a tonne of hosting providers who support it natively. It might not be anywhere near the 'best' language but you can be certain to be able to run it on almost any platform.
I do wish that 'proper' debugging with breakpoints etc were easier however. Xdebug is really fiddly and a massive pain to get working.
"79.1 per cent of all the websites whose server-side programming language we know,"
This statement means nothing, most competently-written web applications are hidden behind reverse proxies these days. All of mine would just tell you they were "nginx". PHP, runs as a module on a web server, so it's easy to detect. But if you're using nodejs, .NET Core, Rails, etc. Those guys will have no idea.
"Those guys will have no idea."
I'd beg to differ on this one. Your reverse-proxied sites might not directly show their source language but all of the languages you've named have their own traits and little idiosyncrasies; plus I'm most cases you'd be using some kind of framework based on the language which would almost certainly give away a load more clues.
I'm pretty sure that it would be entirely possible to build up a list of such details and deduce pretty reliably what language is being used and in some cases also a good stab at what version.
HTTP is a _really_ chatty protocol and the more chatter there is, the greater the odds of being able to create reliable fingerprints.
I was once involved in a large open source project with similar problems. The infrastructure was given minimal attention.
1. Nobody had a deep interesting in maintaining infrastructure: their interest was in the project code. When you volunteer your limited time to an open source project you want to work on the fun, interesting stuff.
2. Those stuck maintaining the infrastructure are not infrastructure professionals (but nobody was inept either).
3. There wasn't enough money to pay someone. Although the project is responsible for the success of some big companies it does not mean the project got much in return (neither monetarily, nor code contributions as the upstream big companies most often kept their code changes to themselves).
4. "Free" services such as GitHub were largely eschewed due to a desire to be independent and other valid reasons.
Luckily there were no security issues that I was aware of during my time with the project. If any malicious commits were to be applied to the repository it would certainly be noticed within hours (minutes?) due to the number of eyes on the code.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
