111–120 of 130 posts
Earlier quoted context omitted.
Selling hacks is ethical
I actually agree, in the same way that selling lock picks or guns is ethical. They are just tools. How they are used is the responsibility of the person wielding them.
Earlier quoted context omitted.
I actually agree, in the same way that selling lock picks or guns is ethical. They are just tools. How they are used is the responsibility of the person wielding them.
I can think of benign uses for lock picks and guns. What is the benign use of a secret exploit?
Earlier quoted context omitted.
I actually agree, in the same way that selling lock picks or guns is ethical. They are just tools. How they are used is the responsibility of the person wielding them.
I can think of benign uses for lock picks and guns. What is the benign use of a secret exploit?
https://www.reddit.com/r/wowservers/comments/1eebxwf/warning...
Earlier quoted context omitted.
I don’t really understand the issue. Already if you have a mismatch, the only way you’d ever know is through static analysis. It will run and maybe crash during run time. I always joke that changing a function signature is the single most risky thing you can do in php (especially if you have any dynamic dispatch). Making it even more risky isn’t the right answer, IMHO. Oh, and doing this would literally break class a…
To be specific about static analysis: Lots of tools catch this. Sure, making some checks native would be nice, but for instance PHPStan always catches this, and more. Regardless of the ‘improve the language angle’: Is somebody isn’t running PHPStan (or Psalm, Sonar, etc), then they’re missing out. PHPStan is currently so good that using it should be non-negiotable. So the question would then even be: “I’d like rule 1…
$a = &$arr[]
$a = null
$arr[] = &$a
For applications, these static analysis tools are great. For libraries, not so much.
Earlier quoted context omitted.
I actually agree, in the same way that selling lock picks or guns is ethical. They are just tools. How they are used is the responsibility of the person wielding them.
I can think of benign uses for lock picks and guns. What is the benign use of a secret exploit?
Earlier quoted context omitted.
> From historically just adding features whenever to know adding hundreds of breaking changes per minor release. Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it. PHP spent a long time running on fumes with little backing. It's now got huge financial backing from Jet…
Doesn’t Facebook still run most of their backend on Hack[0] (compiled PHP subset)? [0] https://hacklang.org/
(and all of them much improved over PHP IMO - especially XHP [equivalent to JSX, where HTML is a first-class citizen in the language syntax])
The linked CVE-2024-2961 article is a pretty fantastic read on its own: https://www.ambionics.io/blog/iconv-cve-2024-2961-p1 People are so creative, I can't help but feel some hope for our future :)
- What people are saying about the filter protocol, and anything else that interprets the files.
- Why do people insist on making all remote file protocols transparent? Fuck that, a file is a file! If you want to support some remote stuff, do that on the OS, where it's opt-in.
- And PHP keeps insisting it's not a web framework while being a web framework. So it has no access control around local file reading, while clearly designing it to be used in a way where only a few directories should be accessible.
- A buffer overflow in glibc, go figure... But yeah, C is perfect and the only issue is that the devs don't know the language well enough or there aren't enough people reviewing this niche library.
- Didn't everybody decide to ditch the pre-unicode encodings from the standard tools? I remember the announcement (that was supposed to include glibc), it made a lot of people angry. Those have been an endless source of CVEs.
> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain. Big Oof. :( :( :(
At a large PHP shop, 0.6% can be tens of millions of dollars.
sudo apt-get purge php.*
Earlier quoted context omitted.
One of the main advantages of actually allowing more arguments is forward compatibility: You can, within a library, provide an additional argument to a callback without actually introducing a BC break for all users. My favorite approach would be allowing too many args on dynamic calls (closures, and function calls with dynamic name, not method calls in general) and otherwise rejecting it.
There's no need to have this in the language just to solve the case you describe. "function current_thing(id: Int, callback: Fn(Int)) {}" and, when you decide you need more you have a myriad of options to add these. From the despised "function current_real_thing(id: Ind, success_callback: Fn(Int), error_callback: Fn(Error)) {}" to "some_namespace:current_thing(...)" via "OtherClass::current_thing(...)" to "load curre…
But I have no hard evidence at hand, only how I experienced that in PHP.