Да, начиная с PHP 8.0, assert больше не выполняет строковые аргументы как код, что повысило безопасность функции и снизило риски исполнения произвольного кода. Это важное улучшение.
Eval - это функция, цель которой выполнять переданный ей код. Уязвимости возникают не из-за самой функции, а из-за того, что если злоумышленник может контролировать ввод, передаваемый в eval, он сможет выполнить любой произвольный код на сервере. Это серьёзная угроза безопасности, так как позволяет выполнять опасные действия вплоть до полного захвата системы. Поэтому eval считается опасным инструментом и требует крайне осторожного использования и тщательной фильтрации входных данных.
Добрый день! Ваш комментарий по статье абсолютно справедлив и содержит много сильных замечаний.
Да, сериализация, eval и плагины WordPress - это классические уязвимости. Но суть статьи была не в открытии Америки, а в их комбинаторике и нюансах, которые часто упускают.
YAML. Это действительно неудачный пример. YAML не является альтернативой serialize() в PHP - это форматы с разными целями. Попробуем переформулировать: если вы всё же вынуждены работать с внешними данными, то JSON с валидацией по схеме - настоящая альтернатива. YAML здесь был недочетом.
Отключение allow_url_fopen действительно влияет лишь на возможность работы с удаленными файлами, это скорее мера ограничения нежелательного поведения на уровне конфигурации, а не полноценный механизм безопасности.
Касательно раздела 4 и примеров $key = (string)$key и строгого сравнения === — эти примеры не отражают точного понимания поведения PHP.
curl_multi. Уязвимость в том, что без правильной обработки curl_multi_select() возвращающей -1, весь набор запросов может зависнуть или зациклиться. Это приводит к DoS-состоянию приложения (истощение памяти, зависание). Согласны, что это не "классическая" уязвимость безопасности, а скорее проблема надёжности, которая может привести к отказу в обслуживании.
Intl. Выделение уязвимости именно в расширении Intl выглядит как слишком узкий фокус - на самом деле, и другие расширения, например Imagick и GD, тоже имеют уязвимости, но не всегда получают одинаковое внимание.
12. Это скорее особенность composer'а. Когда вы подключаете код через files-директиву в composer.json, этот код выполняется при автозагрузке, причём раньше, чем классы из вашего приложения. Если в зависимости есть вредоносный код или если зависимость скомпрометирована, она выполнится автоматически. Это не дыра в Composer, это системное свойство, но оно требует понимания и контроля.
Благодарим за детальный разбор - он помогает улучшить качество материала.
Добрый день! Ваш комментарий верен: в Symfony по умолчанию для сериализации сообщений в брокере используется нативная PHP-сериализация (serialize/unserialize). Это позволяет быстро и просто сериализовать объекты сообщений без сложных ограничений. Однако начиная с версии 4.3 возможна замена сериализатора на Symfony Serializer для других форматов, например JSON, если требуется межъязыковая совместимость или более гибкая настройка. Спасибо за уточнение!
Добрый день! Лучше оставить как есть для сохранения точности. Для снижения объема индекса можно пойти в сторону использования реранкинга и сократить размерность с 1030 векторов до меньшей, но можем потерять в точности. Можно попробовать порезать разрешение картинок из пдф в методе convert_from_path dpi = 225 # это значение будет использоваться для переменной min_pixels images = convert_from_path(pdf_path, dpi). Нужно поэкспериментировать и подобрать требуемую точность. Но идеала мы не получим на мощностях колабы. Хотя для каких-то задач этой точности вполне может быть достаточно.
Скорее всего установлена маленькая модель. Очень маленькие модели меньше 7b могут так себя вести. На то они и маленькие) Если ресурсы позволяют, можно попробовать загрузить модель большей размерности, например gemma3 7b.
Это решение было запущено на ASUS ZenBook 14 с 8Gb на борту и на других офисных буках. Отлично работает на Air M1. А скорость она же относительна. Понятно, что скорость будет медленне, чем с 5090 или L40. Но цель статьи была показать, что не боги горшки обжигают, и даже начинающий разбираться в этой теме может своими руками собрать то, о чем так много говорят.
Вы верно подметили, что с технической точки зрения механизм выполнения - это всегда динамический SQL. Все сводится к EXECUTE или PREPATE строки. Мы использовали термин «Self-modifying SQL» не для описания механизма выполнения, а для описания концепции и цели. Dynamic SQL - это техника «Self-modifying SQL» (в нашем контексте) - это сценарий использования Dynamic SQL. Его цель - изменить саму схему или логику базы данных на основе её текущего состояния. Запрос не просто выполняется, а анализирует метаданные и модифицирует их.
Ваша критика справедлива. Спасибо за Ваш комментарий.
Dynamic SQL - это, в первую очередь, техника. Его можно использовать как для DML, так и для DDL. Self-modifying SQL - это скорее концепция или сценарий использования Dynamic SQL. Её ключевая задача - изменение схемы или логики БД.
1. По поводу термина "Self-modifying SQL" - нет, это не совсем наш термин. Он не является официальным стандартом, как, например, "Dynamic SQL". Self-modifying SQL - это скорее концепция, "разговорное" обозначение для динамического SQL. Его ключевая особенность в том, что он не просто выполняет операцию, а меняет саму структуру или логику БД и т.д. Мы использовали этот термин в статье, чтобы ярче обозначить именно эту идею, когда код не просто выполняет операции, а меняет саму среду своего выполнения.
2. Про YAML Вы правы. Для стандартных миграций инструменты вроде Liquibase/Flyway - лучшее решение. Self-modifying SQL - про сценарии, где правила изменения схемы неизвестны заранее. Это не замена, а решение для других задач.
3. Про отладку согласны, это главный минус. Такой код сложно отлаживать.
4. Postgres и критические системы. Нет, это не так. Postgres как раз часто является основой критически важных систем. Предупреждение означает обратное: «Не используйте этот рискованный подход в таких системах (где как раз и работает Postgres), если у вас нет 100% защиты от инъекций». Это предупреждение об ответственности, а не о сфере применения Postgres.
1. Использование Bloom-индекса для нескольких столбцов
Действительно, в примере индекс создаётся на name, category, price, rating, но в конкретном запросе EXPLAIN ANALYZE показывает его использование только для name и category. Это связано с тем, что Bloom-индексы в PostgreSQL работают на уровне битовых фильтров. Они помогают отсечь заведомо неподходящие строки по тем колонкам, где есть точное сравнение (=).
Согласны с вами, данный момент нужно было указать, добавили информацию.
Ваш вопрос абсолютно логичен: действительно, хеш-индексы не позволяют сравнивать даты, как это делает B-Tree. Как мы писали ранее, Bloom-индекс не ускоряет сами диапазонные запросы. Однако, он может быть полезен при определённых сценариях, например:
- Когда у нас в запросе несколько фильтров и есть фильтр с точным сравнением (order_date >= ... AND status = 'processed').
Но если говорить чисто о order_date >= ..., то Вы правы — Bloom не поможет и лучше использовать B-Tree или BRIN.
Отличный вопрос! Bloom-индексы действительно ориентированы на точные совпадения (=), но в PostgreSQL они могут дополнительно помочь при различных фильтрациях (<, >, <=, >=).
1. Оптимизация поиска по нескольким столбцам (price, rating)
Bloom-индекс используется не для сравнения чисел, а для отсечения неподходящих строк.
Когда запрос содержит price <= 1000 AND rating >= 4, происходит следующее:
- Bloom-индекс быстро исключает строки, где name и category не соответствуют условиям (name = 'Laptop' и category = 'Electronics').
- Это уменьшает число записей, по которым PostgreSQL уже выполняет полный фильтр по price и rating.
Итог: меньше строк для обработки → быстрее поиск. Альтернативный вариант: если вы работаете только с диапазонами, лучше использовать B-Tree или BRIN.
2. Оптимизация агрегатных запросов (order_date)
Индексы Блума не прерывают сами агрегаты (COUNT, SUM, AVG), но помогают быстро исключить заведомо неподходящие строки.
При order_date >= NOW() - INTERVAL '1 month':
- Блум фильтр отбрасывает строки, где точно нет нужных дат.
- Оставшиеся строки идут в финальную агрегацию.
- Это ускоряет запрос, особенно если таблица большого размера и хранит много старых данных.
Вывод
Bloom-индексы дополнительно используются в различных запросах, уменьшая количество строк перед полной фильтрацией. Но если у вас только диапазоны, лучше выбрать B-Tree или BRIN.
Спасибо за комментарий! Markdown здесь используется не как формат хранения метаданных, а как удобный и человекочитаемый способ создания документации.
Вся информация о БД конвертируется в Markdown, потому что:
Легко читать — в отличие от XML или JSON, Markdown гораздо удобнее для восприятия.
Прост в представлении — его легко конвертировать в HTML, PDF или даже DOCX.
Гибкость — Markdown можно рендерить прямо в веб-интерфейсе без сложных инструментов.
При этом никто не мешает хранить метаданные в формате JSON или XML для технических нужд, но Markdown в данном случае играет роль готовой выходной формы для удобного представления информации.
Отвечаем на вопрос: если этот носитель будет формата Рутокен Лайт, то никаких проблем с копированием по нашему методу не будет. Рутокен Лайт является пассивным ключевым носителем и выступает в роли защищенного хранилища для извлекаемых ключей. В случае же носителей не экспортируемых ключей (например Рутокен ЭЦП 3.0) обязательным условием буде постоянное подключение носителя или прикладывания в случае с NFC носителем. Для подключения USB носителей ЭП к мобильному устройству приобретается любой OTG Переходник USB Type-C - USB
Хотелось бы увидеть официальные исследования на тему конкуренции смартфона с алкоголем, где первый выигрывает, это правда интересно. Мы наслышаны только о приложениях для борьбы с алкоголизмом, но хочется понять, каким образом смартфон может помешать одновременному просмотру интернета и распитию спиртного
Спасибо за ваш комментарий!
Да, начиная с PHP 8.0, assert больше не выполняет строковые аргументы как код, что повысило безопасность функции и снизило риски исполнения произвольного кода. Это важное улучшение.
Eval - это функция, цель которой выполнять переданный ей код. Уязвимости возникают не из-за самой функции, а из-за того, что если злоумышленник может контролировать ввод, передаваемый в eval, он сможет выполнить любой произвольный код на сервере. Это серьёзная угроза безопасности, так как позволяет выполнять опасные действия вплоть до полного захвата системы. Поэтому eval считается опасным инструментом и требует крайне осторожного использования и тщательной фильтрации входных данных.
Спасибо за уточнение
Добрый день! Ваш комментарий по статье абсолютно справедлив и содержит много сильных замечаний.
Да, сериализация, eval и плагины WordPress - это классические уязвимости. Но суть статьи была не в открытии Америки, а в их комбинаторике и нюансах, которые часто упускают.
YAML. Это действительно неудачный пример. YAML не является альтернативой serialize() в PHP - это форматы с разными целями. Попробуем переформулировать: если вы всё же вынуждены работать с внешними данными, то JSON с валидацией по схеме - настоящая альтернатива. YAML здесь был недочетом.
Отключение allow_url_fopen действительно влияет лишь на возможность работы с удаленными файлами, это скорее мера ограничения нежелательного поведения на уровне конфигурации, а не полноценный механизм безопасности.
Касательно раздела 4 и примеров $key = (string)$key и строгого сравнения === — эти примеры не отражают точного понимания поведения PHP.
curl_multi. Уязвимость в том, что без правильной обработки curl_multi_select() возвращающей -1, весь набор запросов может зависнуть или зациклиться. Это приводит к DoS-состоянию приложения (истощение памяти, зависание). Согласны, что это не "классическая" уязвимость безопасности, а скорее проблема надёжности, которая может привести к отказу в обслуживании.
Intl. Выделение уязвимости именно в расширении Intl выглядит как слишком узкий фокус - на самом деле, и другие расширения, например Imagick и GD, тоже имеют уязвимости, но не всегда получают одинаковое внимание.
12. Это скорее особенность composer'а. Когда вы подключаете код через files-директиву в composer.json, этот код выполняется при автозагрузке, причём раньше, чем классы из вашего приложения. Если в зависимости есть вредоносный код или если зависимость скомпрометирована, она выполнится автоматически. Это не дыра в Composer, это системное свойство, но оно требует понимания и контроля.
Благодарим за детальный разбор - он помогает улучшить качество материала.
Добрый день! Ваш комментарий верен: в Symfony по умолчанию для сериализации сообщений в брокере используется нативная PHP-сериализация (serialize/unserialize). Это позволяет быстро и просто сериализовать объекты сообщений без сложных ограничений. Однако начиная с версии 4.3 возможна замена сериализатора на Symfony Serializer для других форматов, например JSON, если требуется межъязыковая совместимость или более гибкая настройка. Спасибо за уточнение!
Добрый день! Лучше оставить как есть для сохранения точности. Для снижения объема индекса можно пойти в сторону использования реранкинга и сократить размерность с 1030 векторов до меньшей, но можем потерять в точности. Можно попробовать порезать разрешение картинок из пдф в методе convert_from_path dpi = 225 # это значение будет использоваться для переменной min_pixels images = convert_from_path(pdf_path, dpi). Нужно поэкспериментировать и подобрать требуемую точность. Но идеала мы не получим на мощностях колабы. Хотя для каких-то задач этой точности вполне может быть достаточно.
Скорее всего установлена маленькая модель. Очень маленькие модели меньше 7b могут так себя вести. На то они и маленькие) Если ресурсы позволяют, можно попробовать загрузить модель большей размерности, например gemma3 7b.
Благодарим за вопрос! Возьмем на заметку эту тему для следующих публикаций. Подписывайтесь на наш блог, чтобы не пропустить.
Это решение было запущено на ASUS ZenBook 14 с 8Gb на борту и на других офисных буках. Отлично работает на Air M1. А скорость она же относительна. Понятно, что скорость будет медленне, чем с 5090 или L40. Но цель статьи была показать, что не боги горшки обжигают, и даже начинающий разбираться в этой теме может своими руками собрать то, о чем так много говорят.
Вы верно подметили, что с технической точки зрения механизм выполнения - это всегда динамический SQL. Все сводится к EXECUTE или PREPATE строки. Мы использовали термин «Self-modifying SQL» не для описания механизма выполнения, а для описания концепции и цели. Dynamic SQL - это техника «Self-modifying SQL» (в нашем контексте) - это сценарий использования Dynamic SQL. Его цель - изменить саму схему или логику базы данных на основе её текущего состояния. Запрос не просто выполняется, а анализирует метаданные и модифицирует их.
Ваша критика справедлива. Спасибо за Ваш комментарий.
Dynamic SQL - это, в первую очередь, техника. Его можно использовать как для DML, так и для DDL. Self-modifying SQL - это скорее концепция или сценарий использования Dynamic SQL. Её ключевая задача - изменение схемы или логики БД.
Спасибо за вопросы!
1. По поводу термина "Self-modifying SQL" - нет, это не совсем наш термин. Он не является официальным стандартом, как, например, "Dynamic SQL". Self-modifying SQL - это скорее концепция, "разговорное" обозначение для динамического SQL. Его ключевая особенность в том, что он не просто выполняет операцию, а меняет саму структуру или логику БД и т.д. Мы использовали этот термин в статье, чтобы ярче обозначить именно эту идею, когда код не просто выполняет операции, а меняет саму среду своего выполнения.
2. Про YAML Вы правы. Для стандартных миграций инструменты вроде Liquibase/Flyway - лучшее решение. Self-modifying SQL - про сценарии, где правила изменения схемы неизвестны заранее. Это не замена, а решение для других задач.
3. Про отладку согласны, это главный минус. Такой код сложно отлаживать.
4. Postgres и критические системы. Нет, это не так. Postgres как раз часто является основой критически важных систем. Предупреждение означает обратное: «Не используйте этот рискованный подход в таких системах (где как раз и работает Postgres), если у вас нет 100% защиты от инъекций». Это предупреждение об ответственности, а не о сфере применения Postgres.
Спасибо за развернутый комментарий!
1. Использование Bloom-индекса для нескольких столбцов
Действительно, в примере индекс создаётся на name, category, price, rating, но в конкретном запросе EXPLAIN ANALYZE показывает его использование только для name и category. Это связано с тем, что Bloom-индексы в PostgreSQL работают на уровне битовых фильтров. Они помогают отсечь заведомо неподходящие строки по тем колонкам, где есть точное сравнение (=).
Согласны с вами, данный момент нужно было указать, добавили информацию.
2. Bloom-индексы и диапазоны (order_date >= NOW() - INTERVAL '1 month')
Ваш вопрос абсолютно логичен: действительно, хеш-индексы не позволяют сравнивать даты, как это делает B-Tree. Как мы писали ранее, Bloom-индекс не ускоряет сами диапазонные запросы. Однако, он может быть полезен при определённых сценариях, например:
- Когда у нас в запросе несколько фильтров и есть фильтр с точным сравнением (order_date >= ... AND status = 'processed').
Но если говорить чисто о order_date >= ..., то Вы правы — Bloom не поможет и лучше использовать B-Tree или BRIN.
Спасибо за уточнение!
Отличный вопрос! Bloom-индексы действительно ориентированы на точные совпадения (=), но в PostgreSQL они могут дополнительно помочь при различных фильтрациях (<, >, <=, >=).
1. Оптимизация поиска по нескольким столбцам (price, rating)
Bloom-индекс используется не для сравнения чисел, а для отсечения неподходящих строк.
Когда запрос содержит price <= 1000 AND rating >= 4, происходит следующее:
- Bloom-индекс быстро исключает строки, где name и category не соответствуют условиям (name = 'Laptop' и category = 'Electronics').
- Это уменьшает число записей, по которым PostgreSQL уже выполняет полный фильтр по price и rating.
Итог: меньше строк для обработки → быстрее поиск.
Альтернативный вариант: если вы работаете только с диапазонами, лучше использовать B-Tree или BRIN.
2. Оптимизация агрегатных запросов (order_date)
Индексы Блума не прерывают сами агрегаты (COUNT, SUM, AVG), но помогают быстро исключить заведомо неподходящие строки.
При order_date >= NOW() - INTERVAL '1 month':
- Блум фильтр отбрасывает строки, где точно нет нужных дат.
- Оставшиеся строки идут в финальную агрегацию.
- Это ускоряет запрос, особенно если таблица большого размера и хранит много старых данных.
Вывод
Bloom-индексы дополнительно используются в различных запросах, уменьшая количество строк перед полной фильтрацией. Но если у вас только диапазоны, лучше выбрать B-Tree или BRIN.
Надеюсь, это проясняет ситуацию!
Да, вы все правильно.
Bloom-фильтр гарантированно скажет "нет", если элемента точно нет в множестве.
Благодарим за внимательность!
Исправили.
Спасибо за комментарий! Markdown здесь используется не как формат хранения метаданных, а как удобный и человекочитаемый способ создания документации.
Вся информация о БД конвертируется в Markdown, потому что:
Легко читать — в отличие от XML или JSON, Markdown гораздо удобнее для восприятия.
Прост в представлении — его легко конвертировать в HTML, PDF или даже DOCX.
Гибкость — Markdown можно рендерить прямо в веб-интерфейсе без сложных инструментов.
При этом никто не мешает хранить метаданные в формате JSON или XML для технических нужд, но Markdown в данном случае играет роль готовой выходной формы для удобного представления информации.
Добрый день! Спасибо за обратную связь!
Отвечаем на вопрос: если этот носитель будет формата Рутокен Лайт, то никаких проблем с копированием по нашему методу не будет. Рутокен Лайт является пассивным ключевым носителем и выступает в роли защищенного хранилища для извлекаемых ключей. В случае же носителей не экспортируемых ключей (например Рутокен ЭЦП 3.0) обязательным условием буде постоянное подключение носителя или прикладывания в случае с NFC носителем. Для подключения USB носителей ЭП к мобильному устройству приобретается любой OTG Переходник USB Type-C - USB
Очень рады, что благодаря нашему материалу вы поверили в себя! Жаль, у вас нет своих публикаций, тоже бы поддержали всеми руками вашу минусовую карму
Благодарим за такой развернутый комментарий!
Спасибо, возможно, попробуем такой вариант)
Хотелось бы увидеть официальные исследования на тему конкуренции смартфона с алкоголем, где первый выигрывает, это правда интересно. Мы наслышаны только о приложениях для борьбы с алкоголизмом, но хочется понять, каким образом смартфон может помешать одновременному просмотру интернета и распитию спиртного