Комментарии 73
я бы держался подальше от их проектов, эти люди просто не умеют программировать и не понимают что делают.
ключевые компоненты поддаются лёгкой замене
Спонсор согласен профинансировать работы
а нет, ошибся. Всё они понимают, т.е. этот проект изначально не про улучшение софта, а про освоение бюджета.
Только я хотел написать про то, что новый код может обладать большим количеством уязвимостей, чем прошлый, как вы достали просто прекрасный образец треш кода. У нас магический безопасный язык, мы всё перепишем и сделам безопасным. Unsafe unsafe wile unsafe, безопасность!
Лично я не фанат раста, но еcли быть честным, то почти весь unsafe это взаимодействие со сторонними библиотеками, в частности PAM API. В этом собственно и лежит одна из проблем "переписывания" на раст, пока вся система не замкнута на раст или хорошо изолированна, будут торчать unsafe. Но вообще это проблема любого интеропа.
Вообще, один раз пишется библиотека-обертка, которая прячет ансейф под капот, а наружу выставляет безопасный интерфейс, не ломающийся от человеческих ошибок. Кода в такой библиотеке обычно не сильно много, и ошибок соответственно тоже, а из тех что есть большую часть отловит код-ревью на месте
А затем уже через безопасную идиоматичную обертку строится что-то полезное
Собственно, в этом и фича раста — ансейф хоть и торчит (без этого невозможно в системном языке), но в строго огороженных местах, где его видно за километр :)
Я далек от компилируемых языков, но разве может быть безопасным софт в исходниках которого так много слов unsafe?
Можно подробнее для тех кто не знаком с языком?
если говорить просто про язык. Они там пишут
let curr_str = CStr::from_ptr(...);
...
unsafe { free(curr_str); }
в этом месте CStr заменить на владеющий CString, и тогда этот unsafe{free} можно было бы просто выкинуть. Еще непонятно зачем создается промежуточный Option - там что, за строчки кода платят?
То же самое с let envs = ... - в этом случае встроенного типа (если это можно так назвать) в расте нет, но им что, кто-то мешал реализовать обертку? Заодно запилить для нее трейт Iterator, чтобы писать что-то типа
for curr_str in envs { ... }
вместо
let mut curr_env = envs;
while unsafe { !(*curr_env).is_null() } {
...
curr_env = unsafe { curr_env.offset(1) };
}
То есть даже этот изолированный кусок кода можно написать куда чище и понятнее, с куда меньшим количеством unsafe. Но главное даже не это.
Во-первых, сам по себе интерфейс функции pam_getenvlist сомнителен. malloc через malloc под капотом. Почему бы не придумать какую-нибудь pam_getenvlist2, заполняющую уже переданный ей буфер?
Во-вторых, предлагаю ознакомиться со списком зависимостей проекта. winapi, windows-sys (нафига это вообще в sudo?); два errno разных версий; два hermit-abi разных версий; lazy_static, lazycell и once_cell - 3 крейта, делающих примерно одно и то же; yansi и termcolor - еще 2 крейта, делающих одно и то же, и т.п.
Чтобы решить все эти проблемы, надо не просто переписывать sudo на раст, а контрибьютить в кучу сторонних проектов. Именно в возможности воздействовать на всю экосистему заключается основное преимущество свободного софта - мы не реализуем уродливые корнеркейсы и воркэраунды, а взаимодействуем с разработчиками зависимостей и выкатываем простое, красивое и лаконичное решение.
Товарищи из Prossimo, очевидно, не собираются заниматься ничем подобным, а значит их работа не принесет пользы экосистеме свободного софта. Не говоря уже про то, что для sudo уже давно есть хорошая альтернатива - чем я и советую всем пользоваться
Небольшое дополнение: в Cargo.lock не только прямые зависимости, но и вообще всё дерево, чтобы собиралось воспроизводимо. Скорее всего какая-то библиотека тянет их с собой всегда. То же самое с lazy_static и прочими
Да, по хорошему конечно надо сделать в той либе зависимость от winapi опциональной, и всем перейти на once_cell (а потом в будущем на std), но имеем что имеем :(
Хотя бы оно собирается в один дистиллированый LTO бинарник, и не создаёт этим зоопарком либ головняка пользователям
По поводу CStr и free, подозревая, что это защита от того, что могли быть использованы разные аллокаторы памяти внутри раста, и системной glibc.
А что будет если им прислать MR с исправлением?
del (да скорее всего там просто копия на момент аутентификации)
>в этом месте CStr заменить на владеющий CString, и тогда этот unsafe{free} можно было бы просто выкинуть
А каким образом это сделать? В `CString` есть конечно метод `from_raw` , но в описании явно написано, что использовать его для того что вы хотите сделать не нужно.
`trying to take ownership of a string that was allocated by foreign code) is likely to lead to undefined behavior or allocator corruption `
в этом месте CStr заменить на владеющий CString, и тогда этот unsafe{free}
То есть даже этот изолированный кусок кода можно написать куда чище и понятнее, с куда меньшим количеством unsafe
Что-то я не вижу как это сделать. pam_getenvlist вызывается один раз. То есть написание оберток для OwnCStr и Iterator для char ** с теми же самыми unsafe в итоге даст то же количество "unsafe", а кода будет еще больше чем в исходном виде. Вот если нужно было где-то еще работать с char ** алоцированном с помощью malloc это было бы оправдано.
Во-первых, сам по себе интерфейс функции pam_getenvlist сомнителен.
Так это же "C" функция внешнего API. Если бы у них была возможность не пользоваться libpam, то они бы просто не пользовались "C API".
Во-вторых, предлагаю ознакомиться со списком зависимостей проекта.
Реальные зависимости покажет "cargo tree". В частности lazy_static и lazycell это зависимости bindgen, которые вообще в проект никаким образом не попадут, так являются "build-dependicies", то зависимостями для сборки, а не работы. То есть с их помощью компилируется "bindgen", который генерирует из заголовочных файлов C список Rust функций и все. В исполняемыми файлы "sudo" код из lazy_static, lazycell и так далее не попададет ни каким образом.
То есть написание оберток для
OwnCStrиIteratorдляchar **с теми же самыми unsafe в итоге даст то же количество "unsafe", а кода будет еще больше чем в исходном виде.
Больше кода - это не всегда плохо. Плохо - это когда добавится или уберется какая-то ветка кода и вызвать free() либо забудут, либо вызовут его несколько раз. В C++ в подобных случаях либо используют unique_ptr с кастомным deleter'ом (очень удобно), либо делают свой класс-обертку и полагаются на RAII. Тут тоже можно (и нужно) было бы сделать структуру-обертку с impl Drop и предоставить RAII заботу о вызове free().
WARNING
Sudo-rs is currently under active development and is not suited for any production environment. Using sudo-rs is only recommended for development and testing purposes, but you should expect any system that has sudo-rs installed to break easily and to not be secure.
Написано же, ну.
Миленько, что тут скажешь. Безопасная безопасность подъехала.
Там внутри прототип, который (наверное) работает. Это точно не та стадия, на которой можно как-то оценивать хоть что-то. Новость звучит больше как "смотрите какую приблуду делаем, го пилить PR-ы".
Потому я в упор не понимаю, о чём срач. В качестве последнего варианта предположу, что многим просто влом прочитать этот текст на английском. Штош, взял и вбил в deepl. Может так понятнее будет:
Sudo-rs в настоящее время находится в стадии активной разработки и не подходит для использования в производственной среде. Использование sudo-rs рекомендуется только в целях разработки и тестирования, но вы должны ожидать, что любая система, в которой установлен sudo-rs, будет легко ломаться и не будет безопасной.
Здесь в стиле Капитана Очевидности предупреждают, что ПО, находящееся на ранней стадии разработки не надо пихать в продакшен.
Пока не до конца понимаю этой движухи "давайте все перепишем на rust". Это все еще развивающийся язык, там много замысловатых конструкций и синтаксиса. Понятное дело, что порог входа выше, но и выхлоп тоже будет лучше. Но дело в том, что и на Си можно писать надежные и поддерживаемые программы (на мой взгляд, иногда чистый С даже предпочтительнее С++). То есть чтобы писать хорошие программы нужно хорошо владеть Си, но и rust нужно понимать хорошо, иначе все будет в unsafe. Тогда получается, что rust это не замена языкам, а просто другой язык со своими плюсами и минусами. Поясните, в чем же такое преимущество rust, что необходимо переписывать старые программы на нем?
на мой взгляд, иногда чистый С даже предпочтительнее С++
Мне кажется, скорее не "иногда" а "почти всегда", если честно...
Я не стал так категорично писать, потому что допускаю какие-то обстоятельства когда нужен именно C++, но сам лично предпочитаю только С или C#. На простом Си программы пишутся более понятными, легче прослеживать маршрут данных. Опять таки зависит от архитектора программы, не исключаю что на плюсах получаются лаконичные программы. Но лично для меня перебор в сокрытии данных и разного рода перегрузках операторов, что синтаксически приводит в восторг программистов, но программа становится на самом деле сложнее.
Чисто из моих наблюдений. Не компетентные программисты, на больших проектах, пишут одинаково не масштабируемый говнокод, что на Си, что на плюсах. При этом часто ловишь себя на мысле, уж лучше бы на плюсах писали, там хотя бы есть из коробки, не такие ужасные строки, контейнеры и управление ресурсами(RAII и умные указатели). Да и объектность, хотя бы в какой-то мере мотивирует разбрасывать функционал по классам, а не писать сплошную лапшу.
Или если вы предполагаете, подобный ход развития событий, лучше сразу взять какую ни буть Java или С#.
никакого преимущества нету, просто язык на хайпе, за которым стоит Google. И гугл такое проворачивает регулярно - вспомните похороны flash/as3 ("FLASH-контейнеры небезопасные и вообще плохие, то ли дело html5 canvas"), возникновение node.js ("php|python|ruby - отстой, тру бекенд для веба можно писать и на js") и так далее, каждый раз рассказывается одно и то же - "язык/технология/платформа плохие, а вот мы-то вот мы сделали серебряную пулю, просто берите наши технологии и пишите лучший код в мире"
то же самое было про браузеры, когда Хром люто пропихивался и пиарился везде - все остальные браузеры - "старые и плохие", а вот мы-то "быстрые и ловкие".
Сейчас ведь, по сути, то же самый нарратив - внезапно С и С++ стали плохие, в телегу впрягся Микрософт, National Security Agency ot U.S. внезапно начало давать какие-то рекомендации про софт и безопасность доступа к памяти - а вы сами знаете, что это за признаки, когда в интернете из каждого утюжка начинают рассказывать про безопасность, master|slave, педофилов, инклюзивность и так далее.
Просто пройдёт какие-то лет 5 - 10, индустрия очнётся и увидит, что внезапно линукс стал на гугл.технологиях с гугл.лицензированием, разрабатываемый "некоммерческими организациями", которые сами без сопливого оpen-source сообщества будут знать, как правильно и безопасно развивать язык/технологии - нам останется лишь покупать аккаунты для доступа к SDK.
п.с: да, я на негативе, не верю Гугл и подозреваю тайные умыслы. Очень буду рад ошибиться в этих подозрениях, просто обидно за С и С++ - прям как будто на них нельзя делать хороший код и хорошие проекты, "вас ещё не зачато было, когда мой код на С уже работал"
Только Раст вроде не гугловый, а Мозилловый?
что внезапно линукс стал на гугл.технологиях с гугл.лицензированием, разрабатываемый "некоммерческими организациями", которые сами без сопливого оpen-source сообщества будут знать, как правильно и безопасно развивать язык/технологии - нам останется лишь покупать аккаунты для доступа к SDK.
О, я наконец понял, откуда у линуксоидов такой хейт к расту. Так активно топить за C\C++ могут только люди которые на них ничего серьезного не писали.
Вы вообще не в ту сторону смотрите, столько сколько сделали конониклы, гномы и т.п. для недопущения становления линукса конкурентоспособной десктопной платформой ни сделал больше никто.
Ну таки не без осечек. Помните, был такой язык Dart, который должен был заменить JS в браузерах, серверах и вообще стать новым языком-для-всего? Не помните? А Гугл кучу денег в маркетинг вложил в свое время :)
на Си можно писать надежные и поддерживаемые программы
Раз можно, то почему никто не пишет такие? CVE на CVE CVE погоняет. Раст не решение ВСЕХ проблем (он не исправит сломанную логику волшебным образом), но многих.
У раста точно так же все зависит от конкретного писателя - см. разбор кода выше, а также кучу проблем на RustSec, связанных с unsoundness, различными UB и out-of-bounds memory access. Что в расте, что в C/C++ решают в первую очередь используемые практики написания кода. Вот не используешь ты RAII в расте, пишешь вместо этого ручной вызов free() через unsafe, и вполне можешь получить в лучшем случае утечку памяти (которая превратится в уязвимость через DoS), а в худшем - какой-нибудь double free. Сильно вас согреет тот факт, что это произошло в коде на расте, а не на C? Вряд ли.
Ну вообще то это сильно лучше, чем то что есть в Си или крестах
Блажен кто верует.
Что проще поддается анализу? Когда все 100 процентов кода это unsafe, или когда весь небезопасный код сосредоточен в usafe блоках, которые составляют несколько процентов от кодовой базы.
Это не вера, а банальные и понятные цифры.
От того, что некие "экоактивисты" на своём митинге огородили дизельный генератор паллетами, он не перестал выбрасывать в воздух оксиды углерода и азота. Идея обёртывания error-prone кода в интерфейсы различной степени безопасности не нова, и применяется с переменным успехом практически повсеместно и без раста. Почему с переменным? А потому что это уже не сфера языка, но сфера практик. А с практиками у растаманов в среднем "как везде", взять хотя бы код из этого самого Prossimo, продемонстрированный коллегой выше (с комментариями). Более того, как я уже неоднократно писал, unsafe код раста ещё более error-prone чем код C/C++, потому что требования к нему выше, и на этом многие растописатели обжигаются, в том числе в растокоде, который ими рекламируется и на данном сайте. В общем ладно, дискуссия заходит на очередной круг, неохота время тратить.
Слушайте, вопрос. Был же когда-то давно такой язык "Managed c++" у мелкомягких? Я с ним не сталкивался лично, но по описанию, разве он не делает то же самое, что и раст, но без усложнений? Помню, его продвигали как прекрасного ребёнка плюсов и шарпов, вобравшего в себя лучшее от обоих родителей.
Правда, не слышал о нем уже лет сто.. оно живое вообще? Чем лучше/хуже раста?
Этот язык потом "причесали" и назвали С++/CLI. Но он делает вообще не то же самое что и rust!
Для начала, это язык с GC. Причём GC-объекты и обычные в нём нельзя так просто смешивать (точнее, обычный можно положить внутрь GC, а вот наоборот напрямую нельзя). В принципе, на этом можно заканчивать, потому что пользоваться получившейся химерой неудобно, и наследует она не столько достоинства обоих языков, сколько недостатки.
Для чего этот язык хорошо использовать — так это для интеграции управляемого кода с плюсовыми библиотеками.
Есть ещё C++/CX, на котором я сам не писал, но регулярно вижу примеры кода в блоге oldnewthing, который почитываю. Это тоже нестандартный C++, похож синтаксически отчасти на CLI, а отчасти на C#, компилируется в нативный код, вместо сборщика мусора подсчёт ссылок, как в ObjC/Swift. Но я так понимаю что в последнее время его вытесняет C++/WinRT, который не имеет доморощенных синтаксических конструкций и является полностью совместимым со стандартным C++.
Благодарю. Звучит и правда так себе. Неудивительно, что его нет в широком инфополе.
Я пишу такие. Какие проблемы решает rust?
Извиняю, но мне не нравится такое обобщение, я с ним не согласен. И разработчики в гугле, контрибьютеры в ядро или разработчики популярных библиотек не всегда отличные программисты, это не является критерием. Я согласен с тем, что частично какие-то случаи где программист что-то забыл или попытался что-то освободить это решает, но это далеко не самые сложные проблемы в разработке, и при этом повышая порог входа и читаемость самого кода. Что из этого выйдет покажет время.
Ну, в целом, чтобы писать на С "без дыреней" действительно нужен хороший навык, не имея опыта можно всё отстрелить себе, с этим я не спорю. Но насколько rust сложнее того же С в освоении в случае, когда это, например, первый язык? Я не имею ввиду, что какой-то язык лучше другого, каждый в своей нише, но мне до сих пор непонятен перевес в сторону именно переписывания на rust. Как я уже упоминал, мне нравится C# (хотя новые фичи вызывают вопросы), вот он как раз подходит для решения бизнес задач и порог входа не такой высокий. Если бы мне вдруг сказали что решили переписать на шарпе, то я бы так сильно не удивился.
Мифы про читаемость С кода уже устарели. Читать код - это не только понимать что делает данная строка или функция, но и что НЕ делает. И в примитивной системе типов С, выразить второе практически не возможно. Читая код на Раст, за редким исключением, сигнатуры функций и типов, благодаря сильной системы типов точно и однозначно говорят программисту как это использовать, кто чем владеет, потоко-безопасно ли это, какие ошибки возвращает и т.п. В этом и есть сила Раста - в системе типов и гарантиях.
Но ведь многие проблемы работы с памятью - это именно проблема логики? Большинство use after free, use uninitialised и т.д. ловятся даже компилятором
У людей вообще в принципе не получается писать "надежные и поддерживаемые программы" в смысле гарантированного отсутствия багов, если они начинают превышать размер в 10К строк.
Даже с привлечением отдельных институтов, которые могут годами делать "математически обоснованную" формальную верификацию, для тех же 10К строк. И CoQ и прочие "облегчалки", в корне ничего не меняют, солверы взрываются, сложность верификации с определенного объема(обычно как раз те самые 3-10К) начинает расти экспоненциально. Особенно если мы говорим о реальной системе с побочными эффектами.
Есть реальные примеры, подобной верификации например seL4, и пэйпер, если кто-то думает что я преувеличиваю. https://www.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4.pdf
"seL4, a third-generation microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler. Its performance is comparable to other high-performance L4 kernels."
"The project was conducted in three phases. First an initial kernel with limited functionality (no inter- rupts, single address space and generic linear page ta-
ble) was designed and implemented in Haskell, while the verification team mostly worked on the verifi-cation framework and generic proof libraries. In a
second phase, the verification team developed the abstract spec and performed the first refinement while the development team completed the design, Haskell
prototype and C implementation. The third phase consisted of extending the first refinement step to the full kernel and performing the second refinement.
The overall size of the proof, including framework, libraries, and generated proofs (not shown in the table) is 200,000 lines of Isabelle script."
Расскажите про сублинейность, потому что я в нее не особо верю, есть реальный опыт больших доказательств корректности значительно больше условных 10К строк? В автоматических/полуавтоматических пруверах, это все взрывается гарантированно. Теоретически конечно можно представить, что если сражаться в ручную, удастся все сделать более красиво и приемлемо, но как-то реальных примеров не видно. А те что есть примерно укладываются в те самые 10К строк. Я уж молчу сколько это удовольствие в принципе стоит.
10К для исходной системы. Речь не идет об экспоненте. Вы же доказываете не изолированные куски, всегда есть некоторая связность в том числе логическая, особенно если возникают серьезные побочные эффекты. В общем случаи связность будет дополнительно что-то добрасывать(умозрительно O(n^2)). В результате "поверхность доказательства" вырастает до размеров плохо управляемых, на не слишком больших исходных системах это в принципе не особо заметно.
Доказать мне это особо не чем, кроме известных опубликованных случаев доказательства относительно больших систем (в районе 10К), в которых конечный результат был получен значительными и долговременными усилиями. Поэтому в торжество формально доказательной разработки кода, на масштабах промышленного софта я в принципе не особо верю, даже если отбросить запредельную стоимость такой разработки.
Поэтому да есть определенные направления, где это все имеет смысл, даже экономический, но в основном это не слишком большие системы.
Но давайте позовём всех тех людей, которые жалуются на качество
современного софта и сокрушаются о том, что бизнесу лишь бы херак-херак и в продакшен!
Люди в принципе могут бесконечно жаловаться, пока им это ровным счетом ничего не стоит, там где есть конкуренция и голосование долларом часто все ни так плохо. Во многих случаях, банального бы улучшения культуры разработки и тестирования хватило, чтобы поток жалоб снизился на порядок, но за это ведь компании надо еще заплатить за разработку как минимум 1.5-2х и осадить эффективных менеджеров. О какой формальной верификации может идти речь, когда там даже на небольших масштабах ценник может вырастать в 100х, если это не профанация.
но и rust нужно понимать хорошо, иначе все будет в unsafe
Unsafe не заставит вашу программу магически компилироваться. Он позволяет конкретный набор действий, который компилятор не может проверить принципиально:
Разыменование сырого указателя
Реализация unsafe-трейта. Обычно это маркер, что тип можно передавать в другой поток (Send), или шарить между ними (Sync)
Изменение static mut (глобальной мутабельной переменной)
Вызов extern функции через FFI. Раст понятия не имеет, что ему туда прилинкуют, и что вы это вызываете правильно
Вызов unsafe-функции, которая может привести к UB если вызывать её некорректно
Все это используется либо для FFI, либо для написания прям очень системных штук, в которые без понимания, что происходит, лезть просто стрёмно. И даже там есть MIR Interpreter aka MIRI, который пройдёт вашу программу по шагам, но с сохранением контекста из Rust, что позволяет ему активно ловить UB в рантайме. Конечно, можно писать как тот программист на паскале из анекдота, но....зачем? Писать на С намного проще на C, он хотя бы сопротивляться этому не будет, в отличие от раста :DDD
Поясните, в чем же такое преимущество rust, что необходимо переписывать старые программы на нем?
Если не бороться с правилами языка, а использовать их, они отсекают ~70%¹ уязвимостей. Ну и как минимум, приятно писать, когда у тебя из коробки² есть система сборки, подключаемые одной строчкой либы, компилятор, объясняющий подробно где ошибка и ловящий кучу багов
inb4: в Си или C++ у меня поверхностные знания, так что подробно сравнивать с ними не буду. С Сишкой вообще странно сравнивать, она кмк в другой весовой категории. Я смотрю на раст с позиции питониста, и мне очень нравится :D
¹: на этой цифре сходятся как минимум разработчики Android, Chrome и Mozilla. Думаю у них достаточно большие кодовые базы, чтобы они могли давать объективные оценки ;)
²: приятна даже не сама система сборки (make, cmake и прочие в конце концов тоже существуют) а то, что она из коробки, и все пишут код совместимо с ней
Ну то есть речь не только о самом языке, но также и об экосистеме. Это действительно важно, в этом плане мне нравится C#. Насчет "уязвимостей" тоже согласен, но на мой взгляд эта проблема несколько преувеличена (правильная архитектура взаимодействия слоев программы, тестирование, документация тоже решают эту проблему). Важно понимать, что если новичок будет разыменовывать всё подряд, не следить за ресурсами, то конечно, это сильно повышает работоспособность программ (они иначе и не смогут собраться на rust). Но это не самая большая проблема в разработке, опять таки на мой взгляд.
правильная архитектура взаимодействия слоев программы, тестирование, документация тоже решают эту проблему
Как показала практика, когда кода становится очень много, как в ОС или браузере — не решают :shrug:
Человеческий мозг просто не в состоянии отследить такое количество взаимосвязей и нюансов
Почему не на ChatGPT/DreamCoder? NSA опять оставила всех далеко позади, ползти, за призрачными шансами....
А какие конкретно недостатки sudo/su они решать будут?
Отсутствие модного и молодежного языка =)
Да никаких, как выше показано. Не, ну я вижу конкретное преимущество даже в переписывании на C++, можно сделать код более поддерживаемым, читабельным, лаконичным, обложить всё тестами с ног и до головы. Но! Для этого нужно очень хорошо понимать предметную область. А вот с этим обычно у переписывателей беда. И это реально сложно, понять всё нагромождение костылей, особенности работы разных ОС, PAM, недостатки сишного API и т.д.
Отправить на пеньсию старых прогрогеров
Учитывая качество sudo, хуже быть уже не может. От него ж даже в OpenBSD отказались
А можно лучше придумать что-то новое, а не заниматься переписыванием готовых и рабочих решений? Например, сделать так, чтобы sudo-костыли вообще не пригождались. Это было бы намного лучшей рекламой раста чем очередное переписывание. Но цель здесь одна - закрепить своё поделие в мейнстриме, чтобы про язычок никто не забывал, точнее, не пришлось не забыв
Проект Prossimo перепишет sudo и su на Rust