Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз языка программирования PHP 7.3"	+/–
Сообщение от opennews (?), 06-Дек-18, 22:17
После года разработки представлен (http://php.net/archive/2018.php#id2018-12-06-1) релиз языка программирования PHP 7.3 (http://php.net/). Новая ветка включает серию новых возможностей, а также несколько изменений, нарушающих совместимость. Ключевые улучшения (https://raw.githubusercontent.com/php/php-src/43329e85e682be... в PHP 7.3: -  Реализован гибкий синтаксис (https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes) многострочной вставки (строки heredoc и nowdoc (http://php.net/manual/en/language.types.string.php#language.... не требующий обязательного перевода строк после маркера окончания блока и допускающий выравнивание отступами; -  Добавлена (https://wiki.php.net/rfc/list_reference_assignment) поддержка назначения ссылок в list(): синтаксис "list($a, &$b) = $array;", эквивалентный присвоению "$a = $array[0]; $b =& $array[1];". Предложен также упрощённый синтаксис присвоения позволяющий указывать вместо "list()" квадратные скобки, например "[$a, &$b] = $array;" -  При вызове функций и методов теперь допускается (https://wiki.php.net/rfc/trailing-comma-function-calls) оставление запятых в конце списка аргументов, например, "unset($foo, $bar, $baz,)"; -  Расширение PCRE переведено (https://wiki.php.net/rfc/pcre2-migration) на ветку PCRE2; -   Выражение "instanceof" теперь допускает указание литералов в качестве первого операнда (в такой ситуации результат всегда будет FALSE); -  Добавлено новое исключение CompileError, наследуемое от ParseError и генерирующее для некоторых типов ошибок перехватываемое событие CompileError вместо фатальной ошибки; -  Значительно расширены возможности и увеличена производительность дополнения MBString, в том числе добавлены полноценные средства для манипуляций с  регистром символов (MB_CASE_LOWER, MB_CASE_UPPER, MB_CASE_TITLE, MB_CASE_FOLD и т.п.), до версии 11 обновлена поддержка спецификаций Unicode, добавлена поддержка строк, размером больше 2 Гб, в функциях mb_ereg_*()  добавлена поддержка именованного захвата элементов;      -  В заголовок страницы phpinfo(), добавлено отображение переменной PHP_VERSION; -  В расширение Date добавлен метод DateTime::createFromImmutable(); -  В расширение GD в функции imagecreatefromstring() появилась поддержка создания изображений в формате WebP; -  В расширение OpenSSL добавлена функция openssl_pkey_derive(); -  Представлена новая функция  net_get_interfaces() для получения информации о доступных сетевых интерфейсах; -  Улучшена работа сборщика мусора; -  Переработан PHP-скрипт ext_skel (http://php.net/manual/en/internals2.buildsys.skeleton.php) (генерирует шаблоны кода дополнений), который теперь можно полноценно запускать в Windows без дополнительных зависимостей ('php ext_skel.php'); -  Прекращена поддержка платформы BeOS. URL: http://php.net/archive/2018.php#id2018-12-06-1 Новость: https://www.opennet.me/opennews/art.shtml?num=49732
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

5. "Релиз языка программирования PHP 7.3"	+14 +/–
Сообщение от Аноним (5), 06-Дек-18, 22:35
> Прекращена поддержка платформы BeOS. То ли у них был человек, все эти годы поддерживающий версию для BeOS не смотря ни на что, и тогда хочется пожать ему руку, то ли они только сейчас поняли, что BeOS никто в реальности не поддерживает, а у них нигде это не отмечено. PS. В идеале они бы заменили BeOS на HaikuOS, а то воз который год всё там же https://github.com/php/php-src/pull/2697
Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз языка программирования PHP 7.3"	+21 +/–
Сообщение от Аноним (9), 06-Дек-18, 23:06
Язык весьма неплохой. В каждой функции есть своя изюминка. Например, при помощи file_exists() можно не только проверить существование файла, но и начать выполнять код, заботливо предоставленный третьей стороной. Удобная фича, рекомендую. Если в вашем языке функция проверки существования файла не способна запускать код, просьба меня не беспокоить.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Релиз языка программирования PHP 7.3"	+5 +/–
	Сообщение от Аноним (10), 06-Дек-18, 23:14
	То ли дело хипстота, помешанная на магии современных ЯП и фреймворков, не позволяющих бедолагам стрелять себе в ногу даже если захотят.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от Аноним (29), 07-Дек-18, 02:45
	Обидно оказаться с револьвером, когда у кого-то пулемёт на турели.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от Онаним (?), 07-Дек-18, 09:29
	Да ладно, в хипстерских поделках там сам рантайм обычно просто косая кирпичная кладка из говнозависимостей, подтянутых с говнореп, которые мейнтейнятся непонятно кем и непонятно как до первого залетевшего дятла. По сравнению с этим пых - эталон простоты, если композером не баловаться.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от ъ (?), 07-Дек-18, 03:20
	> Например, при помощи file_exists() можно не только проверить существование файла, но и начать выполнять код, заботливо предоставленный третьей стороной. Пример можно?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	60. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 11:02
	не будет примера, это же очевидно
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от YetAnotherAnon (?), 07-Дек-18, 11:06
	30 секунд в гугле https://blog.ripstech.com/2018/new-php-exploitation-technique/
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	63. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 11:35
	> First, an attacker must be able to plant a crafted Phar file on the targeted web server. уже смешно новоявленные секурные спецы оправдывают своё существование и пытаются рассказать, зачем нести деньги им, а не кому-то другому
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 11:45
	Вы хоть сами прочитали этот бред? Это из той же оперы как вирус для линукса для запуска которого нужно пропатчить ядро определённой версии нужным патчем.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	71. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от ъ (?), 07-Дек-18, 12:17
	> 30 секунд в гугле > include($_GET['file']) А, ну примерно такой глубины кульхацкерской мысли я и ждал.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	72. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от userd (ok), 07-Дек-18, 12:20
	http://www.opennet.me/opennews/art.shtml?num=49641
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	77. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:05
	> Уязвимость вызвана отсутствием проверки поступающих от пользователя данных это всё, что нужно знать
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 11:39
	> file_exists() 1 file_exists() - бесполезная ф-ия, так как не проверяет доступен ли файл может он существует, но него прав нет? 2 is_readable() - когда нужно подключить или вывести, is_writable() - когда нужно изменить или удалить. 3 /tmp или иное место заданное в конфиге для этого должно быть с noexec флагом, в fstab, это ясно как день! 4 Ну и, естественно, записывая файл, вы должны указать ему нужные права (0600|0640|0660) БЕЗ бита выполнения. Это я знал ещё 10 лет назад когда говносайты на Джумле писал. Как тут выполнить файл через file_exists() можно - ума не приложу!
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	70. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от fi (ok), 07-Дек-18, 12:13
	> file_exists() - бесполезная ну не скажи - если файл используется для синхронизации - тот же lock и в шеле постоянно такие проверки делаются.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от userd (ok), 07-Дек-18, 12:37
	Давайте вынесем шелл за скобки, и собственно содержательную часть проверки существования файла - тоже. Если lock делается через file_exists(), то это ошибка. Если процесс установивший файл-блокировку "погибнет" не удалив файл (вариантов море, вплоть до нажатия кнопки ресет и выключения питания) то файл остаётся. используйте flock: http://www.opennet.me/man.shtml?topic=flock&russian=0&catego... http://www.opennet.me/man.shtml?topic=flock&category=1&russi... http://php.net/manual/en/function.flock.php
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 13:32
	Лет 10 точно использую кэш для сайтов, самая первая строка любого урла на любом моем сайте file_exists(файл в кэше на основании текущих переменных урла из .htaccess) И далее уже сразу require_once(файлкэша) exit() или пошло выполнение кода, который запросит все данные страницы и затем отдаст в браузер, ну и запишет в файл кэша это всё. Любая отличная от file_exist функция при многотысячных тестах, выполняется медленнее, чтобы проверить существоваание файла кэша на диске.Включая прямое подключение файла с генерацией кода по ошибке.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:36
	мало запросов значит, ибо file_exists при инвалидации не атомарен и можно нарваться на dog pile при  генерации нового кеша
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 13:41
	Абсолютно никак такое не получить. Файл просто накроется новым параллельным кодом последнего пишущего, до момента следующей валидации. Говорю же - делал многтысячные тесты, включая параллельную нагрузку - все гуд, самое быстрое решение на текущий момент, НЕТ НИЧЕГО БЫСТРЕЕ!
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:54
	> Файл просто накроется новым параллельным кодом последнего пишущего про это я и говорю, не должно быть более одного писателя ^_^ если писателей>1 значит исполнителей>1 значит кеш не работает какое-то время
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 14:06
	Если писать кэш одной строкой, один раз для файла, то без разницы сколько конкурирующих писателей будет - у всех текст один и тот же. Первый вкатил весь кусок - читатель в этот момент еще не видит файла (нет ни fclose ни fflush). Второй вкатил, последний вкатил - флуш. Так, как все писатели работают конкурентно без flock,  то очередь системная мгновенно производит (уже закэшированный после первого писателя) fwrite куска текста в файл - мгно-вен-но. Писатели заканичиваются мгновенно, и следующий читатель получает уже существование файла кэша. На тестах я задавал овер нереальные условия, иногда, при настройках выделения памяти как на шаред хостингах (древних - по 64мб) я мог увидеть заполнение памяти очередью писателей. Но в реальности (или при настройках выделения ресурсов по потребностям сайта) за 10 лет не было НИ ОДНОЙ ошибки связанной с этим, в реальных сайтах и приложениях.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 14:22
	Я за 20 лет столько таких кешей повидал и к чему это приводит, что до сих пор удивляюсь, зачем допускать много писателей, которые исполнители. Но в общем понятно, почему мало кто видит в чём проблема. Это всё прокатывает, пока нет реально больших нагрузок, либо писатели отрабатывают так быстро, что кеш не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 14:33
	Вам ан каком языке написать - тест: 64мб памяти (которых уже никогда не увидеть на реальном даже на шаред хостинге). Одновременных сессий 100, посетителей в минуту 6000, размер страницы 800Кб, длительность теста 1 час - но проблем. Что вы видели? Где вы видели? Поделитесь с нами слепыми, плиз.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 15:26
	я никого уговаривать не собираюсь, делайте как хотите, размер памяти тут не при чём
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:16
	Есть пример с файловым кэшем для околореалтайм интерфейса. is_file + проверка контента (контент небольшой, порядка 1кб объёмом), 1000-1400 запросов в секунду, 2xE5520/8Gb рамы тянут такое только в путь. Причём это относительно вторичная задача на данном сервере. CPU load от этого счастья ~25%. Интерфейс - апач и fastcgi до php-fpm.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	117. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:20
	Выглядит сие высокоуровнево вот так         # first, try from cache         if (is_array($data = self::readCache(self::$cacheId, $items, self::$cacheTimeout))) return $data; # valid cache                  # alas, could not validate cache, do the job retrieving data         $fh = self::lockCache(self::$cacheId);                  # one more verification is needed here due to parallelism         if (is_array($data = self::readCache(self::$cacheId, $items, self::$cacheTimeout, $fh))) return $data; # cache updated by someone and is valid         ... update cache here ...         # write and unlock cache, then return         self::writeCache(self::$cacheId, $data);         self::unlockCache($fh);         return $data
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:25
	Ну и readCache с lockCache     static protected function readCache($id, $items, $timeout = 500, $wLock = null)     {         $ok = false;         if (@is_file(CT_ROOT."/cache/{$id}.info")) {             $finfo = fopen(CT_ROOT."/cache/{$id}.info", 'rb');             flock($finfo, LOCK_SH);             fseek($finfo, 0, SEEK_SET);             $data = array('info' => @unserialize(stream_get_contents($finfo)));             if (is_array($data['info']) && isset($data['info']['timestamp']) && isset($data['info']['version']) && ($data['info']['version'] === CT_VERSION)) {                 if (abs((microtime(true) - $data['info']['timestamp']) * 1000) < $timeout) {                     # cache is ok, demote write lock early if it exists                     if ($wLock !== null) self::unlockCache($wLock);                                          # read items now                     $ok = true;                     foreach ($items as $item)                         if (@is_file(CT_ROOT."/cache/{$id}.{$item}")) $data[$item] = @unserialize(file_get_contents(CT_ROOT."/cache/{$id}.{$item}"));                 }             }             flock($finfo, LOCK_UN);             fclose($finfo);         }                  return $ok ? $data : false;     }     static public function lockCache($id)     {         $fh = fopen(CT_ROOT."/cache/{$id}.lock", 'ab+');         flock($fh, LOCK_EX);         return $fh;     }     static public function writeCache($id, &$data)         $data['info'] = array('version' => CT_VERSION, 'timestamp' => microtime(true));         foreach (array_keys($data) as $key) {             switch ($key) {                 case 'valid':                 case 'changed':                 $data['info'][$key] = $data[$key];                 unset($data[$key]);                 break;             }         }         $finfo = fopen(CT_ROOT."/cache/{$id}.info", 'ab+');         flock($finfo, LOCK_EX);         fseek($finfo, 0, SEEK_SET);         ftruncate($finfo, 0);         fwrite($finfo, serialize($data['info']));         fflush($finfo);                  foreach ($data as $key => $val) {             if ($key == 'info') continue;             file_put_contents(CT_ROOT."/cache/{$id}.{$key}", serialize($val));         }                  flock($finfo, LOCK_UN);         fclose($finfo);     }          static public function unlockCache($fh)     {         flock($fh, LOCK_UN);         fclose($fh);     } Нормально работает, коллизии исключаются блокировкой. Можно адаптировать хоть к сайту, хоть к чёрту лысому. Структура кэша в примере правда слегка хитрая, под конкретное приложение.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	119. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 17:29
	кеш околореалтайм генерится? схема какая?
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:41
	Обновление кэша - три-четыре запроса поверх ZeroMQ к фоновым частям приложения + некоторая предобработка.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	122. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:43
	Ну то есть писателей в моей схеме нет, читатели сами обновляют кэш. В случае с писателями алгоритм почти не меняется. Только время валидности будет овердохера ("вечный" или около того в масштабах приложения кэш), и я ниже другому постеру откомментировал: инвалидация в писателе будет простейшая - берём всё ту же самую эксклюзивную блокировку, и банально удаляем кэш. Далее читатели всё сами обновят без нас.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	129. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 18:35
	Под писателями я имею ввиду тех читателей, которые обнаружили невалидный кеш и пытаются его писать. Собственно ещё вопрос, вот читатель видит протухший кеш и видит лок от другого процесса, он что делает? Судя по первому коду, он будет генерить $data, но кеш не обновит из-за чужого LOCK_EX
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	131. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 18:48
	Читатель видит протухший кэш и пытается взять LOCK_EX. Как только LOCK_EX взят - мы ещё раз проверяем кэш, его мог обновить другой читатель. Если это случилось - мы получили обновлённый кэш, снимаем лок, и ничего не генерим. В противном случае генерим, пишем, снимаем лок.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	132. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 19:15
	Получается, что несколько потоков могут одновременно считать новое значение, т.к. время между "Как только LOCK_EX взят - мы ещё раз проверяем кэш" ненулевое, но достаточно малое, чтобы новый кеш мог быть ещё не обновлён другим потоком.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	135. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Онаним (?), 08-Дек-18, 00:38
	Нет, не могут. Несколько потоков могут контендиться на LOCK_EX на время валидации кэша. На практике под 1200 запросов в секунду при интервале валидности кэша в 1 секунду оно чувствует себя нормально. Почему не могут? Потому что как только LOCK_EX взят - никто больше его взять не сможет до завершения обновления "писателем". Таковым LOCK_EX будет отпущен не ранее, чем новое содержимое записано. После чего каждый ждущий "читатель" возьмёт LOCK_EX, считает кэш, убедится, что содержимое обновлено, и сразу же LOCK_EX отпустит. Чтение кэша - операция достаточно быстрая, поскольку таковой полностью сидит в кэше ОС.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	136. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Онаним (?), 08-Дек-18, 01:09
	Для обхода конкуренции с ридерами и предотвращения рейсов сделана хитрость: лок-файл отдельный, и никогда не лочится как LOCK_SH, в отличие от файла кэша. Как живут писатели: Для проверки кэша мы лочим сам файл кэша (.info) как LOCK_SH, но только на время чтения-валидации. Зачем - чуть ниже. Если кэш не валиден, то мы берём LOCK_EX на локфайл (.lock). Как только мы взяли LOCK_EX для локфайла - никто больше, кроме нас, права обновлять кэш не имеет. Другие считавшие невалидный кэш и возжелавшие его обновить - встанут в очередь на пресловутый LOCK_EX для локфайла. Для чего вторая проверка. Мы может быть таким же возжелавшим в очереди. То есть кто-то до нас взял LOCK_EX на локфайл и обновляет кэш, а мы его ждём. Как только обновляющий закончит работу - мы (ну или кто-то до нас) сможем взять LOCK_EX на локфайл. Взяв LOCK_EX на локфайл, мы проверяем кэш на предмет того, а не стал ли он валидным (не было ли кого до нас с LOCK_EX на локфайл). Если кэш валиден - значит его обновили, и мы сразу же сбрасываем LOCK_EX, потому что это contention point, и нас таких стоящих в очереди на LOCK_EX только чтобы убедиться, что кэш уже обновили, может быть много. После чего возвращаем содержимое кэша вызывающей стороне, работа закончена. Если же кэш валидным не стал, значит мы были первым желающим его обновить. Не отпуская локфайла, гоняем процесс обновления - новые читатели превращаются в желающих обновить кэш и встают в очередь за LOCK_EX. Впрочем, обновлять они ничего не будут, как раз из-за второй проверки. Закончив процесс обновления, лочим сам кэш на LOCK_EX - это второй contention point, тут мы конкурируем с теми, кто валидирует кэш прямо сейчас. Пишем, отпускаем LOCK_EX на кэш, давая возможность новым читателям уже не вставать в очередь на LOCK_EX для локфайла, далее сразу же отпускаем LOCK_EX на локфайл, давая возможность уже вставшим в очередь на локфайл убедиться, что мы кэш обновили, и благополучно отвалить, не обновляясь. --- Как живут читатели: Первый - валидация кэша. Когда мы валидируем и читаем кэш - мы лочим сам файл кэша на LOCK_SH. Для чего: чтобы не считать полузаписанные данные, если активен писатель. Желающий записать кэш писатель контендится с валидирующими читателями, ему нужен LOCK_EX на файл кэша. Второй - мы не боремся ни с другими читателями (потому что LOCK_SH), ни с уже вставшими в очередь на LOCK_EX на локфайл для обновления кэша. Если первая валидация не удалась - мы сами превращаемся в таковых вставших в очередь. Если же мы попали в момент записи кэша писателем - сразу же, как только писатель закончит и отдаст LOCK_EX - мы считаем уже валидный кэш. Это уменьшает общий contention: вставшие в очередь желающие LOCK_EX на локфайл ещё будут продолжать драться между собой за этот лок, только чтобы свалидировать кэш во второй раз и отвалить с новым содержимым, однако новые читатели в очередь вставать перестанут сразу после записи кэша писателем. --- Если сомневаетесь - можете даже диаграмму порисовать :), она тривиальна.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	91. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 14:37
	И да, я же вам написал - люди делающие php не сопли жуют, а пишут код. Писатели отрабатывают мгновенно (ввиду того, что записываемый текст, отработка запросов и все события системы кэшируются, ввиду их равнозначности, и все последующие писатели просто не нагружают систему в принципе). Так что конкурентная запись просто рулит в обычном кэшировании. А то что параллельная запись такая быстрая, это не значит, что кэш не нужен - когда последний писатель исчезнет и кэш процессов системы сбросится - следующий читатель уже получит файл кэша, вместо нагрузочных запросов страницы.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	120. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (116), 07-Дек-18, 17:35
	Проще делать блокировку с обновлением при чтении, проверяя на обновление соседом - тогда не придётся обновлять кэш многочисленное число раз. Инвалидация в писателе тоже простейшая - берём всё ту же самую эксклюзивную блокировку, и удаляем кэш. Далее читатели всё сами обновят без нас.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	97. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 15:02
	> И далее уже сразу require_once(файлкэша) exit() Если уж дело идёт про скорость, то require_once() - это костыль рукожопов, который нафиг не нужен нормальным программистам, а выполняется он медленнее чем require(). > Любая отличная от file_exist функция при многотысячных тестах, выполняется медленнее, Логично, что проверка на существование и на доступность для чтения медленнее проверки только на существование. А без проверки вообще ещё быстрее будет! Если у Вас, конечно, не оффтопик, то Вы получите ошибку, если окажется что файл существует, но он не доступен для чтения.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	102. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от SenaIVV (?), 07-Дек-18, 15:23
	Нет, у меня такой ситуации не может быть, что файл есть, но не доступен для чтения - в этом и смысл и скорость конкурентной записи. На счет require_once - если нет совпадающих пространств имен, одинакова скорость. У меня нет таких пространств. Просто по привычке осталось с самых азов еще, всегда инклюдить и запрашивать исполнение через гарантию отсутствия дублей функций. В самом начале такие коды были, что без этого было никуда :)
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 15:59
	> Нет, у меня такой ситуации не может быть, что файл есть, но > не доступен для чтения - в этом и смысл и скорость > конкурентной записи. Буду знать что file_exists() кому-то всё же нужна на мой взгляд в редкой для PHP ситуации. > На счет require_once - если нет совпадающих пространств имен, одинакова скорость. > У меня нет таких пространств. Просто по привычке осталось с самых азов > еще, всегда инклюдить и запрашивать исполнение через гарантию отсутствия дублей функций. Я тоже начинал с include_once() пока не понял, что всё кроме require() нужно забыть в PHP. А также ещё тогда не знал про spl_autoload_register, кстати... define('WWW', $_SERVER['DOCUMENT_ROOT']); define('ROOT', dirname(WWW)); spl_autoload_register(function($class) {     $file = ROOT.'/models/'.$class.'.php';     if (is_readable($file))         require($file); });
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от SenaIVV (?), 07-Дек-18, 15:30
	И, кстати, на счет скорости проверки наличия - не все так очевидно. Я до теста считал, что прямое включение без проверки наличия файла и код в обработчике ошибок - быстрее (без кэширования, первый запрос такого типа отрабатывает быстрее, чем первая проверка наличия файла). Но при повторном вызове, file_exists сразу начинает выигрывать.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	133. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от hellobillyboy (?), 07-Дек-18, 20:32
	о! классное решение, выложи пожалуйста посмотреть на кодохостинг https://govnokod.ru/php спасибо!
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	85. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:51
	flock не панацея нужно делать pid-файл через fopen x+ и проверять статус процесса, если файл существует
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	92. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Sw00p akaJerom (?), 07-Дек-18, 14:42
	версионность через симлинк
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 15:07
	это уже детали реализации, можно и через mv, смотря что делается, новый tmp тоже надо лочить и писать правильно
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 15:09
	т.е. если делаешь демона, то симлинк тут никаким боком, в остальном страдать версионностью можно разными способами :)
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	124. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от fi (ok), 07-Дек-18, 18:12
	> используйте flock: Это только если вы тоже хотите его юзать, но есть часто используемая технология флагов путем создание пустых файлов.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	78. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:07
	Эксплоит работает, но ровно в одном случае: данные от юзера не фильтруются и используются напрямую.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	108. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 16:04
	> Эксплоит работает, но ровно в одном случае: данные от юзера не фильтруются > и используются напрямую. Понятно, это как новость от супер-пупер антивирусной компании найден супер-пупер троян под Linux! Но как бы невзначай, для работы трояна требуются root привилегии. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от пох (?), 07-Дек-18, 16:48
	> file_exists() - бесполезная ф-ия, так как не проверяет доступен ли файл может он существует, > но него прав нет? откуда в нормальной системе возьмется такой файл? В том месте, где появляются какие-то файлы, доступные php? (к тому же *тебе* может и не нужны на него права - может это просто статическая картинка, ее открывает веб-сервер,а не скрипт на php) > is_readable() - когда нужно подключить или вывести, полагаю, он точно так же исполняет подсунутый phar. > /tmp или иное место заданное в конфиге для этого должно быть с noexec флагом милый ребенок, ты вообще хоть что-нибудь понял в описанном эксплойте, кроме "у меня этого не может быть, я же умный и начитанный"?
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	127. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (127), 07-Дек-18, 18:28
	https://blog.ripstech.com/2018/new-php-exploitation-technique/ https://securityboulevard.com/2018/12/bypass-of-disabled-sys.../ https://blog.ripstech.com/2018/phpbb3-phar-deserialization-t.../
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

11. "Релиз языка программирования PHP 7.3"	+8 +/–
Сообщение от Аноним (11), 06-Дек-18, 23:15
> Прекращена поддержка платформы BeOS Не ожидал от них такой подлости! Прямо удар в спину!
Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз языка программирования PHP 7.3"	+/–
Сообщение от Аноним (12), 06-Дек-18, 23:28
> При вызове функций и методов теперь допускается оставление запятых в конце списка аргументов, например, "unset($foo, $bar, $baz,)"; Но зачем?
Ответить | Правка | Наверх | Cообщить модератору

	13. "Релиз языка программирования PHP 7.3"	+9 +/–
	Сообщение от Пользователь Debian (?), 06-Дек-18, 23:32
	чтобы(   можно,   было,   вот,   так, )
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 23:32
	>> При вызове функций и методов теперь допускается оставление запятых в конце списка аргументов, например, "unset($foo, $bar, $baz,)"; > Но зачем? Возможно, через ЭТО уже кто-то как-то зловредничал.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	15. "Релиз языка программирования PHP 7.3"	+10 +/–
	Сообщение от Аноним (15), 06-Дек-18, 23:38
	unset(     $very_long_name,     $very_very_long_name,     $very_very_very_long_name, //  $very_very_very_very_long_name ); для того
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	17. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Антон (??), 06-Дек-18, 23:53
	слизали с js, хотя может в js тоже взяли откуда то. На самом деле довольно удобно, можно комментить ненужное и добавление параметра влечет изменение одной строки в гит, а не двух.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	18. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Q2W (?), 07-Дек-18, 00:11
	В perl'е это уже кучу лет можно. Просто супер удобно!
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Аноним (25), 07-Дек-18, 01:20
	Write-only language.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (33), 07-Дек-18, 04:48
	Если у Вас проблемы с чтением такого(https://github.com/bugzilla/bugzilla/blob/5.0/editusers.cgi) кода, то и код современного PHP, понять Вы не сможете.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от Аноним (34), 07-Дек-18, 05:50
	Write-only аноним
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	42. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Антон (??), 07-Дек-18, 09:18
	мне этого сильно не хватает в SQL. Я уже задолбался эту последнуюю запятую ставить и удалять
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	66. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от vedronim (?), 07-Дек-18, 11:49
	А где там массивы?
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от ъ (?), 07-Дек-18, 12:23
	В инсертах, например.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Junior frontend developer (?), 07-Дек-18, 21:14
	Во все языки это добавляют со временем
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	21. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Григорий Федорович Конин (?), 07-Дек-18, 00:42
	затем же зачем в массиве можно оставлять запятую :)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	40. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Rom1 (??), 07-Дек-18, 08:16
	Для удобства
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	87. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от SenaIVV (?), 07-Дек-18, 13:56
	Это как раз-таки самое нужное, а то я давно устал уже при динамических строках массивов удалять последний символ запятой(при чем разными с..а функциями для utf-8 и windows-1251).
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. "Релиз языка программирования PHP 7.3"	–1 +/–
Сообщение от Ilya Indigo (ok), 07-Дек-18, 00:22
> При сборке с опцией configure --with-password-argon2 в функциях password_hash()... Да сдалась 300 лет эта убогая ф-ия для идиотов, в которой ещё заботливо запретили использовать свою соль! Лучше бы в hash_hmac() алгоритмы bcrypt и argon2(i|id|d) завезли. А так всё равно приходится пароли алгоритмом sha3-512 хешировать. :-( А так ничего сильно полезного пока не увидел, но и нарушающего совместимость тоже. P.S. Прошёл уже год а документация по sodium всё также отсутствует даже на английском. https://secure.php.net/manual/en/book.sodium.php
Ответить | Правка | Наверх | Cообщить модератору

	24. "Релиз языка программирования PHP 7.3"	+3 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 01:19
	У тебя что, соль какая-то особая, забористая? Чем обычная не устраивает, а?
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:32
	Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге, а динамическая берётся из id и время регистрации, которые запрещено менять в БД, а главное только я знаю как готовить хэш, и только я знаю как его проверять! А я всегда точно знаю, каким алгоритмом он будет создан и обязательно будет проверен, а также точно какой длины он будет! password_hash()/password_verify() предполагает что соль с параметрами всегда хранится с хешем, и алгоритм, соль и параметры мало того что всем известны, так ещё он всегда готовится и проверяется одинокого и password_verify() можно скормить вообще любой валидный хэш подсунув его вместо хэша требуемого пользователя! Такого мне не нужно, кушайте сами!
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз языка программирования PHP 7.3"	+3 +/–
	Сообщение от Аноним (55), 07-Дек-18, 10:42
	> а главное только я знаю как готовить хэш, и только я знаю как его проверять Security by obscurity? Спец, без сомнения!
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 10:43
	> Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге Т.е. утекла каким-то образом статическая часть, здравствуй генерация новых паролей. А если утекла статическая часть, то какова вероятность того, что злодей знает алгоритм готовки хеша? Соль вообще-то не обязана быть скрытой, она вообще про другое. > предполагает что соль с параметрами всегда хранится с хешем, и алгоритм, соль и параметры мало того что всем известны, так ещё он всегда готовится и проверяется одинокого и password_verify() можно скормить вообще любой валидный хэш подсунув его вместо хэша требуемого пользователя! Вот, пожалста, хеш пароля, какой он? $2y$10$kCkVDOxVduJsFkeD5mVcMO2YxK3/BcV02a0rmse6/KE6qjfDwSGcK Дан пароль jog7ygyt8t. Какой мне валидный хеш от любой другой строки подсунуть в password_verify, чтобы пароль был признан правильным? Предполагается, что пароль как бы неизвестен, т.е. брать хеш от этого пароля и предлагать тут нельзя.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	61. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 11:06
	>> Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге > Т.е. утекла каким-то образом статическая часть, здравствуй генерация новых паролей. 1 НЕТ! Без динамической части соль бесполезна, для генерации нужна и соль и данные из БД для каждого пользователя! 2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design! > А если утекла статическая часть, то какова вероятность того, что злодей знает > алгоритм готовки хеша? Если он получил доступ к ssh, то тут, конечно, уже ничего не поможет. Но если он каким-то образом получил доступ только к MariaDB, причём прецеденты были, то это ему никак не поможет в отличие от password_hash()/password_verify() где достаточно просто всунуть валидную хэш для админа. (P.S. И да id админов в конфиге вручную задаю) > Соль вообще-то не обязана быть скрытой, она вообще про другое. Я знаю, но меня не устраивает такой принятый By Design порядок вещей, что можно получив доступ к СУБД тупо вставить хэщ другого пользователя, пароль которого тебе известен или вообще самому сгенерировать её и такой хэш будет валиден. > Вот, пожалста, хеш пароля, какой он? > $2y$10$kCkVDOxVduJsFkeD5mVcMO2YxK3/BcV02a0rmse6/KE6qjfDwSGcK Да мне плевать какой он, я сгенируирую новый стандартным способом, пароль которого буду знать и заменю хэш в таблице админа, сделаю свои тёмные дела, верну старый хеш назад, и про это даже никто не узнает, если конечно в access log не посмотреть, а если админ заходит из той же сети или с телефона такого же оператора то он даже не сможет отличить он это входил или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 12:02
	> 1 НЕТ! Без динамической части соль бесполезна, для генерации нужна и соль и данные из БД для каждого пользователя! > 2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design! 1. зачем тогда статический кусок? без него это такой же хеш: динамическая соль + алгоритм хеша 2. с чего вдруг? тут перегенерация только если база утекла и то не так страшно, т.к. секретного алгоритма нет, а хеши достаточно стойкие. > Если он получил доступ к ssh, то тут, конечно, уже ничего не поможет. А если это админ-обиженка? Все алгоритмы на руках, прикопает до поры. Ну и если кто-то со стороны ходит по базе как у себя дома, то уже всё плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 12:35
	>> 2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design! > 1. зачем тогда статический кусок? без него это такой же хеш: динамическая > соль + алгоритм хеша Затем, чтобы 1 При получении доступа к БД злоумышленник не смог получить всю соль и сгенерировать хэш, даже если бы знал как его генерировать. 2 Чтобы имея под рукой аналогичный сайт и/или микрофреймвёрк этого сайта и зная как её генерировать всё равно не смог бы этого сделать без доступа по ssh. > Ну и если кто-то со стороны ходит по базе как у себя > дома, то уже всё плохо. Я не говорю что это нормально, у меня вообще доступ к ней только через сокет, но я сайты не для себя делаю и админю я далеко не все, и не с одним моим сайтом проблем со взломом не было, и я не хочу нарушать эту традицию! Если я могу сделать лучше чем это по дизайну (длина хэша для пароля меньше и всегда постоянная при той же безопасности, и более высокая защита при доступе к СУБД), то я это делаю!
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Sw00p akaJerom (?), 07-Дек-18, 14:54
	идея не плохая с разделением на части соли, но прикол в том, что постановка задачи у вас изначально не правильна, она равносильна этому - есть шифрованные данные (пример в общем, и не обязательно про хеширование), но криптоаналитик не знает алгоритм, при взломе шифра, уже предполагается, что криптоаналитик знает все о шифре, и все тут дорлжно упираться в ключ (только он не известен), говорить об "атакующий не знает алгоритма" - смысла нет. И в вашем случае говорить, что атакующий не видит части соли прописанной в конфиге, имея доступ только к бд, всего лишь навсего "безопасность через неясность", что категорически не приемлемо в самом понятии криптографии (самообман). Ну есть только доступ к бд, а что мешает сделать на подобии load_file('config.php') и тому подобное? (немного поутрировал)
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 15:22
	Я с вами не согласен. > уже предполагается, что криптоаналитик знает все о шифре 1 Без ssh доступа к серверу нет, а если доступ получен, то смысла уже нет. > "безопасность через неясность" ДОПОЛНИТЕЛЬНАЯ безопасность... Безопасности много не бывает, если при этом она не вредит производительности и удобству авторизации. Это как сказать, зачем закрывать дверь на замок, ведь в наше время есть куча способов открыть любой замок, по этому замок на двери не нужен, а всё будет упираться в... > а что мешает сделать на подобии load_file('config.php') Отсутствие ssh доступа к серверу. при наличие которого уже ничего не нужно будет делать. P.S. Поставленная мной задача обломать того кто получит доступ к СУБД чтобы заменить хэш админа и зайти как ни в чём не бывало под админом, при этом сохранить надёжность хэша, удобство авторизации и уменьшить объём кэша решается. Я не говорю, что к СУБД можно будет подпускать кого угодно ничего не опасаясь! Это просто дополнительная защита, которая в случае эксплоита субд или кривых рук админа может или защитить или заставить взломщика предпринять более заметные действия например вход по ssh, который в auth.log ssh сразу будет заметен, в отличии от access.log apache.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Sw00p akaJerom (?), 07-Дек-18, 15:50
	> Я с вами не согласен. >> "безопасность через неясность" принято, если со мной не согласны, то посоветую более вторитетный источник - Б. Шнайер, почитайте его труды, "на пальцах" все разъясняет. > ДОПОЛНИТЕЛЬНАЯ безопасность... заключил бы это в кавычки, "безопасность" - процесс, а не метод. > Безопасности много не бывает, если при этом она не вредит производительности и > удобству авторизации. Она должна быть достаточной и необходимой с условиями требований. > есть куча способов открыть любой замок, ну вот отлично, значить нужно прийти к выводу, что делается "что-то не так" >по этому замок на двери не нужен, а всё будет упираться в... дверь то, тогда зачем? >> а что мешает сделать на подобии load_file('config.php') > Отсутствие ssh доступа к серверу. при наличие которого уже ничего не нужно > будет делать. load_file - имелось ввиду средствами самой СУБД. > как ни в чём не бывало под админом ну в принципе админом быть и не нужно, если достаточно взять из базы всю информацию, которая собственно добавляется админом, если тока через админку там получить возможность для загрузки файлов и т.п. ну разные вектора и развития
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Sw00p akaJerom (?), 07-Дек-18, 14:44
	на то и коллизии существуют
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	100. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 15:20
	какова вероятность коллизии у bcrypt с blowfish или argon2? тупой брутфорс на видеокарте на 4 порядка медленнее, чем у того же sha512 в конце-концов выяснилось, что защищается от подмены хеша в базе, чтоб не дать залогиниться потом под паролем для этого хеша
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Sw00p akaJerom (?), 07-Дек-18, 15:38
	> какова вероятность коллизии у bcrypt с blowfish или argon2? ровно такая же как и md5, все зависит от битности. > тупой брутфорс на видеокарте на 4 порядка медленнее, чем у того же > sha512 от чего зависит эта "медленность" ? > в конце-концов выяснилось, что защищается от подмены хеша в базе, чтоб не > дать залогиниться потом под паролем для этого хеша что имелось тут ввиду я не понял
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 16:46
	> ровно такая же как и md5, все зависит от битности а в реальной жизни, без применения велосипедов? тот же солёный md5 можно, но реально сложно же > от чего зависит эта "медленность" ? насколько я понимаю, там и потребление памяти, и многораундовость влияют, и скорее всего параллелить расчёты нельзя > что имелось тут ввиду я не понял товарищ выше написал, зачем он так делает
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 16:49
	Собственно я к тому, что любой хеш нам только даёт возможность распознать утечку и инициировать смену паролей за разумное время, но не даёт 100% гарантии защищённости.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 01:21
	> Лучше бы в hash_hmac() алгоритмы bcrypt и argon2(i|id|d) завезли. ну если так надо, берёшь С и завозишь пулл-реквестом > А так всё равно приходится пароли алгоритмом sha3-512 хешировать. :-( зачем?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	49. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:42
	> ну если так надо, берёшь С и завозишь пулл-реквестом Трачу от недели до месяца на разбор всех тонкостей как это делается, реквестю, и в лучшем случае посылаюсь сразу, мол для паролей жрите password_hash()/password_verify() а hash_hmac вообще совсем для другого предназначен, а в худшем мой реквест просто будет висеть мёртвым грузом. Бывало, может не месяц, но достаточное кол-во времени тратил на SR а меинтайнер с подобными объяснениями их отклонял. Не так уж часто, кол-во принятых гораздо больше, но уже чую за что можно взяться, а что будет простой тратой времени. > зачем? Затем, что в отсутствии возможности использовать bcrypt и argon2(i|d|id), sha3-512 остаётся самым надёжным алгоритм для хэша пароля.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Мимокрокодил (?), 07-Дек-18, 09:34
	http://php.net/manual/ru/function.password-hash.php
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	51. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:45
	И что? Внимание Эта опция была объявлена устаревшей начиная с PHP 7.0.0. Рекомендуется использовать автоматически генерируемую соль.
	Ответить | Правка | Наверх | Cообщить модератору

28. "Релиз языка программирования PHP 7.3"	+2 +/–
Сообщение от java developer (?), 07-Дек-18, 02:25
отличный релиз замечательного инструмента. Всех поздравляем!
Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз языка программирования PHP 7.3"	+4 +/–
Сообщение от Аноним (39), 07-Дек-18, 08:00
В целом, PHP стал похож на нормальный язык. В него бы ещё объектно-ориентированные примитивные типы и коллекции, да перегрузку операторов и можно  жить.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от nobody (??), 07-Дек-18, 09:23
	Боюсь, что поезд ушёл. Ещё и оставив за собой огромный шлейф "былой славы"
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Онаним (?), 07-Дек-18, 09:30
	Ну вот да, перегрузки операторов зело не хватает...
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	48. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (48), 07-Дек-18, 09:35
	>ещё объектно-ориентированные примитивные типы Зачем они тебе?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	52. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (52), 07-Дек-18, 10:09
	Затем, чтобы можно было сделать так $someArray-> и увидеть все методы для работы с массивами, а не гуглить их каждый раз. Плюс есть надежда, что новые методы для работы с типами будут вменяемыми, а не как сейчас, когда одни функции принимают данные первым параметром, другие - вторым, одни чистые, другие - меняют состояние, одни внезапно преобразуют строковые ключи ассоциативного массива в числа, если они похожи на них, и работают с ними как с индексами, другие считают, что строка "0" - пустая.
	Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз языка программирования PHP 7.3"	–3 +/–
Сообщение от Попугай Кеша (?), 07-Дек-18, 10:25
Все-то я согласен с вами. И все правильно пишите. PHP плохой, PHP ужасный, функция проверки наличия файла может запускать чужой код. И я вас понимаю. Как разработчик. Но вот звоню я другу (друг делает проекты для частников и не только). И спрашиваю: "Как дела, на чем пишите проекты?". На PHP - отвечает. Почему, интересуюсь? А он - "Ну ты понимаешь, на рынке PHP-разработчиков пруд пруди, платить им много не надо, можно быстро взять человека и доучить с улицы, что сделать нужно". Далее нужно где-то разворачивать. Nginx есть у всех, либо Apache. И любой полуобразованный админ может либо знаком с ними, либо знает как разворачивать. В общем, в любом захолустье знают про PHP как разрабы, так и админы. И искать долго не надо никого. И платить мало. Выгодно, в общем! Так что я с ним соглашусь. Для малого-среднего бизнеса это выгодно. Вот такой "народный" язык программирования получается. Это и не хорошо, и не плохо. Это данность. А в фирмах крупных, конечно, где бабки на бюджеты пилятся и осваиваются, там можно и Java взять на бекенд, или вашу эту хипстоту - Go/Ruby/Rust, хотите - C#. А народ - а народ оставьте в покое. Пусть пишет на своем PHPю
Ответить | Правка | Наверх | Cообщить модератору

	57. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 10:58
	Всякие расплодившиеся курсы программирования говорят, что "можно быстро взять человека и доучить с улицы" питону и гошечке.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Andrey Mitrofanov (?), 07-Дек-18, 11:01
	> Всякие расплодившиеся курсы программирования говорят, что "можно быстро взять человека > и доучить с улицы" питону и гошечке. Нет. Расплодившиеся курсы говорят, что "человеки с улицы" таки _покупают_ распложившиеся курсы. Про "можно научить" оное не говорит, ни-ни.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Релиз языка программирования PHP 7.3"	+2 +/–
	Сообщение от Попугай Кеша (?), 07-Дек-18, 11:02
	Есть спрос - есть предложение. Да, можно. Если загрузить человека несложной работой - например, верстать по шаблону (даже без знания CSS, на фреймворке) landing-страницы или как это сейчас модно - спецпроекты (какую-нибудь страницу, посвященную событию в городе, или фирме, или в год хомяка например). Правильно. Человека обучают HTML-ю за неделю. Вкачивают базу по PHP еще за одну неделю. И вот он может идти за 50-60 тысяч фигачить лендинги в фирмешку "Рога и копыта" у которой такой работы завались. Через год такого спеца начинают вкачивать в JS, и вот он уже "front-end джуниор"!
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	81. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:31
	> Вкачивают базу по PHP какой такой php, везде только и видно питон, го и жс :) скоро, очень скоро там будет много макак, это уже заметно, вся илитность на хайпе пропала
	Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз языка программирования PHP 7.3"	+/–
Сообщение от DmA (??), 07-Дек-18, 11:51
тут скорей всего быстрота нужна разработки для клиента, PHP позволяет выстрелить в ногу, если клиент так хочет. О конечной стоимости владения  своим сайтом клиент не сильно задумывается. Поэтому PHP -быстрее и дешевле
Ответить | Правка | Наверх | Cообщить модератору

	69. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Попугай Кеша (?), 07-Дек-18, 12:10
	Сравните сложность настройки сервера на PHP + цену за сервер с поддержкой PHP в месяц/год со сложностью настройки сервера на Java (ну или Ruby, Python, Go, что хотите) + цену за сервер на Java (или что хотите), например. Почему-то эти факторы наши многоуважаемые друзья-разработчики не учитывают. Сколько времени у вас уйдет? А время = деньги в мире бизнеса.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от blblblblbl (?), 07-Дек-18, 13:27
	Разницы между настройкой nginx + php-fpm или nginx + python(ruby, go) нет, всё это делается за одно и то же время, виртуалка нужна и там, и там и за те же деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Попугай Кеша (?), 07-Дек-18, 14:55
	Shared уже не использует никто? Я просто не знаю, расскажите
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от пох (?), 07-Дек-18, 16:56
	скажу так - те, кто его используют, могли бы свою единственную страничку с телефоном разместить в гуглосайтах и не тратить деньги. но, поскольку не знают об их существовании - все еще платят макакам. Впрочем, недорого.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Попугай Кеша (?), 07-Дек-18, 17:03
	Люди как не странно не любят обучаться. По привычке платят. Таких много.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от Попугай Кеша (?), 07-Дек-18, 14:56
	Еще интересно за сколько вы Java развернете
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	123. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 18:11
	хз, у меня своего софта на джаве нет :) а вот эластик с полпинка заводится, стильно, модно, молодёжно
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от пох (?), 07-Дек-18, 16:54
	грошовому клиенту нет необходимости задумываться о "конечной стоимости" - его сайт вместе с его лавочкой (сайт иногда даже позже, если за хостинг заплачено на год вперед) через полтора года перестает существовать вместе с децльным бизнесом. меня больше удивляет, зачем крупные лавки используют какие-то другие технологии - тот же vtb, с его привычкой раз в год менять сайт (целиком, не то чтобы что-то по мелочи, а вообще абсолютно другой и вид, и использование, и снова все приходится искать хз где и натыкаться на глюки где попало) - от найма разработчиков подешевле явно бы выиграл.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	125. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от blblblblbl (?), 07-Дек-18, 18:12
	это ж осваивание бюджета, ты что =) других причин постоянно передылывать сайт нет как ещё честному манагеру денег потырить
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от пох (?), 08-Дек-18, 23:24
	> это ж осваивание бюджета, ты что =) > других причин постоянно передылывать сайт нет > как ещё честному манагеру денег потырить а, точно - а поскольку менеджер каждый раз разный, то и карманная контора, выигрывающая конкурс, каждый раз новая, и, разумеется, старый сайт весь неправильный, немодный, не молодежный, надо все-все-все переделать (а на деле - "хз, я в первый раз этот фреймворк вижу, фронтенд тоже на незнакомом мне...да нунахрен в этом копаться, давайте сделаем на нашем обычном матерьяле, плевать что пользователям заново привыкать")
	Ответить | Правка | Наверх | Cообщить модератору

76. "Релиз языка программирования PHP 7.3"	+/–
Сообщение от Аноним (76), 07-Дек-18, 12:57
а я ещё на 5.6 сижу :-(
Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от DmA (??), 07-Дек-18, 16:28
	провинциал :)
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Релиз языка программирования PHP 7.3"	–1 +/–
	Сообщение от Аноним (126), 07-Дек-18, 18:17
	У меня вот в компании только недавно подняли минимальную версию до 5.6 для выпускаемого продукта. Противные шареды не желают обновляться, противные клиенты не хотят в этом разбираться - грустные разработчики снова и снова лепят костыли на 5.6.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	139. "Релиз языка программирования PHP 7.3"	+1 +/–
	Сообщение от пох (?), 08-Дек-18, 23:24
	> Противные шареды не желают обновляться, противные клиенты не хотят в этом разбираться > - грустные разработчики снова и снова лепят костыли на 5.6. а так ведь хочется обмазаться свеженьким!
	Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз языка программирования PHP 7.3"	+1 +/–
Сообщение от Аноним (116), 07-Дек-18, 13:24
Прелесть PHP - в его монолитном рантайме, в котором есть почти всё, что нужно для разработки, и которому в общем случае не нужны 100500 дополнительных файлов с 100500 классов в 3 строчки для реализации задач. Впрочем, любители сделать для языка с динамической сборкой 100500 таковых всё равно живы, и то, что у них в итоге на выходе получается глючная тормозящая блоатварь - не удивительно.
Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз языка программирования PHP 7.3"	+/–
Сообщение от Аноним (127), 07-Дек-18, 18:32
https://blog.ripstech.com/2018/phpbb3-phar-deserialization-t.../ https://securityboulevard.com/2018/12/bypass-of-disabled-sys.../ https://blog.ripstech.com/2018/new-php-exploitation-technique/
Ответить | Правка | Наверх | Cообщить модератору

	130. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от Аноним (127), 07-Дек-18, 18:40
	https://rdot.org/forum/showthread.php?t=4379
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Релиз языка программирования PHP 7.3"	+/–
	Сообщение от нах (?), 11-Дек-18, 09:42
	ой, прекрасно, еще и getimagesize ВНЕЗАПНО исполняет код ;-)
	Ответить | Правка | Наверх | Cообщить модератору

137. "Релиз языка программирования PHP 7.3"	+/–
Сообщение от Аноним (137), 08-Дек-18, 22:52
Если пых переписать на Rust, то он станет хипсторским и его перестанут называть устаревшим! А еще безопасность будет!
Ответить | Правка | Наверх | Cообщить модератору

	140. "Релиз языка программирования PHP 7.3"	–2 +/–
	Сообщение от нах (?), 11-Дек-18, 09:40
	предлагаю делать форк! Если что, CoC я уже готов закоммитить. С вас readme.md! Задачи для следующей версии - список разработчиков к которым необходимо обращаться "Оно".
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема