Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP: The Right Way

phptherightway.com

Post reply on HN
Print view View original

221–230 of 233 posts

Re: PHP: The Right Way

#221

Post by brohee »

Udo wrote: post #57
Kudos wrote: post #52

Earlier quoted context omitted.

No it isn't, there's GPG signing and things going on there.

No it isn't, there's GPG signing and things going on there. That's really just Cargo Cult security, isn't it? Signed packages can just as easily be malicious. In fact a repository server could be a much worthier target for the injection of bad code than a single, relatively obscure web project.

Signed packages can be just as malicious, but the security of the mechanism relies on the signer not wanting to do jail time, thus protecting his secrets and not signing stuff he doesn't trust.

Re: PHP: The Right Way

#222

Post by brohee »

mcantor wrote: post #157
dsl wrote: post #137

Earlier quoted context omitted.

You really can't tell the difference between blindly executing input from an insecure HTTP connection, and installing packages with a tool that verifies cryptographic signatures against known good keys shipped with your distro? Mr. Cantor, I have added to the list of people to never hire I keep in my notebook.

So? Who says the verified package isn't malicious? My point isn't about cryptography, it's about complexity. Unless you personally read through every line of code, how do you really know that there isn't something in there waiting to screw you over?

You don't know. What you know however is who to sue if the package ends up being malicious, thanks to the signature.

Re: PHP: The Right Way

#223

Post by mikeash »

smsm42 wrote: post #217
mikeash wrote: post #185

Earlier quoted context omitted.

That bug is not a big deal by itself, but the circumstances surrounding it are a symptom of severe problems with how PHP is developed.

I don't see any "severe problems with how PHP is developed" that have any relation to this obscure issue, only importance of which is in its use for bashing PHP.

The ones I see:

1. Ad hoc language design process (if you can call it that at all) resulted in a serious lack of forethought in the language's case sensitivity rules. Somehow they ended up with about half of the language being case sensitive and half being case insensitive. Somehow they ended up not considering the implications of "case insensitive" with regards to internationalization, and thus ended up with utterly bizarre rules where code works or doesn't work depending on the locale it's run in.

2. Extreme emphasis on backwards compatibility means an unwillingness to fix the bug by e.g. making the language fully case sensitive, or regularizing the rules for case-insensitive comparisons among language identifiers to be locale-independent. This could be phased in over a long period of time with progressive deprecation to ensure that anyone relying on the old behavior has years of notice to fix it.

3. Somehow, the broken case insensitivity of these identifiers also breaks case identical lookups for certain names. Despite the bug existing and being discussed for ten years, this still doesn't work. No matter how bizarre your case-insensitive comparison rules are, there is absolutely no reason whatsoever that looking up a class using the exact same byte-for-byte name should fail. That this hasn't been fixed means that either the PHP team doesn't care, has no idea how to fix this, or the code base is too broken and crufty to make a fix practical. None of these alternatives says anything good.

