The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes, opennews (ok), 03-Фев-24, (0) [смотреть все]

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


2. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (2), 03-Фев-24, 13:19 
Кстати, утилита runc написана на безопасном языке Go
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +8 +/–
Сообщение от Карлос Сношайтилис (ok), 03-Фев-24, 13:25 
Если ты про дескрипторы, то язык тут ни при чём.
Если про гонку, то гошечка от неё не защищает
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +10 +/–
Сообщение от Аноним (2), 03-Фев-24, 13:27 
Дак и Си никогда не причём, это все процессор и контроллер памяти
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –3 +/–
Сообщение от Аноним (13), 03-Фев-24, 14:11 
Это да. Если компиляторы сишки будут бить разработчика десятком киловольт при любой попытке использовать указатели или динамически аллоцировать память — сишка станет безопасным языком.
Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +7 +/–
Сообщение от Аноним (31), 03-Фев-24, 15:50 
Без динамического выделения памяти вообще жизнь станет совсем тяжёлой. Даже Pascal может в динамические массивы.
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –2 +/–
Сообщение от Аноним (13), 03-Фев-24, 17:49 
Любителей Turbo Pascal можно пересадить на Turbo Basic. Такой же синий экран, но куда более безопасный язык.
Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (71), 03-Фев-24, 22:08 
Почему именно Турбо вспомнил? Есть вполне живой Free, который, наверное, в Linux даже более востребован, чем Windows.
Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от _kp (ok), 04-Фев-24, 05:23 
При всей нелюбви к Паскалю, таки использую, для небольших приложений, типа загрузкиков и конфигураторов устройств, ибо Лазарус собирает нативные приложения под Mac,Win,Linux с минимумом усилий.
Еще забавно, что студент вообще без знания Паскаля может на нем что нибудь написать полезное с минимумом подсказок.
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (91), 04-Фев-24, 07:40 
> Любителей Turbo Pascal можно пересадить на Turbo Basic. Такой же синий экран,
> но куда более безопасный язык.

А еще можно взять выключенный компьютер и подобрать монитор или телек рисующий синий экран без сигнала. Совсем безопасно станет, и без всяких труб.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

112. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 04-Фев-24, 14:48 
Единственный безопасный метод запуска программ на небезопасных языках — не запускать эти программы.
Ответить | Правка | Наверх | Cообщить модератору

232. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 06-Фев-24, 13:52 
> Единственный безопасный метод запуска программ на небезопасных языках — не запускать
> эти программы.

Ну я и предложил - не включать его. Решает в том числе и эту проблему, начиная прямо с boot ROM и UEFI. И кстати проверьте что сетевой шнур - отключен от розетки! Иначе какая-нибудь пакость типа ME - все равно пролезет ведь. Только полное отключение питания, только хардкор.

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Bottle (?), 03-Фев-24, 21:53 
Кстати такое можно неиронически устроить - с помощью системы сборки Cmake, подключая некий файл "forbidden.h" с переопределёнными функциями к любому другому. Тем самым можно запретить небезопасные функции и писать как на Расте, не переписывая код на Раст.
https://iq.opengenus.org/ban-use-of-c-functions/
https://stackoverflow.com/questions/32773283/cmake-include-h...
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

86. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 03:15 
Тут несколько аспектов.

1. Есть масса простых утилит, где не важно что и как, важно чтобы оно просто отработало на тех полутора примерах для которых написано.

2. Есть всякие анализаторы которые делают примерно тоже - возмущаются по делу и просто так на эти функции.

3. Та реализация что представлена генерит 3 строки на каждое вхождение, это не удобно.

В целом я согласен что srtcpy() и прочие функции для работы со строками без указания размера буфера не безопасны и не должны использоватся в современном коде.
Выкидывать strncpy() - глупо.
Но лично я бы предпочёл чтобы в компиляторы добавили варнинг про это, вместо этого туда нынче засунули самый бесполезный в мире варнинг -Wunsafe-buffer-usage чтобы подчеркнуть неисправимую неполноценность С и подтолкнуть к С++ и гнили.

Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 10:10 
ну вот кстати я слабо понимаю пользу от strn*

