Live data from Hacker News

Upcoming Hardening in PHP

dustri.org

121–130 of 130 posts

Re: Upcoming Hardening in PHP

#121
post #38

Earlier quoted context omitted.

Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version. The last part makes the fact their could be massive security holes like RCE in…

> 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…

> 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.

The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines.

And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 part-time. The rest were volunteers doing it as a hobby. That full-time developer who was paid by Jetbrains decided he wanted to work on another project. This resulted in the next release being pretty much nothing. At which point, everyone realised this language went from funded to not funded and they created the PHP foundation.

Re: Upcoming Hardening in PHP

#122
post #38

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/

I think the fact Facebook decided to just fork that language instead of improving it shows how bad the core development was. The internals newsletter was just brutal. I remember reading a thread from a Facebook dev asking who quietly just reverted his commit. No discussion, no nothing, the code was just reverted if someone didn't like it.

I really think that was a major misstep by the project.

Re: Upcoming Hardening in PHP

#123

Earlier quoted context omitted.

Doesn’t Facebook still run most of their backend on Hack[0] (compiled PHP subset)? [0] https://hacklang.org/

I think the fact Facebook decided to just fork that language instead of improving it shows how bad the core development was. The internals newsletter was just brutal. I remember reading a thread from a Facebook dev asking who quietly just reverted his commit. No discussion, no nothing, the code was just reverted if someone didn't like it. I really think that was a major misstep by the project.

> I really think that was a major misstep by the project.

Oh, yeah.

As someone who has written and maintained a lot of "infrastructure-level" stuff, I have come to learn that releasing a project that serves users, or is infrastructure for other projects, is like having children.

Making them is fun. Releasing them, is a pain, but, once they are out there, it is my Responsibility to support them, and accept that they have their own agency.

I can't just go in and pretend that I'm Lord Farquaad, and treat the project as if it's my private fiefdom. It's now a public resource, and my decisions and actions affect a lot of others. I also tend to write software that supports folks with a rather ... pithy ... demeanor, so screwups can result in not-pleasant feedback.

That's a big reason why I don't mind that most of my public repos aren't popular.

Re: Upcoming Hardening in PHP

#124
post #29

Earlier quoted context omitted.

php 7 has been released 9 years ago.

Yeah, and I just finished porting an enormous amount of production code from PHP 5 to 7.x before fully moving it to 8. There are so many breaking changes in each major version, when you have a lot of live projects and clients don't have the budget to pay you to upgrade them, they can lay stagnant for years until way past EOL. It would have been nice to know, for instance, that future versions of PHP would throw warni…

Your $previouslyUndefined thing as something that's changed, as far as I know, isn't true? Unless I've missed some very recent change.

If $a is true, that snippet will just execute with no errors. If $a is false you'll get a warning trying to check $previouslyUndefined in the second if. That behavior's been the same for a very long time. The blocks don't matter for scope but the fact that you never executed the line that would have defined the variable does.

Similarly, warnings on accessing array keys that don't exist, that's been a thing forever too. Pretty sure both go back with the same behavior to PHP 4, and probably earlier.

Re: Upcoming Hardening in PHP

#125
post #29

Earlier quoted context omitted.

php 7 has been released 9 years ago.

Yeah, and I just finished porting an enormous amount of production code from PHP 5 to 7.x before fully moving it to 8. There are so many breaking changes in each major version, when you have a lot of live projects and clients don't have the budget to pay you to upgrade them, they can lay stagnant for years until way past EOL. It would have been nice to know, for instance, that future versions of PHP would throw warni…

>Why? Who cares?

I do, if I typoed previouslyUndefined the first time. I get it adds boilerplate, but it also catches stupid bugs

Re: Upcoming Hardening in PHP

#126
### Структура проекта

``` project/ ├── data/ │ └── surveys.json ├── app.js └── package.json ```

### Шаг 1: Инициализация проекта

1. Создаем папку проекта и переходим в неё:

   ```bash
   mkdir project
   cd project
   ```
2. Инициализируем npm:

   ```bash
   npm init -y
   ```
3. Устанавливаем Express.js:

   ```bash
   npm install express
   ```
