1.7, Аноньимъ (ok), 09:02, 28/08/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +7 +/– |
Обычно уязвимости приводят к взлому системы.
А тут к переполнению буфера.
А в старые добрые времена переполнение буфера приводило к уязвимостям, эх.
| |
|
2.61, ptr128 (?), 10:50, 30/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Новость надо читать полностью, а не по диагонали. Так как в буфере размещается криптографический хеш, то, по определению, за обозримое время невозможно сделать его содержимое предсказуемым. Так как эта задача сведется к операции создания строки по хешу, что имеет слишком высокую вычислительную сложность.
| |
|
1.10, Аноним (10), 09:33, 28/08/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Может просто указать размер буфера по максимально длинному хэшу в системе? Это самое простое и вообще не затратное решение, да и памяти экономит текущий способ максимум пару байт на ключ, что можно легко наверстать в другом месте.
| |
|
2.14, And (??), 10:45, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
А ещё можно просто проверять в коде поступающее снаружи.
Аксиома со школы, но многих потом учат не делать проверок на годность данных и прочие проверки на ошибки в вводе со стороны/от пользователя. И привычка-то меняется в худшую сторону, инженегр деградирует.
| |
|
3.15, ыы (?), 10:58, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –8 +/– |
Ну, вы если бы писали подобное, я уверен предприняли все необходимые проверки и защиты. К счастью вас не пускают к написанию такого кода. Почему к счастью? Потому что тогда вы бы были заняты делом, и не могли из-за нехватки времени общаться с нами тут...
| |
|
|
5.51, пох. (?), 00:15, 29/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Ну что вы, что вы, хозяин добр - на большинстве галер рабы могут пару часиков поспать, поесть и поменять носки чтоб хозяину в нос не шибало.
| |
|
|
3.16, Аноним (16), 11:23, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| –1 +/– |
Не, не, не, ты что, нельзя так делать! Такие проверки лишние, они только жрут ценное процессорное время и оно может тормозить на каком-то говне мамонта. Поэтому и не включают всякие stack-protector. Достаточно заявы погромиста "мамой клянусь, тут все ок" и можно сразу в прод!
| |
|
4.17, ыы (?), 11:29, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
Толи дело электрон.. вот в нем все хорошо... он просто не запускается на говне мамонта и можно делать все необходимые проверки...
| |
|
5.18, Аноним (16), 11:36, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
А причем тут электрон? Вам религия не позволяет прописать нужные флаги при компиляции?
Или ваш говнокод просто не скомпилируется с ними или будет падать на каждый чих?))
Или 1% производительности вам важнее безопасности?
| |
|
6.19, Аноним (-), 12:07, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
> Или 1% производительности вам важнее безопасности?
Откуда такая большая цифра? На фоне подсчета самого хеша, проверка размера буфера и прочей обвязки теряются.
Заметны будут (в большинстве случаев ненужные, но обычно все время педалируемые в качестве эталонного примера "жырножручести проверок" местными Ылитистами) проверки на выход за границу массива в циклах ...
| |
|
|
|
3.52, Аноним (52), 06:24, 29/08/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> А ещё можно просто проверять в коде поступающее снаружи.
Во-первых ключ меняется самой библиотекой, а не "приходит снаружи". Но надеюсь вы хотя бы саму новость прочитали.
Во-вторых не вижу никаких проблем выделять максимальное место для хэша сразу, вместо того чтобы (а) перевыделять память для одной и той же сущности на пару байт, (б) вообще иметь в этом случае дело с динамической памятью, когда речь идёт об одном слепке одного ключа, который в идеале в структуре должен находится как обычное число.
| |
|
|
|
2.21, anonymous (??), 12:42, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
Так уже написаны библиотеки и на Rust. Просто тут речь про другую библиотеку. В общем, не очень понятно, что вы предлагаете.
| |
|
|
4.29, Аноним (29), 16:15, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– |
Но ведь раст в FF и Редох показал, что растаманы тоже ошибаются при проверке индексов массива и вылетают, текут, падают...
| |
|
|
2.28, Урри (ok), 15:16, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +2 +/– |
LibSSH работает на всех (почти) платформах. Ваш любимый язык, к сожалению, покрывает только процентов 5 от нужного количества.
Впрочем, никто не мешает вам взять, и переписать libssh на rust. Сделайте доброе дело.
| |
|
|
4.33, Аноним (16), 17:36, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Конечно нет, llvm или сам тулчейн раста вполне может не поддерживать какую-то богом забытую маргинальную платформу из 90х, которую поддерживает CGG или какой-то другой компилятор, но "ЭТО ОЧЕНЬ ВАЖНО!!111" и используется как аргумент почему Си это тру, а раст это отстой.
| |
|
|
6.37, Аноним (16), 20:18, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Хаха, щютка на уровне Петросяна. Впрочем... глупо было ожидать большего.
Архитектур и платформ больше десятка, а на счет владельцев... напомните сколько владельцев у ядра линукса? То-то же...
| |
|
|
|
|
4.38, пох. (?), 20:23, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –4 +/– |
Для хрустобоя все что не поддерживается - неважное и незначимое.
> Список поддерживаемыъ платформ можно увидеть тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
ожидание - список на пару страниц. Реальность: в tier1 восемь строчек. Винда, винда, винда и винда. 64 bit only. И еще, вот, нате-подавитесь - линoops и максось. В единственно-верных позах.
Нда, с другой стороны - а чего еще от макак ждать...
Про tier2 не будем - мне ваши "guaranteed to build" нафиг не упали. ЭТУ гарантию обеспечивает llvm, угу. А вот что _ваша_ поделка что-то там build после этого, а не "такая херня, такая херня получается" - никто, похоже, не гарантирует вовсе.
Разумеется это то что нужно для low-footprint библиотечки собирающейся везде где вообще есть поддержка posix.
| |
|
|
6.43, Бздун (?), 21:32, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– |
> i586-unknown-freebsd
> бздя
Даже в консервативной фре - ожидаемый по умолчанию класс ЦПУ теперь i686 и вообще, x86 перевели в Tier2.
| |
|
7.45, пох. (?), 21:55, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Но 3d-party си-компилятор для нее, как видишь - пока еще не сломали. Потому что без него не будет ничего работать вообще, кроме голой фри, которая никому не нужна ни на 586, ни на чем другом.
| |
|
6.44, пох. (?), 21:53, 28/08/2021 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| –2 +/– |
> Мамонтам там и место
значит хрустикам вскоре найдется место на помойке - вместе с модными еще в прошлом году штанами от усраччи.
> Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно.
не найдется - ваш хруст не нужен никому кроме ошпаренных макак, любителей свежайшего. А те не умеют в долгосрочные сложные проекты, если их не финансирует гугль, или, например, гугль.
И это в общем-то хорошо. Очередная антитехнология далеко не уйдет с винды, винды, винды, и винды.
> https://gcc.gnu.org/gcc-11/criteria.html
а вот это, чувак, не "кое-как собирается сам бинарник". Это проходят тесты DejaGNU - гарантирующие не сборку бесполезного компилятора, а то что этот компилятор хотя бы периодически после этого компилит работающий на этой платформе код - причем всеми своими фронтендами. Для начала - на этой платформе они вообще должны работать, что не очень просто, операционная система нужна (а не ведроид).
При том что это gcc11, то есть снова нечто уже маловостребованное за пределами линoops под единственноверную архитектуру из-за троянцев в механизме.
К счастью, libssh пока вроде не требует для своей сборки моднейших версий компилятора - соберется и устаревшей на десять лет.
> Ни макоси, ни винды. Печалька.
диствительна. У них ведь, бедолажек, нет своего си компилятора?
А вот своего хруста, не завязанного на llvm единственноправильной версии - действительно нет и не будет никогда и нигде.
Т.е. его не будет никогда и нигде кроме платформ, куда эппл захочет спортировать свой код, и при этом еще сами хрустики осилят на него портироваться.
Закапывайте...
| |
|
7.46, Аноним (16), 22:31, 28/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> если их не финансирует гугль, или, например, гугль.
> не уйдет с винды, винды, винды, и винды.
Э... гугль или гугль? Винды и винды?
Дед, ты опять забыл таблетки выпить?
Но дело в том что их и так финансирует гугл. В Rust Foundation - как раз google, facebook, microsoft, aws, huawei, а в спонсорах - arm, github и еще кто-то.
Т.е. те же самые google, facebook, microsoft, huawei которые являются Platinum и Gold members в Linux Foundation))) Так что можешь не беспокоиться.
| |
|
6.58, нах.. (?), 21:09, 29/08/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –2 +/– |
> Разумеется, потому что 32бит в тиер2. Мамонтам там и место - последний интеловый 32bit only проц вышел 10 лет назад (атом), а последний нормальный десктопный - в далеком 2006. Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно.
Да вы профи. А ну брысь в школу, каникулы уже кончились.
| |
|
|
6.65, пох. (?), 12:18, 30/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
бть... какие ж вы все же ди-лы...
У gcc есть tier1 и 2. Как раз тем и отличаются, что одно тестируют, а другое - собралось, ну уже хорошо. Но он не распространяется в бинарниках, как и _любой_ gnu софт - ждите, д-лы. gnu распространяется своими разработчиками в виде исходников. Традиция тех времен, когда их принято было собирать у себя и для себя.
Придут добрые дяденьки и за вас все соберут, только к проекту они не имеют никакого отношения.
Может даже тесты запустят, прежде чем вам эту сборку вывалить на лопате.
А может нет, вы ж д-лы, вы и так схаваете.
| |
|
5.69, Урри (ok), 13:34, 30/08/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –1 +/– |
пох, ты конечно идиот. Но здесь отлично выступил.
Зацени как у народца подгорает-то, что их любимый растик полторы платформы всего поддерживает.
| |
|
6.73, Аноним (20), 17:57, 30/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и арм? Лигаси платформы не нужны, потому что кто под них будет переписывать? Надо новый код писать. А какой-нибудь авз микроконтроллер можно и на Си делать, там всё-таки проги должны быть маленькими и с памятью штык в штык работать (хотя кто-то вроде и Раст на микроконтроллеры запихивает).
| |
|
7.79, Урри (ok), 18:51, 30/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
> Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и
> арм?
Растишечным хелловорлдам, действительно, и одного windows/x86_64 хватать должно.
Даже не могу поспорить, все так.
| |
|
|
|
|
|
|
1.48, СССР (?), 23:14, 28/08/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
а кто юзал полноценно и libssh b libssh2? Первый я покурил хорошо, написал класс для работы с pty, реализовал sudo -u ser -i. В целом достаточно удобно. Единственное пришлось подумать как фиксировать конец потока, sleep не вариант ) пока не нулевая длинна блока тоже. Но там есть калбэки, возможно они вызываются когда происходит реальный конец вывода.
На libssh2 затэстил простой пример но не через pty. по факту что интереснее не сравнивал. У кого есть опыт с либами?
| |
|
2.56, Аноним (56), 20:03, 29/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Расскажите, как ограничить возможность их использования в системе по максимуму, если их удалить нельзя, так как другие программы не работают без них.
| |
|
3.85, СССР (?), 00:09, 31/08/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Расскажите, как ограничить возможность их использования в системе по максимуму, если их
> удалить нельзя, так как другие программы не работают без них.
Не совсем понимаю вопрос. вам для чего их удалять? Просто отключите сервис в системе и будет вам счастье.
| |
|
|
1.49, СССР (?), 23:18, 28/08/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
"В качестве запасного метода защиты можно ограничить список поддерживаемых методов обмена ключами только алгоритмами с одинаковым размером хэша" - это же для решения проблем на сервере?
| |
1.89, Аноним (-), 07:39, 03/09/2021 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
> операция смены ключа допускает применение криптографических
> хэшей с размером слепка, отличающимся от первоначально использованного алгоритма
Кто вообще придумал такое переобувание в полете?
| |
|