Зачем нам огрызок строки и что с ним делать если была нужна вся строка? Это вот уже плохие данные и чреваты уязвимостью дальше.
В большинстве реальных ситуаций с копированием строк ты сначала меряешь, потом выделяешь под копию место, не влезло - плюешься ошибкой, потом туда копируешь уже точно зная длину. И ошибки происходят потому что просто неправильно померяли - результат ты радостно запихнешь и в функцию с n.

А если ты вообще длину не знаешь по какой-то причине - а вынужден предполагать, по данным извне - то с тем же успехом можно пользоваться memcpy.

При этом strcpy и memcpy эффективны, ложатся в одну команду процессора, а вот варианты с n - нет, в процессоре не бывает комплексных проверок.

P.S.
#define BUF *buf
%s/strcpy(buf,string)/strncpy(BUF,string,sizeof(BUF))/g
Сасамба. 1998й год.

Уровень людей считающих что функции с n модно-надежно-безопастно. Сейчас такие программируют на безопастных йезычках примерно так же вот.

Ответить | Правка | Наверх | Cообщить модератору

100. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (2), 04-Фев-24, 12:54 
> И ошибки происходят потому что просто неправильно померяли - результат ты радостно запихнешь и в функцию с n.

Что, чёрт возьми, ты такое несешь.
n - это длинна твоего буфера, к-й тебе известен.

Ответить | Правка | Наверх | Cообщить модератору

104. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 14:32 
И как это вот оно так получается-то, что без конца при этом попадают мимо?

А я тебе скажу как - то что ты думаешь что тебе "известно" - внезапно, оказывается несовпадающим с действительностью.

И, повторяю для полных дол..ов - что будем делать если даже правильно все посчитали, нигде не ошиблись - но оно - вот?


Ответить | Правка | Наверх | Cообщить модератору

132. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 23:01 
Вы всегда можете пропатчить/заменить strncpy() на нечто будет вызывать abort() (аварийно завершать процесс), если вам это так надо :)

Вот такой макрос помогает понять когда функция сфейлилалась:
#define IS_SNPRINTF_FAIL(__rc, __buf_size)                \
    (0 > (__rc) || (__buf_size) <= (size_t)(__rc))
Но всё равно есть куча применений где пофик что оно могло сфейлится, или понятно сразу что сфейлится там просто не возможно, потому даже strcpy() часто безопасно применять.

> При этом strcpy и memcpy эффективны, ложатся в одну команду процессора

Вы считаете это смешно?
Даже на z80 memcpy() требовал более 1 инструкции, тк нужно было в регистры записать аргументы.
А для х86 эффективные реализации memcpy() довольно развесистые, с переходом на SIMD где это имеет смысл.

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

134. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от нах. (?), 04-Фев-24, 23:29 
> Вы всегда можете пропатчить/заменить strncpy() на нечто будет вызывать abort() (аварийно
> завершать процесс), если вам это так надо

очевидно что так скорее всего не надо, а надо как-то аккуратно отменить операцию и сообщить пользователю или кому-то выше по стеку приложения - где сломалось и почему так вызывать не стоило.

> или понятно сразу что сфейлится там просто не возможно, потому даже strcpy() часто безопасно
> применять.

именно об этом и речь - как правило мы уже померяли строку до того как с ней работать и либо  либо буфер ей выделили подходящий, либо поделили под имеющиеся, либо думаем какую метнуть в морду ошибку.
(а вот применение где "и таааак сойдет" мне вообразить довольно сложно, что бы это могло бы быть?)

> А для х86 эффективные реализации memcpy() довольно развесистые, с переходом на SIMD где это
> имеет смысл.

