5 ms·

TL;DR: Amateurish PHP developers at Tumblr fuck up; HN developers who don't know PHP that well make wildly incorrect assumptions about PHP. People, I know it's

TL;DR: Amateurish PHP developers at Tumblr fuck up; HN developers who don't know PHP that well make wildly incorrect assumptions about PHP. People, I know it's en vogue to bash PHP (just wait, in a few years it'll be Ruby and Python - remember, PHP was once hyped, too, and now it's going in the other direction) - but if you criticize PHP, could you at least try to sound like you've actually developed in PHP for more than a week? Because most of the negative comments here about PHP have absolutely nothing to do with PHP as such - the Tumblr error in question has to do with incompetent programmers. If you read The Daily WTF you'll know that incompetent programmers can screw up no matter what language they're using.

nbpoole 16y ago
Amateurish? Incompetent? It seems a bit extreme to make those generalizations because someone made a typo in a PHP file that managed to hit production.
- stowaway 16y ago
  Maybe I went a little overboard with those words. However, it's not so much the typo; it's the fact that the typo caused passwords to be visible.
  - nbpoole 16y ago
    Again though, PHP apps storing configuration info in PHP is a fairly common practice. If that's the way you store that information, any typo that takes your configuration file out of "PHP mode" is going to leak data. Before today, I'm sure a lot of PHP coders didn't consider that when dealing with configuration files for applications: they chose to design that way because it's simple to deal with.
    - stowaway 16y ago
      Sure, but if they'd made just a tiny effort to test their code before releasing it they'd have caught that bug instantly. We're not talking about time-consuming tests here - we talking about loading the page in the browser once. If the PHP code is showing, you're doing it wrong.
      - nbpoole 16y ago
        Oh, totally. This should have been caught very quickly.
    - jasonlotito 16y ago
      > Again though, PHP apps storing configuration info in PHP is a fairly common practice. This isn't a problem with PHP. It's a problem with ANY app storing configuration options inside the actual language. It would be like storing vhost information in C and forcing you to recompile all of apache to get a new site up. Yes, config options are easy to add to interpreted languages. I see it happen all the time, and not just in PHP. Perl, Python, Ruby. The problem is that to change the config options, you are essentially changing what amounts to the application, and if you break your config, you break your application. The standard way of storing config options in PHP is with .ini files. At least, in my circle. Sure for quick scripts, we throw it in the actual code, but whenever we have to manage more than a few config options, it get's moved out. I realize I'm expanding on what you said a bit. =) I just want to make it clear that this isn't a PHP problem. It's a basic programming problem.
      - nbpoole 16y ago
        A very good point
      - ashearer 16y ago
        The key isn't so much that the configuration language is the source code language, but that both are a template language. As far as the parser is concerned all three are written interchangeably in an HTML superset that's sent down the wire raw by default, no matter where they're located or what called them. PHP gains its low barrier to entry partly from the fact that HTML becomes valid PHP just by changing its extension, but that useful equivalence also cuts the other way. Many other frameworks use the source code language for configuration without risking this particular error, because they keep templates separate. (In Django, for example, templates use a different language and are read out of template-specific directories.) It's not even a problem unique to configuration files. A disclosure of source code would have occurred by replacing the first character of a PHP source file. The fact a configuration file was involved makes the effect both more severe and less likely to be caught ahead of time. More severe, because it discloses passwords, rather than just proprietary code. Less likely to be caught, because standard testing methods tend to rely on a staging or test config instead of the production one. There are other posts disagreeing over various single villains, but a wider view is that Tumblr was bitten by a combination of a single-character typo, an otherwise useful PHP language design choice, the common and otherwise harmless practice of configuring via a programming language, and the blind spot typical test suites have for production-specific issues.
- jasonlotito 16y ago
  They made a typo. Then they didn't test on their local machine. Then they didn't test on a dev server. Then they didn't test on a staging server. Then they didn't test on a live server. At no point did they do any form of testing. Judging by the mistake, I wouldn't be surprised if they edited the file live on the server.
  - nbpoole 16y ago
    Yes, but of course this is all speculation: we don't know how this change managed to make its way to production. The fact that it happened is unfortunate, but that doesn't mean the entire engineering staff is incompetent.
    - jasonlotito 16y ago
      Of course. =) But it's fun to speculate while I'm busy doing chores around the house. As for being incompetent, I didn't mean to imply that. Rather, my focus was on the fact that the mistake wasn't just a typo. There were a LOT of mistakes that were made.
  - datasink 16y ago
    A production config file is typically an exception to the rule. If you have a development team, you will probably not want each one of them to know what your production passwords are. If you have sysadmins, they will probably want none of the devs to know. For what may be a thoroughly tested and properly deployed release, what happens when a sysadmin needs to update a password for a database? In many cases, without custom tools or a formal process, they'll just pop the config file open with vi and rsync the change out to their web cluster. I'd bet this is what happened in Tumblr's case. A sysadmin did it. Probably to avoid doing a full production redeployment for a simple config update. They will put resources into formalizing this now that they've been bitten.
    - jasonlotito 16y ago
      In my opinion, of course, sys admins shouldn't be touching configurations that affect production code. You can have config files kept from the development team, but only allow access to the actual config file to a few select individuals if you need to. Sensitive data can be kept separated. > For what may be a thoroughly tested and properly deployed release, what happens when a sysadmin needs to update a password for a database? They coordinate the efforts with someone on the development team to deploy this. A sysadmin touching source code is as bad as a developer making changes to the networking side, especially if neither are talking back and forth. This is how we work. Any changes made by networking are first vetted on by me, for example, for the systems I'm responsible for. I work with them to ensure that deployment is done at the proper time, and we handle any possible problems on our end. The networking team doesn't touch anything we work on, and vice-versa. Communication becomes key.