### Шаг 2: Создаем файл `surveys.json` для хранения опросов

Создаем папку `data` и файл `surveys.json` в ней с начальным содержимым:

```json [] ```

Это будет массив объектов, где каждый объект — отдельный опрос.

### Шаг 3: Создаем файл `app.js` для серверной логики

Вот код для `app.js`:

```javascript const express = require('express'); const fs = require('fs'); const app = express();

app.use(express.json());

const surveysFilePath = './data/surveys.json';

// Функция для чтения данных из файла const readSurveys = () => { const data = fs.readFileSync(surveysFilePath, 'utf-8'); return JSON.parse(data); };

// Функция для записи данных в файл const writeSurveys = (surveys) => { fs.writeFileSync(surveysFilePath, JSON.stringify(surveys, null, 2)); };

// Создание нового опроса app.post('/surveys', (req, res) => { const surveys = readSurveys(); const newSurvey = { id: Date.now(), ...req.body, editable: true }; surveys.push(newSurvey); writeSurveys(surveys); res.status(201).json(newSurvey); });

// Получение всех опросов app.get('/surveys', (req, res) => { const surveys = readSurveys(); res.json(surveys); });

// Редактирование опроса (если он редактируемый) app.put('/surveys/:id', (req, res) => { const surveys = readSurveys(); const surveyId = parseInt(req.params.id); const surveyIndex = surveys.findIndex(survey => survey.id === surveyId);

  if (surveyIndex === -1) {
    return res.status(404).json({ error: 'Survey not found' });
  }

  if (!surveys[surveyIndex].editable) {
    return res.status(403).json({ error: 'Survey cannot be edited' });
  }

  surveys[surveyIndex] = { ...surveys[surveyIndex], ...req.body, editable: false };
  writeSurveys(surveys);
  res.json(surveys[surveyIndex]);
});

// Удаление опроса app.delete('/surveys/:id', (req, res) => { const surveys = readSurveys(); const surveyId = parseInt(req.params.id); const newSurveys = surveys.filter(survey => survey.id !== surveyId);

  if (newSurveys.length === surveys.length) {
    return res.status(404).json({ error: 'Survey not found' });
  }

  writeSurveys(newSurveys);
  res.status(204).send();
});

// Запуск сервера const PORT = 3000; app.listen(PORT, () => { console.log(`Server is running on http://localhost:${PORT}`); }); ```

### Пояснение к коду:

1. *Маршруты*: - `POST /surveys` – создание нового опроса с полем `editable: true`. - `GET /surveys` – получение всех опросов. - `PUT /surveys/:id` – редактирование опроса по ID, если `editable: true`, после чего `editable` становится `false`. - `DELETE /surveys/:id` – удаление опроса по ID.

2. *Функции*: - `readSurveys` – читает данные из JSON-файла. - `writeSurveys` – записывает данные в JSON-файл.

### Шаг 4: Запуск проекта

Запустите сервер командой:

```bash node app.js ```

Теперь API будет доступен по адресу `http://localhost:3000`.

Re: Upcoming Hardening in PHP

#127
post #62

Earlier quoted context omitted.

At a large PHP shop, a successful exploit can be the end of the company.

almost everyone have all the things required for those exploits disabled. why would i accept performance penalty if i don't allow open(' https://google.com ') to begin with? the correct action would be to remove all the stupid features everyone serious disable to begin with.

It seems hard to "disable" the issues mentioned at https://dustri.org/b/upcoming-hardening-in-php.html

Re: Upcoming Hardening in PHP

#128
post #38

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…

> 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. The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines. And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 p…

I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language.

I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.

Re: Upcoming Hardening in PHP

#129
post #128

Earlier quoted context omitted.

> 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. The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines. And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 p…

I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language. I'm also not seeing 200 on there, though you said "200 lines" ar…

> I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language.

They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar.

And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change.

> I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.

It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes.

I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain.

The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.

Re: Upcoming Hardening in PHP

#130
post #101

Earlier quoted context omitted.

Selling hacks is ethical

Why? And: Always?

Paying for bounties is paying for exploits. That is to say, choosing not to pay for exploits is tantamount to selling your customers off for a price, the price of the bounty.
Post reply on HN