и им лишняя проверка тоже совершенно никчему.
Потому что jnz БЕЗ отдельной операции сравнения у нас есть наверное в любой архитектуре, кроме совсем уж странных, а "jnz но если еще и вон там образовался нолик то не" как-то не просматривается.

Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 05-Фев-24, 02:30 
У меня лично работа со строками обычно идёт как работа с буферами сырых данных (те указатель + размер, нуль никто не ищет), а всякие strncpy() почти не используются, snprinf() юзаются вон с тем макросом, обычно чтобы нагенерить ответ.


> а вот применение где "и таааак сойдет" мне вообразить довольно сложно, что бы это могло бы быть?

Иногда и на С пишут какие то проги типа как на Shell Script нечто, для того чтобы сделать простую работу или проверить что оно работает.
https://github.com/rozhuk-im/sec-omc-coder
Упадёт такое - да и пофиг, нужно оно раз в году для одного файла.
Или я как то писал удалятор временных файлов под венду, и кидал в автозагрузку. По сути это легко можно было заменить на .cmd файл или .sh под не вендой, но мне тогда в голову как то не пришла такая идея и я написал на С :)

Точно так же один знакомый на PHP писал консольные утилиты которые что то там делали с текстовыми файлами, потому что PHP для него основной язык.

Ответить | Правка | Наверх | Cообщить модератору

238. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 06-Фев-24, 19:16 
> https://github.com/rozhuk-im/sec-omc-coder
> Упадёт такое - да и пофиг, нужно оно раз в году для одного файла.

Вопрос: что сие за штука? Что за omc и самсунги? Такое описание как будто все знают о чем это. Самсунг производит что угодно - от аккумуляторов до морских кораблей, это хардварная версия Гугла.

Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от ng (ok), 05-Фев-24, 11:10 
> srtcpy() и прочие функции для работы со строками без указания размера буфера не безопасны и не должны использоватся в современном коде.

Плосы встречного дорожного движения обозначаются разделительной полосой или бетонным отбойником вдоль проезжей части.

Бетонный отбойник гарантированно исключает выезд на встречную полосу.

Включая ситуации, когда в крайнем левом ряду внезапное препятствие (ДТП), времени на экстренное торможение нет, правый ряд занят, а встречка свободна.

Добро пожаловать в безопасный, дивный мир. ;-)

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

172. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (172), 05-Фев-24, 14:55 
>Бетонный отбойник гарантированно исключает выезд на встречную полосу.

В бетонном отбойнике нет unsafe. И вылет на встречную он не гарантирует.

Ответить | Правка | Наверх | Cообщить модератору

202. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от ng (ok), 05-Фев-24, 18:02 
В точку!

Безопасность движения - это, сначала, мастерство водителей, а разметка дорог потом.

Надёжность программ - это, сначала, мастерство программистов, и "безопасный" ЯП потом.

Ответить | Правка | Наверх | Cообщить модератору

203. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 05-Фев-24, 19:27 
>>Бетонный отбойник гарантированно исключает выезд на встречную полосу.
> В бетонном отбойнике нет unsafe. И вылет на встречную он не гарантирует.

Ну вот хрустовский panic() это типичный бетонный отбойник. И хотел ли ты его получить в случае если кернел линуха не смог вооон там в аллокацию памяти - большой такой вопрос. Может лучше было зафейлить сискол с каким-нибудь -ENOMEM или чем там, да и хорен с ним - по сравнению с падежом всего кернела с грохотом то? Конечно, в панике кернел в довольно безопасном стостоянии, но...

На память об этом безопасные хрустики придумали try* костыли на свои конструкции (чем это так отличается от остальной динамической аллокации, с которой боролись?!). Изящно так получилось, совсем не похоже на костыль и на то с чем так пафосно боролись. Оказывается постоянно убиваться о бетонный отбойник то - это такое себе. Надо же!

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

82. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –2 +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 01:20 
Нужна не абстрактная безопасность а работоспособность и производительность.
При этом работоспособность иногда включает в себя и вашу "безопасность", если это является целью работы програмы.