mustpax 16y ago
Any programming language's flaws can be made up for by sufficient skill and discipline on the part of the developers. That does not make those flaws any less real.

nbpoole 16y ago

Amateurish? Incompetent? It seems a bit extreme to make those generalizations because someone made a typo in a PHP file that managed to hit production.

stowaway 16y ago
Maybe I went a little overboard with those words. However, it's not so much the typo; it's the fact that the typo caused passwords to be visible.
- nbpoole 16y ago
  Again though, PHP apps storing configuration info in PHP is a fairly common practice. If that's the way you store that information, any typo that takes your configuration file out of "PHP mode" is going to leak data. Before today, I'm sure a lot of PHP coders didn't consider that when dealing with configuration files for applications: they chose to design that way because it's simple to deal with.
  - stowaway 16y ago
    Sure, but if they'd made just a tiny effort to test their code before releasing it they'd have caught that bug instantly. We're not talking about time-consuming tests here - we talking about loading the page in the browser once. If the PHP code is showing, you're doing it wrong.
    - nbpoole 16y ago
      Oh, totally. This should have been caught very quickly.
  - jasonlotito 16y ago
    > Again though, PHP apps storing configuration info in PHP is a fairly common practice. This isn't a problem with PHP. It's a problem with ANY app storing configuration options inside the actual language. It would be like storing vhost information in C and forcing you to recompile all of apache to get a new site up. Yes, config options are easy to add to interpreted languages. I see it happen all the time, and not just in PHP. Perl, Python, Ruby. The problem is that to change the config options, you are essentially changing what amounts to the application, and if you break your config, you break your application. The standard way of storing config options in PHP is with .ini files. At least, in my circle. Sure for quick scripts, we throw it in the actual code, but whenever we have to manage more than a few config options, it get's moved out. I realize I'm expanding on what you said a bit. =) I just want to make it clear that this isn't a PHP problem. It's a basic programming problem.
    - nbpoole 16y ago
      A very good point
    - ashearer 16y ago
      The key isn't so much that the configuration language is the source code language, but that both are a template language. As far as the parser is concerned all three are written interchangeably in an HTML superset that's sent down the wire raw by default, no matter where they're located or what called them. PHP gains its low barrier to entry partly from the fact that HTML becomes valid PHP just by changing its extension, but that useful equivalence also cuts the other way. Many other frameworks use the source code language for configuration without risking this particular error, because they keep templates separate. (In Django, for example, templates use a different language and are read out of template-specific directories.) It's not even a problem unique to configuration files. A disclosure of source code would have occurred by replacing the first character of a PHP source file. The fact a configuration file was involved makes the effect both more severe and less likely to be caught ahead of time. More severe, because it discloses passwords, rather than just proprietary code. Less likely to be caught, because standard testing methods tend to rely on a staging or test config instead of the production one. There are other posts disagreeing over various single villains, but a wider view is that Tumblr was bitten by a combination of a single-character typo, an otherwise useful PHP language design choice, the common and otherwise harmless practice of configuring via a programming language, and the blind spot typical test suites have for production-specific issues.
jasonlotito 16y ago
They made a typo. Then they didn't test on their local machine. Then they didn't test on a dev server. Then they didn't test on a staging server. Then they didn't test on a live server. At no point did they do any form of testing. Judging by the mistake, I wouldn't be surprised if they edited the file live on the server.
- nbpoole 16y ago
  Yes, but of course this is all speculation: we don't know how this change managed to make its way to production. The fact that it happened is unfortunate, but that doesn't mean the entire engineering staff is incompetent.
  - jasonlotito 16y ago
    Of course. =) But it's fun to speculate while I'm busy doing chores around the house. As for being incompetent, I didn't mean to imply that. Rather, my focus was on the fact that the mistake wasn't just a typo. There were a LOT of mistakes that were made.
- datasink 16y ago
  A production config file is typically an exception to the rule. If you have a development team, you will probably not want each one of them to know what your production passwords are. If you have sysadmins, they will probably want none of the devs to know. For what may be a thoroughly tested and properly deployed release, what happens when a sysadmin needs to update a password for a database? In many cases, without custom tools or a formal process, they'll just pop the config file open with vi and rsync the change out to their web cluster. I'd bet this is what happened in Tumblr's case. A sysadmin did it. Probably to avoid doing a full production redeployment for a simple config update. They will put resources into formalizing this now that they've been bitten.
  - jasonlotito 16y ago
    In my opinion, of course, sys admins shouldn't be touching configurations that affect production code. You can have config files kept from the development team, but only allow access to the actual config file to a few select individuals if you need to. Sensitive data can be kept separated. > For what may be a thoroughly tested and properly deployed release, what happens when a sysadmin needs to update a password for a database? They coordinate the efforts with someone on the development team to deploy this. A sysadmin touching source code is as bad as a developer making changes to the networking side, especially if neither are talking back and forth. This is how we work. Any changes made by networking are first vetted on by me, for example, for the systems I'm responsible for. I work with them to ensure that deployment is done at the proper time, and we handle any possible problems on our end. The networking team doesn't touch anything we work on, and vice-versa. Communication becomes key.

mustpax 16y ago

Any programming language's flaws can be made up for by sufficient skill and discipline on the part of the developers. That does not make those flaws any less real.