Комментарии 24
Спасибо за статью Андрей и за uuid v7 который наконец-то в ядре v18.
Кажеться, что Postgres давно бы мог излечиться от многих врожденных болячек, но консервативный подход core team делает свое дело - тормозит развитие Postgres.
Или я не прав?
Я очень раз что новый UUID полезен :)
Тормозить развитие в довольной развитой системе - не очевидно неправильное решение. В качестве аналогии можно подумать о раковых опухолях - они тоже являются быстрым клеточным ростом.
В случае с Постгресом всё, конечно, не так однозначно, нам надо двигаться вперёд. Но осторожно, стараясь ничего не сломать.
То что UUIDv7 не вошёл в PostgreSQL 17 из-за того, что feature freeze случился за две недели до принятия RFC 9562 - это, по моему мнению, конечно плохо. Надо было коммитить год назад, мой код был готов.
Но в общем случае - в операционной базе данных стабильность превыше всего.
Это вечная борьбы - делать новые революционные фичи и не сломать старое. Что выбрать?
Многие продукты, как мне кажеться, нашли этому решение.
Например, тот же MySQL с 2023 года формирует Innovation релизы в которых есть супер-новые фичи, да возможны проблемы, но есть выбор - сиди на LTS или бери Innovation
У Clickhouse так же есть LTS ветки и обычные.
Не из мира БД - Haproxy, Zabbix, nginx и бог знает еще что, так же придерживаются концепций LTS релизов и быстрых релизов с новыми фичами.
Не представляю себе реальных пользователей бета-версий СУБД с чем-то сложнее домашнего бложика или стартапа с главным активом в виде дизайна презентации. Потерять данные, потому что какая-то транзакция полгода назад некорректно реплицировалась, и теперь у нас остатки по складам не сходятся? Нужно останавливать склад на недельную инвентаризацию? Нет, спасибо.
Меня лично прям прёт от подхода, когда выходит в среднем 1 версия софтины в год и всё, никаких минорный версий и патчей. И она просто работает, ичсх без багов.
Речь не о бета выпусках (они кстате есть), а о смене модели формирования релизов и мышления в core team. Чтобы выделить какой-то roadmap ликвидации основных болячек, да хоть какой-то roadmap (которого в принципе нет, там написано no formal list of feature requirements required for development), позволить принимать патчи более оперативно и не мурыжить авторов годами.
Возьмем к примеру патч с 64-битным счетчиком транзакций от постгреспро - уверен он оттестирован и проверен, но не принимают в ванилу, почему? Он большой, затрагивает много чего… очень интересная причина. А может причина в том что он исправит родовую травму и у платных дистрибутивов постгрес будет -1 платная фича?
Тот же патч Андрея (uuid v7) который не вошел в 17 версию по смешной причине с rfc.
Есть и другие интересные и нужные патчи которые остались висеть в комитфестах без продвижения потому что автор просто устал ждать и убеждать.
Любой новый функционал должен покрываться тестами и соответствовать каким-то адекватным требованиям и при наличии таковых он имеет право быть принятым, но…
Причина не коммитить что-то может быть смешной, но если она есть - найти коммиттера будет сложно. Их внимание довольно диффицитно, даже если его разделить на патчи вообще без недостатков.
Мы в Ржакенхилле (офис команды разработки в Екатеринбурге) играем в игру "назови 10 причин не коммитить это". В простой версии для commitfest item. В сложной - для commit log.
Роберт говорит "we tend to make a committer anyone who understands what actually can be committed". Думаю, это гипербола, но всё же что-то в этом есть.
Как тут не вспомнить fail story из PG 18:
525392d Don't lock partitions pruned by initial pruning
1722d5eb Revert "Don't lock partitions pruned by initial pruning"
Бета нужна. И тестеры тоже нужны.
Внимание дефицитно наверно потому, что все они работают в каких-то компаниях на full time, а роль комитера в postgres она в режиме совместительства. Интересно есть ли разработчики внутри postgres кто работает только там на full time?
Почему же контрибьюторов не сильно много? Рискну предположить, что из-за модели разработки, из-за высокого порога вхождения. Кажеться, что сама модель разработки postgres далека от совершенства и даже не пытается измениться. Комитфесты, рассылки в hackers, присылание файлов patch, боже даже irc есть (интересно там кто-то есть?), система ревьювинга и коллективной разработки из прошлого века (уж простите, я избалован github/gitlab/gitea/forgejo/jira и прочими удобными инструментами, забросайте меня помидорами, я их люблю).
Вот тут есть определённое искажение восприятия, которое я часто встречаю. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. И уровень разработки открытого кода на голову выше любой коммерческой разработки.
Да, процесс разработки сложился до того, как появился git. Тем более Github. Но сам процесс редко является проблемой. А вот когнитивная сложность системы, высокая связность движущихся частей - является причиной проблем. Linux модульный и там есть коммиттеры в разные части. Коммиттер Postgres внося изменения отвечает за всю систему + совместимость с расширениями, драйверами, экосистемой из тулзов.
>Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом.
Согласен, работают, но речь то про другое. Работают ли они full time над ванилой или full time над ответвлением постгрес в рамках коммерческой компании где они трудоустроены? Это все же разные постгрес и разные процессы. Какой процент времени они готовы тратить на ванилу, а какой на коммерческий продукт компании? Я уверен, что у все этот процент есть, так же как и есть список фичей которые коммерческая компания готова отдать в ванилу, но примут ли это в ванилу - риторический вопрос.
>Но сам процесс редко является проблемой
Не согласен. Вот пришел человек с патчем, предлагает фичу/багфикс, а в ответ тишина, пушит патч по 10 раз и снова тишина. Это не проблема когнитивной сложности системы, до этой части процесса дело даже не дошло. Это проблема процесса разработки, когда у комитеров/ревьюверов нехватка времени/сил или чего-то еще, чтобы проверить этот патч или хотя бы дать ответ человеку - мол хэй, ты молодец, но мы тут что-то загружены, давай ты пушнешь патч через пару недель когда будет посвободней. Ну а когда большой патч с классной фичей отклоняют, что мол мы не можем его проревьювить, мы боимся что он что-то поломает в неочевидном месте? По-моему это тоже проблемма процесса - мы не можем наладить процесс тестирования продукта, чтобы тесты покрывали наиболее важные части кода и когда мегафича что-то ломает, то тесты бы это отражали.
Работают ли они full time над ванилой или full time над ответвлением постгрес в рамках коммерческой компании где они трудоустроены? Это все же разные постгрес и разные процессы.
Нет, когда я говорю Постгрес - я имею ввиду ванильный Постгрес, а не что-то типа Постгреса. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. А не чем-то типа.
И да, коммерческие компании готовы отдать в ваниллу что угодно. Но оно не того качества, которое требует ванила.
Любопытно про что угодно и не того качества.
Но если честно, я в это слабо верю. Если ПостгресПро отдает приличное количество наработок в ванилу, то например от Тантор я не вижу рвения (или они втихушку это делают?). Возможно причина отчасти как раз в качестве кода, типа "А ну и так сойдет для ком. клиентов", но сдается мне, что есть и другая составляющая. Ну честно, не верю я что компания готова по доброте душевной отдать коммерческие наработки в ванилу. Ну выложили бы тогда все патчи у себя на сайте - берите люди добрые, у кого хватит сил и терпения - патчите и собирайте свои версии постгрес, а у кого еще и железные яйца, то используйте в проде. Но реальность увы другая Андрей.
Моё мнение - любой форк строго хуже ваниллы. Причём это касается даже мастера ванилы, который хуже релиза. А свежий релиз хуже прошлогоднего. Настоящий Постгрес начинатеся где-то с версии х.3 или х.4.
Ребята и из ПгПро, и из Тантора выкладывают патчи и чинят баги в ванилле - это замечательно. Сравнивать их коммерческие продукты не берусь (и даже не буду делать выводов из толпы PgPro в 40 человек в pgsql-hackers, хотя это хочется отметить! Тантор есть в хакерсах, это тоже замечательно, ждём остальных)
Прошу пояснить насчет CRIME. Поток репликации ведь может быть зашифрован SSL. Какая разница что при этом льется, сжатые данные или нет?
Если у нападающего есть возможность писать в базу данных и сделать так, чтобы его изменения сжимались вместе с какими-нибудь секретными данным - по длинне передаваемых данных он может понять насколько его данные похожи на секрет. Тут лучше поподробнее почитать CRIME, это очень инетерсная штука. Из-за неё сжатие удалили из TLS, сжатие существенно ослабляет криптографию.
Не обращайте внимания, это сугубо теоретические розовые сопли. Для атаки на репликацию postgres вам нужен а) доступ на прослушку канала репликации между шардами; б) ровно один писатель в мастер БД, который шлёт "сикретные сикреты" (одни и те же) с низкой энтропией и в) возможность слать свои запросы с произвольным текстом. Тогда, если вы случайно угадаете "секрет" или его достаточно длинную непрерывную часть в своём запросе, вы увидите, что сжатый пакет репликации имеет размер меньше, чем несжатый (ну так работают алгоритмы на базе LZW, не передают одно и то же дважды).
Автору статьи хочу посоветовать привести пример хоть одной реальной системы, где "секреты" - например, access token'ы - обладают низкой энтропией и передаются в открытом виде (типа пароля 12345). И честно признаться, виноват ли тут CRIME или может всё-таки лень юзера с таким паролем.
Начнём с того, что я не преувеличиваю, а констатирую наблюдаемые свойства атаки, указывая на все ограничения. В рассылке я, точно также как и вы, был сторонником включения сжатия, но настройкой суперпользователя. И сообществе в итоге пришло именно к такому консесусу по этому вопросу.
Во-вторых, все уязвимости обладают свойством "розовых соплей", но тем не менее эксплуатируются. Я очень надеюсь, что в своих системах вы более творчески и критически подходите к безопасности сервисов. Именно такое отношение "да тут взломать сложно" и приводит к большому количеству инъекций в коде. "Сложность" эксплуатации уязвимости зачастую номинальная.
Из приведённых вами примеров. Доступ на прослушку? Подходите творчески, достаточно доступа к мониторингу, например роли pg_select_all_data, чтобы увидеть представление со статистикой по сети. Ровно один писатель в БД в период времени длинной в сотни микросекунд. Это редкость? Нет. Секретные данные вместе с несекретными? Ну, допустим, у пользователя есть право менять свой пароль. Хэш его пароля лежит на одной страничке с md5 админа. Full page image уехавший по сети раскрывает пароль админа. Наконец, про энтропию - вам не нужно угадывать весь хэш за один раз, вы можете сделать тысячу смен паролей и подобрать хэш постепенно, по одному байту. В pgsql hackers можно найти эксплойт, который за 400 смен паролей атакующего вытаскивает хэш суперюзера, с которым потом можно зайти в базу. Любую, без особой специальной подготовки, просто включить сжатие и получить доступ к мониторингам базы!
Пожалуйста, не относитесь к безопасности своих систем вот так. Все уязвимости эксплуатируют творчески и с желанием приложить много усилий.
В pgsql hackers можно найти эксплойт, который за 400 смен паролей атакующего
вы забыли одно маленькое условие - в этот момент никто другой с базой работать не должен от слова совсем. Не самый частый случай для продовой базы с секретной инфой.
Подходите творчески, достаточно доступа к мониторингу, например роли pg_select_all_data
Да блин, ну это смешно. Если у меня есть pg_select_all_data, то я уже суперадмин. Зачем мне подбирать хэш, если я имею право его тупо прочитать?
не относитесь к безопасности своих систем вот так
ну а как? У каждой меры "безопасности" есть своя цена. В случае со сжатием репликации - это цена канала между серверами, отнюдь не нулевая. А вы рассказываете про появившихся откуда-то неизвестных атакующих с pg_select_all_data. Это театр, а не инженерия.
вы забыли одно маленькое условие - в этот момент никто другой с базой работать не должен от слова совсем. Не самый частый случай для продовой базы с секретной инфой.
Во-первых, уязвимость остаётся уязвимостью, даже если для эксплуотации требуется тишина. Во-вторных, не требуется, изменения пройдут в несколько сотен байт WAL, которые часто окажутся подряд даже в очень нагруженной системе. Но это всё не важно, я не хочу публично развивать идеи эксплуотации CRIME.
Да блин, ну это смешно. Если у меня есть pg_select_all_data, то я уже суперадмин. Зачем мне подбирать хэш, если я имею право его тупо прочитать?
Нет, это не так, pg_select_all_data не может читать pg_authid. Но цель, конечно, выйти из базы и атаковать соседние системы.
цена канала между серверами, отнюдь не нулевая
Это так с точки зрения применения в конкретной системе.
А с точки зрения массового продукта, сообществе Postgres не хочет чтобы настройки по-умолчанию приводили к известной уязвимости. Кроме этого, у security team есть определение уязвимости, под которое CRIME попадает, если сжатие ключено сервером из коробки.
А вы рассказываете про появившихся откуда-то неизвестных атакующих с pg_select_all_data. Это театр, а не инженерия.
Доступ к мониторингу может быть получен другим способом. Типичные взломы проводятся с комбинацеий уязвимостей, кроме того приправляются социальной инженерии. В моём примере CRIME используется для выхода из СУБД на машину, но цели и условия могут быть иные. Я не ломаю вашу базу, я только демонстрирую, что уязвимые к таком вектору атаки системы существуют.
ну а как?
Если вы администрируете базу данных - просто обновляйте софт вовремя. Основной вектор атаки в большинстве случаев - эксплуотация известных уязвимостей, если против вас используют zero day - вы бы не писали эти вопросы. Если вы разрабатываете приложение - временами просматривайте OWASP всем коллективом разработчиков - уже это сделает вашу систему намного более сложной целью в куче других атакуемых систем. Если вы разрабатываете базу данных... фиг знает, стоит изучать все существующие уязвимости. Могу порекомендовать мои работы: тренажер github.com/x4m/pg_cve_demo/ и статью https://xakep.ru/2021/12/03/postgresql-cve-history/
Но убедить коммиттеров в необходимости запретить отмену нереплицированного запроса я пока не смог.
А может сделать это опцией и пусть администратор решает что ему нужно?
Как не получилось сделать PostgreSQL лучше (и почему это нормально)