А эта ваша "безопасность" похоже на кастрацию, когда ничего в языке сделать нельзя, да он ещё тебя поучает и отвественность за ошибки типа с тебя снимает.

В общем пока вот такие хотят безопасности, веганствуют и запрещают оружие, нормальные люди покупают очередной ствол, жарят шашлык и пишут прогу на С которая делает то что им нужно.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

84. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (84), 04-Фев-24, 02:53 
Мне почему-то кажется, что вы ездите на автомобиле, не пристёгиваясь ремнём.
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 04-Фев-24, 02:55 
Вам действительно кажется :)
Я езжу В такси, пристёгиваясь там где таксисты не убрали ремни.
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от Аноним (13), 04-Фев-24, 14:59 
Как насчёт того, что пристёгивание ремнём влияет на производительность поездки (добавляет +2 секунды в начале и в конце)?
В вашем представлении, это должен быть очень серьёзный оверхед.
Ответить | Правка | Наверх | Cообщить модератору

140. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Ivan_83 (ok), 05-Фев-24, 02:37 
Функция перевозки - доставить пассажира до места целым, очевидно что не пристёгивание может повлиять на целостность :)
Водитель обычно не ждёт когда пристегнутся, по крайней мере здесь обычно так, и поскольку он не стартует сразу до сотки (да тут и погонять негде) то это не существенно.
Ответить | Правка | Наверх | Cообщить модератору

204. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 05-Фев-24, 19:29 
> Как насчёт того, что пристёгивание ремнём влияет на производительность поездки (добавляет
> +2 секунды в начале и в конце)?
> В вашем представлении, это должен быть очень серьёзный оверхед.

Ну, если телепортатор перекидывал меня через половину глобуса за секунду - 2 секунды на пристегнуться, и 2 на отстегнуться будут, очевидно, подбешивать...

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

88. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от Аноним (-), 04-Фев-24, 06:02 
> При этом работоспособность иногда включает в себя и вашу "безопасность", если это является целью работы програмы.

Корректность программы -- это составная часть работоспособности. А если мы под "безопасностью" понимаем safety в стиле раста, то это составная часть корректности. К киберсекурити это имеет лишь косвенное отношение.

> А эта ваша "безопасность" похоже на кастрацию, когда ничего в языке сделать нельзя

Не лезь в программирование, это не твоё. Попробуй сисадмином устроиться, там надо не столько уметь, сколько знать, то есть декларативное знание важнее процедурного. Может тебе лучше зайдёт.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

111. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (13), 04-Фев-24, 14:47 
> Нужна не абстрактная безопасность а работоспособность и производительность.

В общем, вам нужно, чтобы вашу прогу не просто могли ломануть, а могли это сделать тысячу раз в секунду, чтобы каждый китайский ботнет подсадил по своему трояну.
Правда, после этого производительность становится так себе, потому что система начинает майнить сразу несколько криптовалют.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

90. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (91), 04-Фев-24, 07:39 
> Это да. Если компиляторы сишки будут бить разработчика десятком киловольт при любой
> попытке использовать указатели или динамически аллоцировать память — сишка станет
> безопасным языком.

Зачем так сложно? Статический анализатор и какой-нибудь misra checker в билд пайплайн - и попробуй-ка сгавнякай.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

56. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –4 +/–
Сообщение от OpenEcho (?), 03-Фев-24, 19:33 
> Если про гонку, то гошечка от неё не защищает

Там у Гошки ключик есть полезный для этого, -race называется

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

65. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +3 +/–
Сообщение от morphe (?), 03-Фев-24, 21:21 
> -race

Который найдёт только те гонки, что происходят регулярно, да и их не всегда.

Ответить | Правка | Наверх | Cообщить модератору

102. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от OpenEcho (?), 04-Фев-24, 14:19 
>> -race
> Который найдёт только те гонки, что происходят регулярно, да и их не
> всегда.

Если вы посмотрите на то, на что я коментировал, то уверен, что вы поймете о чем речь.

