1.1, Аноним (1), 08:07, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
> без должного анализа возвращённого ранее кода ошибки
Виноват си, потому что не дает sum types. То, что разраб забыл проверить -- простительно, потому что мозг -- это мясо. Мы не можем от мяса требовать 100%-ного анализа кода. К счастью, есть язык, который автоматизирует проверки. Он бы это выявил на этапе компиляции и подсказал мясу: "тут может вернуться ошибка". Мясо бы кивнуло и поблагодарило чудо-язык за техническую помощь.
| |
|
2.3, onanim (?), 08:55, 27/07/2025 [^] [^^] [^^^] [ответить]
| +5 +/– |
а gcc разве не выдаёт такие варнинги при компиляции?
и использование статических анализаторов разве не является обязательным при разработке критически важного софта?
| |
|
3.10, Аноним (10), 10:01, 27/07/2025 [^] [^^] [^^^] [ответить]
| –6 +/– |
Использование костылей разве не является обязательным при ходьбе?
| |
3.11, вымя (?), 10:24, 27/07/2025 [^] [^^] [^^^] [ответить]
| +8 +/– |
Если вы откроете патч (https://github.com/sudo-project/sudo/commit/fb208d383af27a07abe9cb277a620ea34c), то обнаружите, что pgrp приезжает из ec->cmnd_pid, который устанавливается вообще в другом месте, кем попало, как попало, аж в трёх си-файлах, да и там либо явно (= -1), либо очень косвенно (= cstat.val, = sudo_debug_fork()), а не из результата выполнения стандартной библиотечной функции. Компиляторный угадав тут явно бесполезен, потому что ему никто никогда не подскажет, используется ли потом это поле структуры в другом месте без проверки или просто авторы с привычками времён 80486 опять экономят байты исполняемого кода, удачно переиспользуя -1 по своему усмотрению.
И, да, Result/Either type тут действительно сэкономил бы время всем, потому что компилятор бы гавкнул на попытку использовать этот тип как аргумент kill(), и сделал бы это быстро и надёжно, в отличие от статических анализаторов, которым нужно проверить миллион инвариантов среди сотен функций из десятков файлов, не запутаться в них и не вылететь по исчерпанию памяти. Если, конечно, какой-то анализатор вообще надоумили проверить, что в kill() передаётся -1 (в чём я сомневаюсь, потому что отрицательные аргументы у kill легитимны и используются гораздо чаще, чем может показаться), потому что анализировать коды возвратов тут, похоже, бесполезно (см. выше).
| |
|
4.36, 1 (??), 17:10, 27/07/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Они сейчас вставили проверку на -1. Ну ок, а если прилетит -2? С таким подходом ни какие расты не спасут.
Их нельзя за это винить: Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается. Проблему создали те, кто решил тащить создаваемый таким способом код в энтерпрайз.
| |
|
5.42, Аноним (42), 21:22, 27/07/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается.
Ты больной? Оупен сорс - это модель распространения исходников и не более, к качеству кода это вообще никак не относится. Или ты думаешь в закрытом софте как иначе пишут и не галлюцинируют? Достаточно венду вспомнить с её троянами, вымогателями и порнобаннерами
| |
|
6.43, Аноним (43), 08:24, 28/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Больной здесь скорее тот, кто докопался до формального лпределения.
И да, в корпаниях пишут код иначе - там есть проверяющие.
В опенсорсе же таких часто нет. И да, опенсорц это хобби, даже Линус когда ядро писал был студентом и это был его хобби проект. Без интереса корпораций линукс был бы сейчас в лучшем случае где-то среди бздей, а в худшем - хурдом.
| |
|
5.45, laindono (ok), 11:21, 28/07/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
А -2 это тоже валидное значение. Всё, что необходимо - сделать сильнотипизированную обёртку. Везде, где мы снаружи получаем какое-то значение, мы его парсим в тип. Примерно как фейсконтроль в баре. Проверяем, что мы получаем. Если это не, то, что ожидаемо в конкретном контексте - выводим ошибку. Чтонибудь вроде Result<ProcessId, i32> даже сойдёт. Окей, в некоторых местах будет Result<GroupId, i32>. Или enum { ProcessId(u32), GroupId(u32), ... }. И с другой стороны, когда нам надо вызвать kill, то мы прям перед этим проверяем, если в конкретном месте имеет смысл только pid, но не gid. Нам ведь надо превратить тип-сумму обратно в число.
Просто делаем процесс явным всегда. Это сильно упрощает чтение кода, при том это самое чтение даёт больше информации. Более ёмкий и более читабельный код уменьшает вероятность логических ошибок. Поддержка становится проще и всё такое. А освободившееся время, которое не потрачено на пошаговый дебаг, можно использовать для написания тех же тестов например. Ведь не то, чтоб у нас были неограниченные ресурсы для написания и поддержки каждого мелкого винтика unix-way системы.
| |
|
|
|
2.8, Anonimm (?), 09:34, 27/07/2025 [^] [^^] [^^^] [ответить]
| –4 +/– |
А где же "миллионы глаз", которые пропустили эту ошибку ещё на этапе сборки?
| |
|
3.14, Аноним (14), 11:57, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
у sudo настолько огромная кодовая база что отдельному программисту практически невозможно проверить все
| |
|
|
|
6.29, Anonimm (?), 15:57, 27/07/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
О, как! А как же "Linux работает на N компьютеров, входящих в топ-500"? Неужели обманули? 😆
| |
|
|
8.33, Anonimm (?), 16:05, 27/07/2025 [^] [^^] [^^^] [ответить] | –2 +/– | Так его пихают туда просто чтобы был Да уж, умственные способности вендоров пор... текст свёрнут, показать | |
|
9.47, Аноним (47), 12:14, 28/07/2025 [^] [^^] [^^^] [ответить] | +/– | Значит, масштабируется на кластерах хорошо Чтобы работал и задачи по моделирова... текст свёрнут, показать | |
|
|
|
|
5.28, Аноним (28), 15:56, 27/07/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
ваша аппаратная архитектура байдезинг ненадежна, о чем речь вообще.
| |
|
4.34, 1 (??), 16:43, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Размер кодовой базы не причём. Налажал автор предыдущего изменения, а патч там был мелкий. В отладочном сообщении он прямо писал, что собирается вызвать killpg, но строчкой ниже вызывал kill. Если такие ошибки пропускают, значит с ревью изменений там на самом деле все плохо.
| |
|
3.37, Аноним (37), 20:04, 27/07/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я своими двумя посмотрел и снёс этот ваш sudo из системы. Чтобы пакеты не выпендривались, сделал псевдопакет без судо.
| |
|
|
3.30, Anonimm (?), 15:59, 27/07/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ниче, скоро ИИ её читать будет, новости о новом бэкдоре станут чаще здесь мелькать..
| |
|
|
3.38, Аноним (37), 20:08, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
В нормальном языке типы не утекают в исполняемый код. А если именно это и надо, то пилите struct с интом в начале структуры и всеми необходимыми структурами в union ниже. Великолепно работает.
| |
|
|
1.16, Карлос Сношайтилис (ok), 12:31, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> При передаче отрицательного значения группы поведение не определен
Сишное мышление.
Когда привык, что UB это неотъемлемая часть системы и переносишься это на уровень пользователя.
| |
|
2.39, Аноним (37), 20:12, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Если я вашу rust программу (без шизофренической проверки каждого аргумента для каждой функции) запущу и на следующий день другой компонент системы, который вы в rust не контролируете (структура или код ошибки из ядра, данные из файла, из прилинкованной библиотеки), то в вашем расте внезапно тоже появится UB, потому что *ТЫ* не проверил входные данные.
| |
|
3.51, Аноним (-), 15:05, 28/07/2025 [^] [^^] [^^^] [ответить] | +/– | В худшем случае не UB, а паника Если, допустим, у меня есть тип ProcessId, и я ... большой текст свёрнут, показать | |
3.52, Аноним (52), 17:01, 28/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
В Расте обычно не проверки аргументов из примитивных типов, а предварительное преобразование из примитивных в оберточные типы. Проверка делается в конструкторе.
Без проверок никуда, но с таким подходом их будет намного меньше (если это pid, то мы знаем, что он не может быть -1, и пишем это один раз), а аргументом принимаем уже тип pid, который по определению (если мы правильно написали его конструктор из инта) валиден.
Такой подход, можно сказать, заставляет написать все проверки.
| |
|
|
1.19, Аноним (18), 13:55, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ни когда не понимал, зачем такую косую утилиту пихают почти во все дистры линукса
| |
|
2.24, Аноним (25), 14:58, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Потому что пользователей GUI пугают терминалы? )
Потому что он не в курсе привилегий и считает себя богом своей машинки, при этом ничего не понимая в плане безопасности надо принудительно разграничивать? )
| |
|
1.23, Аноним (25), 14:52, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>При передаче отрицательного значения группы поведение не определено
Косяк killpg(). Они скажут, что тот кто использует killpg() должен контролировать что передает её. Но killpg() - часть системы, и приумножать хаос своей неопределенность не должна. Тем более проверка на входе для неё не критичная в плане производительности. Это все, может быть оставлено для костылей? Но ведь поведение кода не определено при таком фактическом значение!
| |
|
2.27, вымя (?), 15:33, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Описание в новости не имеет отношения к реальности, кстати. В патче не подчищают за killpg(), а меняют kill() на killpg(), а у kill() поведение при отрицательном pid как раз-таки определено чётко. Что, конечно, не отменяет ногострельности интерфейса в современных руках.
| |
|
1.32, Anonimm (?), 16:03, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Хороши "миллионы глаз", нечего сказать. Уязвимость случайно (?) появилась в сентябре прошлого года и только сейчас заметили, что sudo неправильно обрабатывает запросы..
Ниче, ИИ все эти "случайности" найдёт.. и добавит новые..
| |
|
2.35, 1 (??), 16:52, 27/07/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
На линуксах баг не воспроизводится. Проблему обнаружили на AIX, когда до них доехала эта версия. То что она приехала к ним через год, для энтерпрайзов это нормально.
| |
|
3.40, вымя (?), 20:39, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Не «не воспроизводится», а «ещё не успели воспроизвести». Там же не только aix, но и огромная куча людей на сервере, например; давно вы такое видели на серверах? А /dev/pts у линукса тоже не резиновый, на секундочку.
| |
3.41, Аноним (41), 20:43, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Когда портируют ПО из Linux в BSD, необходимо всё проверять, т.к. многие самые обычные вещи работают по-разному. Всегда проверяю.
| |
|
|
|
2.49, Аноним (-), 12:59, 28/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Debian stable с проверенными временем дырявыми пакетами.
Так будет точнее)
У них минимум 3 года сквид был с 10+ штук уязвимостями. На который сам рахраю забил.
Но удалять дыярый пакет это не по деби(ли)ановски)
| |
|
3.50, Соль земли2 (?), 13:03, 28/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Может потому что squid надо самому всегда из исходников собирать, чтобы была поддержка HTTPS?
| |
|
|
|