The issue itself is not that important (unless you're Turkish, or running on Turkish servers, or somehow end up running in a Turkish locale), but the fact that it exists and has not been fixed in a decade means something is seriously wrong.

Re: PHP: The Right Way

#224

Post by wilmoore »

aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

If you don't like that command, do this instead:

    > curl -s http://getcomposer.org/composer.phar -o $HOME/local/bin/composer ; chmod +x $HOME/local/bin/composer
Assuming that $HOME/local/bin is in your $PATH, the current user will have a "composer" command available.

Re: PHP: The Right Way

#225

Post by wilmoore »

smsm42 wrote: post #128
kingkilr wrote: post #18

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

What's wrong with filtering input? If you expect a number, what's wrong with telling the user "strawberry pie" is not a valid value?

What everyone is missing with the filtering argument is:

(1) normalization (things like trim, etc. so you don't do stupid things like invalidate an email address just because it was input with trailing spaces). The result is passed to a validator.

(2) validation (if a number is expected, it's only valid if given a sequence of digits within the correct range). Valid values are passed on to the next phase (likely persisted).

Sanitization is generally not needed and in most cases likely to cause data corruption. I'm sure there are use cases for it but it should be the exception, not the rule.

Re: PHP: The Right Way

#226

Post by wilmoore »

phillmv wrote: post #102
billpatrianakos wrote: post #90

Earlier quoted context omitted.

We get it, man. PHP sucks, you're cool/smarter/better because you use something else, and you need to remind us all about it by jumping in every time the letters P-H-P are seen in sequence to let us all know how it sucks by retreading the same old lines used by the last fifty guys who said the same thing but to your credit you really tried to be clever about it. A good portion of why people like to mock PHP is due to…

Well… Javascript does suck. No one in their right mind defends the language .

It is actually a very strong language with a few very well known warts (like every other language on the planet has). The problem is that people try to use it as if it were Ruby, PHP, Python, Java. One can do that, but just know that it is an exercise in futility. It will cause frustration and one will come to the conclusion that JavaScript sucks when in fact, it is just that most people don't really take the time to _understand_ JavaScript.

JavaScript could stand to be a bit less verbose (look into CoffeeScript for some relief if you value your sanity and time) in some areas and type coercion should just go away; but if you use strict mode and strict equality, a huge amount of pain is alleviated.

If one take the time to learn about constructor functions, the prototype chain, and own properties; they are 70% there. Most people can get by on just that.

Re: PHP: The Right Way

#227

Post by unconed »

jasonlotito wrote: post #69
unconed wrote: post #51

Earlier quoted context omitted.

This the wrong way to look at it, and yes, the PHP world always does this wrong because they're too focused on HTML. SQL injection occurs when you're not escaping data while producing output , namely, an SQL query sent to the DB. XSS attacks occur when you're not escaping data while producing HTML, but you don't need angle brackets to do it. allows for XSS injection with just a quote character. Header injection attac…

> the PHP world always does this wrong because they're too focused on HTML. No. The PHP world recommends, time and time again, using PDO and binding variables to queries. I've yet to meet an individual who does it the other way, other than people who are relying on extremely outdated tutorials (7+ years ago). Hell, even this document does. This document, unfortunately, uses the word filter in the wrong way, but the i…

Which is fine for SQL injection, but completely ignores every other context, of which there are many, and which don't have PDO-like APIs. That's what I meant by PHP getting it wrong. The entire filter pipeline is built to assume you're outputting only to HTML, and it's useless for making data safe for other contexts without completely destroying it.

Re: PHP: The Right Way

#228

Post by aichi »

Why the hell is required space indentation instead of tabs? Don't you know how to setup your editor? Don't you know that there are coders with special needs and they would like to setup another indentation, because they are using e.g. font size 20px to see your code?

Re: PHP: The Right Way

#229

Post by smsm42 »

mikeash wrote: post #223
smsm42 wrote: post #217

Earlier quoted context omitted.

I don't see any "severe problems with how PHP is developed" that have any relation to this obscure issue, only importance of which is in its use for bashing PHP.

The ones I see: 1. Ad hoc language design process (if you can call it that at all) resulted in a serious lack of forethought in the language's case sensitivity rules. Somehow they ended up with about half of the language being case sensitive and half being case insensitive. Somehow they ended up not considering the implications of "case insensitive" with regards to internationalization, and thus ended up with utterly…

1. As opposed to what? Government-appointed committee with 20 volumes of bylaws? Open source design processes are ad-hoc in 99% of the cases, and from what I saw in business so are many of the successful ones in business too.

>> Somehow they ended up with about half of the language being case sensitive and half being case insensitive.

Why you think it's because of the "lack of forethought"? Case-insensitive methods/classes were decided to be so for a reason (since it made easier to write bigger projects in PHP). You may not like this decision, but it doesn't mean everything you disagree with is because nobody thought about it.

>> Somehow they ended up not considering the implications of "case insensitive" with regards to internationalization, and thus ended up with utterly bizarre rules where code works or doesn't work depending on the locale it's run in.

Again, the only reason why that bizzare situation with Turkish locale exists is because it wasn't noticed. There's no deep and mysterious reason rooting in flawed PHP design why it can't be fixed - as far as I can see, the fix is not hard either, it just that nobody got to fixing it.

2. Changing language implementation with potential of breaking of 99% of existing code is not a "bugfix". If you don't understand this, maybe it's too early for you to lecture people on how to design languages. It can be done, but there's no reason to - it would lead to massive breakage with no upside in any functionality.

3. "The issue itself is not that important" - BINGO! You said it. If the issue is not that important, why you're wasting time dwelling on it and make it sound as if this is the most important thing ever? You wrote a long post supposedly about deep flaws in PHP design and process - but the only thing you actually wrote about is an obscure bug that you yourself admit is not important! Maybe it's time to discuss something that is important then?

Re: PHP: The Right Way

#230

Post by erikb »

mikeash wrote: post #209
erikb wrote: post #201

Earlier quoted context omitted.

lol. downvotes for wanting to share someone's idea. that one I really don't get...

Probably because your comment is extremely difficult to understand and looks a lot like spam.

What is hard to understand about it? Most link sharing happens on facebook. If you share a link in facebook, people will click on it, IF there is a picture that interests them. If there is no picture 99% of people will ignore the shared link. So for the author of this website it would make sense to add any picture at all. When someone shares the link to his website, FB will automatically find the picture. But there is none.
Post reply on HN