Изпользуйте как можно меньше го-рутин с шаред обьектами, разбивая логику на тестируемые юниты, Mutex, WaitGroup и каналы с shared ресурсами is must have, а не глобальные флаговые переменные  в надежде только на -race и все будет пучком, как впрочем не только с Го, а и любыми другими ЯП.

Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от morphe (?), 04-Фев-24, 15:14 
> как впрочем не только с Го, а и любыми другими ЯП.

Речь шла о том, защищает ли go от гонок данных, ответ - не защищает.

Если в Rust компилятор требует от тебя доказательства что гонок данных нет, то в golang тебе вручную нужно следить за тем что у тебя оптимально блокировки/атомики расставлены.

В сложном Rust коде это также позволяет более чётко разделять владение ресурсами, что позволяет проводить рефакторинг без риска где-то разломать хрупкие concurrency инварианты.

Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от OpenEcho (?), 05-Фев-24, 02:33 
> Речь шла о том, защищает ли go от гонок данных, ответ - не защищает.

В смысле сам язык? Автоматом? А такие вообще есть?

Го предоставляет достаточно инструментария чтоб не делать гонок, а значит если програмист умеет пользоваться языком, знает как работают операциоунные системы, то Го вполне даже защищает и
-race кстати, вполне хороший помощник если написанно достаточно грамотно и тесты написанны не для отмазки а с душой.

Если же кто то думает, что сляпает программу и проверит с -race, то определенно это заблуждение и это относится на сколько я знаю ко всем существующим языкам.

> Если в Rust компилятор требует от тебя доказательства что гонок данных нет,
> то в golang тебе вручную нужно следить за тем что у
> тебя оптимально блокировки/атомики расставлены.

как только понадобятся сырые указатели и включится ансайв, то он ни чем не будет отличаться о своих товарищей по цеху


> В сложном Rust коде это также позволяет более чётко разделять владение ресурсами,
> что позволяет проводить рефакторинг без риска где-то разломать хрупкие concurrency инварианты.

Я далеко не против против Раста, но его изпользование и поддержка на сегодняшний день обходятся дороже чем тот же Го || java. Не все синьоры (а то и принципалы) смогут быстро прыгнуть на растовый код, когда кодовая база наработана десятилетиями на других языках. Держать специально только растовиков, - очень накладно, потому как действительно глубоко понимающих этот язык не так уж и много

Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от morphe (?), 05-Фев-24, 02:55 
> В смысле сам язык? Автоматом? А такие вообще есть?

Ну написал же - Rust

> Го предоставляет достаточно инструментария чтоб не делать гонок, а значит если програмист
> умеет пользоваться языком

C предоставляет достаточно инструментария чтобы не делать выходов за границы буфера и use after free, а значит если программист умеет пользоваться языком... Ну как бы уже понятно

> как только понадобятся сырые указатели и включится ансайв, то он ни чем
> не будет отличаться о своих товарищей по цеху

Будет, поскольку unsafe не выключает гарантий языка, и более того, большая часть кода unsafe не использует.
Ну и без unsound кода ты не можешь получить гонки данных, т.е Rust таки тебя защищает.

> но его изпользование и поддержка на
> сегодняшний день обходятся дороже чем тот же Го || java.

Смотря для чего, там где тебе нужно работать в режиме реального времени go/java тебе не подходят из-за сборщика мусора. А Rust позволит тебе расставить атомики в строго нужных местах, и гарантирует что ты ничего не пропустил.
Также если у тебя не какой-то веб бекенд, а что-то, где реально важна корректность исполнения, корректность в Rust стоит на первом месте в отличии от golang (Примеров много, несколько штук упомянуты тут например https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...)

Да и в целом не очень сложно собрать команду Rust разработчиков, их уже достаточно много чтобы выполнять проекты любой сложности, тут скорее проблема что компаний использующих Rust на всех не хватает)
Особенно если есть предубеждения относительно криптовалют и HFT.

Ответить | Правка | Наверх | Cообщить модератору

180. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от OpenEcho (?), 05-Фев-24, 15:29 
> Смотря для чего, там где тебе нужно работать в режиме реального времени go/java тебе не подходят из-за сборщика мусора.

Вот это наверное самое главное - use the right tool for a job.

Что свелось по большому счету к С vs Rust, если это реал тайм, то определенно раст будет надежней (при условии, что раст програмист не дергается между проектами, а програмирует на нем каждый день), но там, где это не ринг ноль, не реал тайм, затраты на изпользования раста и что более важно его суппорт пока что дороже.


> Да и в целом не очень сложно собрать команду Rust разработчиков

Хелло-вордщиков, - да навалом

> их уже достаточно много чтобы выполнять проекты любой сложности

К сожалению у нас с вами разный опыт, большинство "растовиков" косячат так же как и с другими языками, есть которые действительо шарят и глубоко понимают язык и системы, но очень уж много хайпо-пиплов. Как только начинают топить за раст только, это первый признак, что у человека мало опыта, в отличие от действительно тех, кто  владеет многими языками и выбирют тот инструментарий, который больше подходит под конкретные задачи.

И это разговор больше про новые проекты, а то, что написанно и работает десятилетиями, переписывать все на безопасный язык, - на это не пойдут даже монстры, дешевле уплатить отмазку, беря риск, если что что-то пойдет не так.

Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (63), 03-Фев-24, 20:37 
Поняли, если дырявая прожка написана на безопастном язычке, тут же оказывается что "язык тут ни при чём". Все что нужно знать об умственных способностях проповедников святой безопастности.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

78. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 04-Фев-24, 00:17 
Именно. Так как безопасный язык не допускает языко-зависимых дыр (например, переполнения буфера), то остаются только дыры в логике программы.
Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (127), 04-Фев-24, 19:36 
Ты все равно не выловишь все memory огрехи в C/C++ статическими анализаторами, а в Rust такие ошибок тупа нет. Нужно максимально ошибки человеческого фактора перекладывать на компилятор, потому что это позволяет повысить качество софта в среднем, вне зависимости от квалификации и внимательности программистов.
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

9. Скрыто модератором  –4 +/–
Сообщение от Аноним (91), 03-Фев-24, 13:48 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

12. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +6 +/–
Сообщение от Аноним (13), 03-Фев-24, 14:09 
> Кстати, утилита runc написана на безопасном языке Go

Поэтому там хотя бы нет переполнений буфера.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

17. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Tron is Whistling (?), 03-Фев-24, 14:30 
Зато то, что там есть в силу особого подхода к погромированию - куда хуже.
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 03-Фев-24, 14:33 
Ничто не может быть хуже переполнений буфера, с учетом того, что любая программа на сишке содержит  их буквально в каждом килобайте бинарного кода.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от Аноним (63), 03-Фев-24, 20:28 
Ахтунг, у нас уникум который проверил каждую программу на Си, и в каждой нашел переполнения буфера. Или он балабол, что куда более вероятно.
Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –1 +/–
Сообщение от Аноним (13), 04-Фев-24, 00:11 
Любой разумный человек, если вы ему покажете прогу, написанную на сях и использующую динамическую аллокацию памяти и заявите, что там нет уязвимостей, скажет вам, что вы балабол.

Просто потому, что ни одной такой программы в истории человечества не зафиксировано.

Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Tron is Whistling (?), 03-Фев-24, 14:36 
@аноним выше
Хуже переполнений буфера может быть буфер переполнений.
А вообще давай, покажи хотя бы на kernel32.dll - где они там в каждом килобайте?
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

24. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 03-Фев-24, 14:44 
> Хуже переполнений буфера может быть буфер переполнений.

И то, и другое — синонимы термина "C programming language".

> А вообще давай, покажи хотя бы на kernel32.dll - где они там в каждом килобайте?

Я вашего труЪ олдскул юникса не разумею.

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от _ (??), 03-Фев-24, 18:24 
Да не, у тебя потупее имя было! (С) Однажды

Люди делают ошибки, прикинь! Кто бы мог подумать? Это что же - Дарвин прав и мы не дети богов а всего то придвинутые обезьяны? Какой Ёзык не дай - всё равно ошибки есть :)

Ответить | Правка | Наверх | Cообщить модератору

107. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 04-Фев-24, 14:41 
> Какой Ёзык не дай - всё равно ошибки есть :)

Просто при прямой работе с памятью их выходит в десятки раз больше, чем без.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +2 +/–
Сообщение от OpenEcho (?), 03-Фев-24, 19:41 
> И то, и другое — синонимы термина "C programming language".

Очередной студент освоил питон/раст и все остальное ка-ка & олд скульное ? :)

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

75. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Аноним (13), 04-Фев-24, 00:09 
> Очередной студент освоил питон/раст и все остальное ка-ка & олд скульное ? :)

Там про какой-то kernel32.dll говорили. Явно про самый труЪ юниксовый юникс от компании Мокрый Софт, без этих ваших ржавых докеров.

Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  –1 +/–
Сообщение от OpenEcho (?), 04-Фев-24, 14:23 
>> Очередной студент освоил питон/раст и все остальное ка-ка & олд скульное ? :)
> Там про какой-то kernel32.dll говорили. Явно про самый труЪ юниксовый юникс от
> компании Мокрый Софт

Я про: "синонимы термина "C programming language" если что...

> без этих ваших ржавых докеров.

докеры вообще-то, совсем совсем - не ржавые :)

Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (13), 04-Фев-24, 14:39 
> Я про: "синонимы термина "C programming language" если что...

Хороший препод в универе сразу скажет в начале курса что-то вроде "Как бы вы не старались писать на сишке без переполнений буфера, вы не сможете, каким бы гением вы ни были". И такие люди, как правило, не являются фанатами новомодной фигни.

> докеры вообще-то, совсем совсем - не ржавые :)

Это был лёгкий сарказм над "труЪ олдскульными программистами", для который всё, что не kernel32.dll — то модный ржавый игого-докер в кубернетисе под системд с вяленым, смузи-смузи-смузи.

Ответить | Правка | Наверх | Cообщить модератору

136. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от OpenEcho (?), 05-Фев-24, 02:08 
>> Я про: "синонимы термина "C programming language" если что...
> Хороший препод в универе сразу скажет в начале курса что-то вроде "Как
> бы вы не старались писать на сишке без переполнений буфера"

Препод в юнивер в большинстве случаев очень далек от реальностей продакшена, единицы которые действительно следуют индустрии, остальные же хорошие спикеры про хайп.


> Это был лёгкий сарказм над "труЪ олдскульными программистами", для который всё, что не kernel32.dll

Понятно :)

Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +4 +/–
Сообщение от Аноним (31), 03-Фев-24, 16:09 
>буфер переполнений

Двумерный массив?

>покажи хотя бы на kernel32.dll - где они там в каждом килобайте?

Тут чтобы что-либо показать, как бы, нужно иметь kernel32.h, kernel32.c, как минимум.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

72. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +1 +/–
Сообщение от Tron is Whistling (?), 03-Фев-24, 23:25 
Ну можно хотя бы от 2000 винды взять - они утекали.
Ответить | Правка | Наверх | Cообщить модератору

139. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноньимъ (ok), 05-Фев-24, 02:37 
Двумерный массив - это ложь.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

205. "Уязвимость в runc, позволяющая выбраться из контейнеров Dock..."  +/–
Сообщение от Аноним (-), 05-Фев-24, 19:31 
>> Кстати, утилита runc написана на безопасном языке Go
> Поэтому там хотя бы нет переполнений буфера.

Как оказалось от д@o2#$ов в программировании это не помогает и они ухитряются не то что свою память профакать - а вообще изолированный от них хост подставить, разломав абстракцию к чертям.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру