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

"Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от opennews (??), 28-Авг-21, 08:31
В библиотеке libssh (не путать с libssh2), предназначенной для добавления клиентской и серверной поддержки протокола SSHv2 в программы на языке Си, выявлена уязвимость (CVE-2021-3634), приводящая к переполнению буфера при инициировании процесса смены ключа (rekey) с использованием механизма обмена ключами, применяющего другой алгоритм хэширования. Проблема устранена в выпуске 0.9.6... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55698
Ответить | Правка | Cообщить модератору

Сообщения

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

5. "Уязвимость в libssh, приводящая к переполнению буфера"	–6 +/–
Сообщение от Аноним (5), 28-Авг-21, 08:50
Ну сколько можно... без радикального переписывания не обойтись.
Ответить | Правка | Наверх | Cообщить модератору

	6. "Уязвимость в libssh, приводящая к переполнению буфера"	+5 +/–
	Сообщение от Иваня (?), 28-Авг-21, 08:59
	Не ной, займись этим, замаял уже!
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Аноньимъ (ok), 28-Авг-21, 09:07
	Согласен, слишком много фрактальных недостатков накопилось.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	12. "Уязвимость в libssh, приводящая к переполнению буфера"	–9 +/–
	Сообщение от Аноним (12), 28-Авг-21, 10:11
	> Согласен, слишком много *ректальных недостатков накопилось hotfixed
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от hohax (?), 28-Авг-21, 17:02
	Здесь вам не тут!
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (40), 28-Авг-21, 20:56
	Тут вам не здесь!
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от СеменСеменыч77 (?), 29-Авг-21, 21:07
	хитрый какой анон. всем известного стоп-слова нет - жаловаться модеру нет оснований.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	71. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Fedd (ok), 30-Авг-21, 15:31
	Вот кто тут значит настукивает
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от СеменСеменыч777 (?), 31-Авг-21, 07:53
	>  Вот кто тут значит настукивает и не скрываю. по-моему я всех предупредил. кто не внял - ССЗБ.
	Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимость в libssh, приводящая к переполнению буфера"	+7 +/–
Сообщение от Аноньимъ (ok), 28-Авг-21, 09:02
Обычно уязвимости приводят к взлому системы. А тут к переполнению буфера. А в старые добрые времена переполнение буфера приводило к уязвимостям, эх.
Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в libssh, приводящая к переполнению буфера"	+9 +/–
	Сообщение от Какаянахренразница (ok), 28-Авг-21, 20:50
	Убийство привело к смерти жертвы.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в libssh, приводящая к переполнению буфера"	–3 +/–
	Сообщение от Аноним (47), 28-Авг-21, 23:05
	> в старые добрые времена В школу собирайся, а не вспоминай про "старые добрые времена".
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	61. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от ptr128 (?), 30-Авг-21, 10:50
	Новость надо читать полностью, а не по диагонали. Так как в буфере размещается криптографический хеш, то, по определению, за обозримое время невозможно сделать его содержимое предсказуемым. Так как эта задача сведется к операции создания строки по хешу, что имеет слишком высокую вычислительную сложность.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от Аноним (10), 28-Авг-21, 09:33
Может просто указать размер буфера по максимально длинному хэшу в системе? Это самое простое и вообще не затратное решение, да и памяти экономит текущий способ максимум пару байт на ключ, что можно легко наверстать в другом месте.
Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимость в libssh, приводящая к переполнению буфера"	+3 +/–
	Сообщение от And (??), 28-Авг-21, 10:45
	А ещё можно просто проверять в коде поступающее снаружи. Аксиома со школы, но многих потом учат не делать проверок на годность данных и прочие проверки на ошибки в вводе со стороны/от пользователя. И привычка-то меняется в худшую сторону, инженегр деградирует.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимость в libssh, приводящая к переполнению буфера"	–8 +/–
	Сообщение от ыы (?), 28-Авг-21, 10:58
	Ну, вы если бы писали подобное, я уверен предприняли все необходимые проверки и защиты. К счастью вас не пускают к написанию такого кода. Почему к счастью? Потому что тогда вы бы были заняты делом, и не могли из-за нехватки времени общаться с нами тут...
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от Урри (ok), 28-Авг-21, 15:13
	Это на какой такой галере люди пашут 24\7?
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от пох. (?), 29-Авг-21, 00:15
	Ну что вы, что вы, хозяин добр - на большинстве галер рабы могут пару часиков поспать, поесть и поменять носки чтоб хозяину в нос не шибало.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от Аноним (16), 28-Авг-21, 11:23
	Не, не, не, ты что, нельзя так делать! Такие проверки лишние, они только жрут ценное процессорное время и оно может тормозить на каком-то говне мамонта. Поэтому и не включают всякие stack-protector. Достаточно заявы погромиста "мамой клянусь, тут все ок" и можно сразу в прод!
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	17. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от ыы (?), 28-Авг-21, 11:29
	Толи дело электрон.. вот в нем все хорошо... он просто не запускается на говне мамонта и можно делать все необходимые проверки...
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 28-Авг-21, 11:36
	А причем тут электрон? Вам религия не позволяет прописать нужные флаги при компиляции? Или ваш говнокод просто не скомпилируется с ними или будет падать на каждый чих?)) Или 1% производительности вам важнее безопасности?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимость в libssh, приводящая к переполнению буфера"	+3 +/–
	Сообщение от Аноним (-), 28-Авг-21, 12:07
	> Или 1% производительности вам важнее безопасности? Откуда такая большая цифра? На фоне подсчета самого хеша, проверка размера буфера и прочей обвязки теряются. Заметны будут (в большинстве случаев ненужные, но обычно все время педалируемые в качестве эталонного примера "жырножручести проверок" местными Ылитистами) проверки на выход за границу массива в циклах ...
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 28-Авг-21, 13:58
	Потому что писать меньше одного процента как-то некомильфо)) У этих ребят https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.186... просадка производительности вообще получилась на уровне погрешности измерений.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (52), 29-Авг-21, 06:24
	> А ещё можно просто проверять в коде поступающее снаружи. Во-первых ключ меняется самой библиотекой, а не "приходит снаружи". Но надеюсь вы хотя бы саму новость прочитали. Во-вторых не вижу никаких проблем выделять максимальное место для хэша сразу, вместо того чтобы (а) перевыделять память для одной и той же сущности на пару байт, (б) вообще иметь в этом случае дело с динамической памятью, когда речь идёт об одном слепке одного ключа, который в идеале в структуре должен находится как обычное число.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

20. "Уязвимость в libssh, приводящая к переполнению буфера"	–5 +/–
Сообщение от Аноним (20), 28-Авг-21, 12:19
Переполнения, переполнения, переполнения... Эээх! А ведь есть просто решение. Начинается на R, заканчивается на ust
Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от anonymous (??), 28-Авг-21, 12:42
	Так уже написаны библиотеки и на Rust. Просто тут речь про другую библиотеку. В общем, не очень понятно, что вы предлагаете.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в libssh, приводящая к переполнению буфера"	+5 +/–
	Сообщение от Гость (??), 28-Авг-21, 13:27
	Он предлагает всё везде заменить на раст. Не взирая ни на что. Любой ценой.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Аноним (29), 28-Авг-21, 16:15
	Но ведь раст в FF и Редох показал, что растаманы тоже ошибаются при проверке индексов массива и вылетают, текут, падают...
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от Аноним (20), 28-Авг-21, 17:01
	Лучше упасть на переполнении сразу, чем heartbleed
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от anonymous (??), 30-Авг-21, 11:44
	Он, вроде, такого не говорил. Этот риторический приём называется соломенное чучело.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	28. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Урри (ok), 28-Авг-21, 15:16
	LibSSH работает на всех (почти) платформах. Ваш любимый язык, к сожалению, покрывает только процентов 5 от нужного количества. Впрочем, никто не мешает вам взять, и переписать libssh на rust. Сделайте доброе дело.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	32. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Аноним (20), 28-Авг-21, 17:07
	А почему свет раста есть не на всех платформах? Ллвм разве не это самое?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от Аноним (16), 28-Авг-21, 17:36
	Конечно нет, llvm или сам тулчейн раста вполне может не поддерживать какую-то богом забытую маргинальную платформу из 90х, которую поддерживает CGG или какой-то другой компилятор, но "ЭТО ОЧЕНЬ ВАЖНО!!111" и используется как аргумент почему Си это тру, а раст это отстой.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от Аноним (36), 28-Авг-21, 18:53
	Одна архитектура, одна система, один владелец? Где-то я это уже слышал, не напомните?
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Аноним (16), 28-Авг-21, 20:18
	Хаха, щютка на уровне Петросяна. Впрочем... глупо было ожидать большего. Архитектур и платформ больше десятка, а на счет владельцев... напомните сколько владельцев у ядра линукса? То-то же...
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от Урри (ok), 29-Авг-21, 21:35
	Вы не видите разницы между "собирается" и "работает"? Сходите на https://doc.rust-lang.org/nightly/rustc/platform-support.html и посмотрите, что раст обещает работать(!) только на двух платформах 1) ARM64 (Linux), причем с ядром не ниже 4.2(!!), при этом винда под армы идет лесом. 2) х86/64 (Linux, Windows, macOS). Две. Архитектуры. А с учетом отсутствия поддержки винды для армов - вообще по честному полторы. При этом С покрывает (https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit... десятки архитектур. О чем еще можно тут говорить?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	63. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 12:08
	> что раст обещает работать(!) только на двух платформах 1. Это враньё, там куча поддерживаемых платформ. 2. Гарантированная работа тулзоф раста на платформе и вашей программы написанной на расте - разные вещи. > при этом винда > под армы идет лесом Опять враньё aarch64-pc-windows-msvc Поддерживаемая платформа с гарантированным бинарными релизами и тестами. > Две. Архитектуры. А с учетом отсутствия поддержки винды для армов - вообще > по честному полторы. Наглая безумная иступлённая ложь. > При этом С покрывает (https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit... > десятки архитектур. О чем еще можно тут говорить? Только кроссплатформенность сишки миф. Для каждой платформы нужно писать специфический код и строить замки из ифов в системе сборки, которая частью компилятора не является, как и система отладки, которая на разных платформах разная. Ну и Вишенка на торте из ваших экскрементов: https://gcc.gnu.org/install/binaries.html >Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers. Тоесть тир 1 и 2 в gcc отсутствует как явление.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от Урри (ok), 30-Авг-21, 13:32
	> Это враньё, там куча поддерживаемых платформ. Понятно. Значит разницы между "работать" и "компилироваться" растишечка таки не видит. Ну кто бы удивлялся. А по-английски наш маленький растик уже умеет читать, или в школе еще нету уроков английского? Сможет понять разницу между tier 1) - automated testing ensures that each tier 1 target builds and passes tests after each change. и tier 2) - automated tests are not always run so it's NOT GUARANTEED to produce a working build или не сможет? > Наглая безумная иступлённая ложь. "Аааааа, мама, меня обидели! Так не может быть! Я не вееееееееерю!" Иди поплачь, может полегчает. > Только кроссплатформенность сишки миф. Муа-ха-ха-ха-ха-ха. Эй, Линус, Майкрософт, Амуде, Ленова, и еще более 20 тысяч компаний разного размера, и не знаю сколько инди девов - тут какой-то да***йоп утверждает, что ваш миллиард строк (даже чуть больше) ни разу не собирается под почти все существующие платформы с помощью gcc и не работает на ойой скольки миллиардах устройств по всему миру. Анонимы опеннета пробивают новые днища. Надо себе в закладки этот комментарий добавить. Буду коллег смешить по пятницам.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 30-Авг-21, 16:03
	> или не сможет? Именно что ты не можешь. Потом что для GCC написано то же самое. secondary platforms are:     The compiler bootstraps successfully, and the C++ runtime library builds.     The DejaGNU testsuite has been run, and a substantial majority of the tests pass. На вторичных платформах оно должно просто скомпилиться и пройти некий majority тестов. И все. Насколько ответственно. Потому что это тоже не ГАРАНТИРУЕТ что оно работает. Более того, это даже может быть знаком что проблема есть. Удивительно что ты это не знаешь. Оказывается сишники тоже не видят разницу между работать и пройти только часть тестов. В расте "automated tests are not always run" ("автоматические тесты не всегда запускаются") это проблема, а у божественного гцц - "мы допускаем что не все тесты пройдут" - это все норм, упавшим тестом больше, упавшим тестом меньше, работаем дальше. Ваше двоемыслие начинает утомлять. > Буду коллег смешить по пятницам. В перерывах между исправлениями double free?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Урри (ok), 30-Авг-21, 18:39
	Растообиженка вертится как угорь на сковороде. Приятно посмотреть.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 30-Авг-21, 19:09
	Ахаха, ну ты даешь)) Ты вкинул в тему цифру про пять процентов и ушел от ответа с просьбой перечислитью их. Ты налажал с двумя платформами потому что не отличает работу компилятора и от работы тулзов. Ты слился когда тебе указали что в гцц поддержка тиер2 аналогичная. А теперь все что ты можешь сказать "растообиженка вертится как угорь"? Серьезно? Это самый отстойный слив за последний месяц!
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Урри (ok), 30-Авг-21, 19:30
	> Ты вкинул в тему цифру про пять процентов и ушел от ответа с просьбой перечислитью их. ?? где просьба? Ну и кроме того - что, своих мозгов не хватает по картинке оценить? > Ты налажал с двумя платформами потому что не отличает работу компилятора и от работы тулзов. Я уже исправился - не две, а полторы. Прошу запротоколировать. > Ты слился когда тебе указали что в гцц поддержка тиер2 аналогичная. Ээээ. Не видел у gcc никаких tier - ни 1, ни 2. Можно тыкнуть прямой ссылкой на https://gcc.gnu.org/ ? > А теперь все что ты можешь сказать "растообиженка вертится как угорь"? Серьезно? Да. А ты предлагаешь мне вот эту написанную чушь на серьезных щах разбирать? > Это самый отстойный слив за последний месяц! Самый банальный способ разрешить когнитивный диссонанс - заявить "это не я тупой, это все вокруг дураки".
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 30-Авг-21, 19:45
	> где просьба? >> "что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%?" к твоему сообщение написан текст и там даже знак вопроса... что же это может быть? или ты ожидал что-то вроде "Уважаемый Урри, не могли бы Вы сообщить значимый источник данного утверждения?" > Ээээ. Не видел у gcc никаких https://gcc.gnu.org/gcc-11/criteria.html "We have classified these platforms into three categories: primary, secondary, and tertiary" > "это не я тупой, это все вокруг дураки". Так ты с похом (при условии что это разные люди) всю тему этим занимаетесь.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Урри (ok), 30-Авг-21, 20:02
	> >> "что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%?" Ааааа. Да все, что не 5%. Начиная с iot, пробегая через мобильные девайсы и заканчивая мейнфреймами. Я думал это шутка такая, а это действительно был вопрос? Пххххх. > "We have classified these platforms into three categories: primary, secondary, and tertiary" А, ну ок. Пускай это будет некий аналог "tier". Тогда в tier1 входит девять платформ, а не две. > Так ты с похом (при условии что это разные люди) всю тему этим занимаетесь. Разные, не сомневайся. Мы с ним недавно неплохо так поср.. поспорили.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 18:22
	>что ваш миллиард строк (даже чуть больше) ни разу не собирается под почти все существующие платформы с помощью gcc и не работает на ойой скольки миллиардах устройств по всему миру. Внезапно да, на одной конкретной платформе не собирается миллиард строк кода от всех других платформ. И уж точно на роутере у меня всего этого кола нет, как и процентов 80-90 всего вообще ПО невозможно под него собрать.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	77. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Урри (ok), 30-Авг-21, 18:37
	И что же у вас за платформа такая?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 31-Авг-21, 00:17
	> И что же у вас за платформа такая? Хайку ос на эльбрусе!
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 18:29
	>Понятно. Значит разницы между Я то разницу вижу. А вот вы подменяете понятия, тир 2 это то же поддержка. Ит то, что гарантий не дают, не означает что оно не работает. Вас сейчас за руку словили как дебильного ребёнка, на глупой лжи, а вы вместо извинений права качаете, мол тупой Аноним не понимает ваши стройные остроумные приёмы недобросовестного диалога.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	76. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от Урри (ok), 30-Авг-21, 18:36
	> Ит то, что гарантий не дают, не означает что оно не работает. Че, реально? А-ха-ха-ха-ха-ха. Впрочем... не хотите купить у меня программу, которая создает идеальные бекапы - ничто и никогда у вас не потеряется, я гар... не, не гарантирую. Но то, что я это не гарантирую, ведь не значит, что оно не работает? > вы вместо извинений права качаете, мол тупой Аноним не понимает ваши стройные остроумные приёмы недобросовестного диалога. Цитировать источник - это "остроумный приём недобросовестного диалога"? И вы действительно настолько тупой, что не понимаете тех элементарных вещей, о которых я вам пишу? Ну нет, так нет. Примите мои глубочайшие извинения.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от Аноним (16), 28-Авг-21, 17:49
	Да ну, аж интересно что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%? Заодно и с пруфцами что LibSSH  там есть. А то цифра звучит... ну скажем взятой с потолка)) Список поддерживаемыъ платформ можно увидеть тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	38. "Уязвимость в libssh, приводящая к переполнению буфера"	–4 +/–
	Сообщение от пох. (?), 28-Авг-21, 20:23
	Для хрустобоя все что не поддерживается - неважное и незначимое. > Список поддерживаемыъ платформ можно увидеть тут https://doc.rust-lang.org/nightly/rustc/platform-support.html ожидание - список на пару страниц. Реальность: в tier1 восемь строчек. Винда, винда, винда и винда. 64 bit only. И еще, вот, нате-подавитесь - линoops и максось. В единственно-верных позах. Нда, с другой стороны - а чего еще от макак ждать... Про tier2 не будем - мне ваши "guaranteed to build" нафиг не упали. ЭТУ гарантию обеспечивает llvm, угу. А вот что _ваша_ поделка что-то там build после этого, а не "такая херня, такая херня получается" - никто, похоже, не гарантирует вовсе. Разумеется это то что нужно для low-footprint библиотечки собирающейся везде где вообще есть поддержка posix.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 28-Авг-21, 21:03
	> Win 64 bit only. Разумеется, потому что 32бит в тиер2. Мамонтам там и место - последний интеловый 32bit only проц вышел 10 лет назад (атом), а последний нормальный десктопный - в далеком 2006. Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно. > нате-подавитесь - линoops и максось. В tier1 линуксов всего на один меньше чем вариантов винды - 4 vs 3. Так что мимо. Столько буков написал, а ни одной значимой архитектуры так и назвал. А теперь глянем на божественный ГЦЦ. https://gcc.gnu.org/gcc-11/criteria.html Primary Platform List. "ожидание - список на пару страниц", реальность: линь, линь, бздя, линь, мипсы, линь, линь, солярка, линь... Очень разнообразно однако. Ни макоси, ни винды. Печалька. Secondary Platform List: о, надо же, макось и винду добавили. А где андроид, где ios? Хотя бы на уровне "guaranteed to build"? Слабенько как-то.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в libssh, приводящая к переполнению буфера"	+2 +/–
	Сообщение от Бздун (?), 28-Авг-21, 21:32
	> i586-unknown-freebsd > бздя Даже в консервативной фре - ожидаемый по умолчанию класс ЦПУ теперь i686 и вообще, x86 перевели в Tier2.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от пох. (?), 28-Авг-21, 21:55
	Но 3d-party си-компилятор для нее, как видишь - пока еще не сломали. Потому что без него не будет ничего работать вообще, кроме голой фри, которая никому не нужна ни на 586, ни на чем другом.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от пох. (?), 28-Авг-21, 21:53
	> Мамонтам там и место значит хрустикам вскоре найдется место на помойке - вместе с модными еще в прошлом году штанами от усраччи. > Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно. не найдется - ваш хруст не нужен никому кроме ошпаренных макак, любителей свежайшего. А те не умеют в долгосрочные сложные проекты, если их не финансирует гугль, или, например, гугль. И это в общем-то хорошо. Очередная антитехнология далеко не уйдет с винды, винды, винды, и винды. > https://gcc.gnu.org/gcc-11/criteria.html а вот это, чувак, не "кое-как собирается сам бинарник". Это проходят тесты DejaGNU - гарантирующие не сборку бесполезного компилятора, а то что этот компилятор хотя бы периодически после этого компилит работающий на этой платформе код - причем всеми своими фронтендами. Для начала - на этой платформе они вообще должны работать, что не очень просто, операционная система нужна (а не ведроид). При том что это gcc11, то есть снова нечто уже маловостребованное за пределами линoops под единственноверную архитектуру из-за троянцев в механизме. К счастью, libssh пока вроде не требует для своей сборки моднейших версий компилятора - соберется и устаревшей на десять лет. > Ни макоси, ни винды. Печалька. диствительна. У них ведь, бедолажек, нет своего си компилятора? А вот своего хруста, не завязанного на llvm единственноправильной версии - действительно нет и не будет никогда и нигде. Т.е. его не будет никогда и нигде кроме платформ, куда эппл захочет спортировать свой код, и при этом еще сами хрустики осилят на него портироваться. Закапывайте...
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	46. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (16), 28-Авг-21, 22:31
	> если их не финансирует гугль, или, например, гугль. > не уйдет с винды, винды, винды, и винды. Э... гугль или гугль? Винды и винды? Дед, ты опять забыл таблетки выпить? Но дело в том что их и так финансирует гугл. В Rust Foundation - как раз google, facebook, microsoft, aws, huawei, а в спонсорах - arm, github и еще кто-то. Т.е. те же самые google, facebook, microsoft, huawei которые являются Platinum и Gold members в Linux Foundation))) Так что можешь не беспокоиться.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в libssh, приводящая к переполнению буфера"	–3 +/–
	Сообщение от пох. (?), 29-Авг-21, 00:13
	> Но дело в том что их и так финансирует гугл. ну так под платформы, одобряемые гуглем (и да, это винда - ему же нужно чтоб у раба все работало и на десктопе тоже) - оно и будет работать. Вот те пять штук из списка. А солярисы эти ваши - пустое, как и 32битные системы. Их гугль оплачивать не планирует, и там ничего работать не будет. И тем более не будет во всякой мелкой фигне, для которой подобные библиотеки и актуальны. Одно радует - гугль похоронил уже великое множество прожектов, так что и этому рано или поздно крышка.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от нах.. (?), 29-Авг-21, 21:09
	> Разумеется, потому что 32бит в тиер2. Мамонтам там и место - последний интеловый 32bit only проц вышел 10 лет назад (атом), а последний нормальный десктопный - в далеком 2006. Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно. Да вы профи. А ну брысь в школу, каникулы уже кончились.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	64. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 12:13
	https://gcc.gnu.org/install/binaries.html >Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers. У GCC нет тир 1 и 2 как явления.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	65. "Уязвимость в libssh, приводящая к переполнению буфера"	–2 +/–
	Сообщение от пох. (?), 30-Авг-21, 12:18
	бть... какие ж вы все же ди-лы... У gcc есть tier1 и 2. Как раз тем и отличаются, что одно тестируют, а другое - собралось, ну уже хорошо. Но он не распространяется в бинарниках, как и _любой_ gnu софт - ждите, д-лы. gnu распространяется своими разработчиками в виде исходников. Традиция тех времен, когда их принято было собирать у себя и для себя. Придут добрые дяденьки и за вас все соберут, только к проекту они не имеют никакого отношения. Может даже тесты запустят, прежде чем вам эту сборку вывалить на лопате. А может нет, вы ж д-лы, вы и так схаваете.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 12:27
	Это прекрасно. Я прямо заворожен и лишился слов. Так вот. Это не то, что под тир 1 подразумевается обычно.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость в libssh, приводящая к переполнению буфера"	+1 +/–
	Сообщение от пох. (?), 30-Авг-21, 13:20
	кем "подразумевается" - хрустиками? Вы и из этого новую религию сделали? P.S. еще вон у freebsd tier'ы есть. И снова это ничуть не про бинарники.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноньимъ (ok), 30-Авг-21, 18:58
	>P.S. еще вон у freebsd tier'ы есть. И снова это ничуть не про бинарники. Ну и зачем вы так с разбегу в лужу садитесь сразу? https://docs.freebsd.org/en/articles/committers-guide/#archs >The FreeBSD Project provides the following guarantees to consumers of Tier 1 platforms: >Official FreeBSD release images will be provided by the release engineering team. >Binary updates and source patches for Security Advisories and Errata Notices will be provided for supported releases. >Binary updates and source patches for cross-platform Security Advisories will typically be provided at the time of the announcement. >Official binary packages for third party software will be provided by the ports team. For embedded architectures, these packages may be cross-built from a different architecture. Да конечно, бинарники необязательны, однако, тяжело обеспечить *первоклассную поддержку* когда нет официальных бинарников на которые можно ссылаться в саппорте/багрепорте. Как-то в целом не очень первоклассно получается когда для первого класса нет официально собранных бинарников. Проект GNU в первую очередь предоставляет поддержку свободы предоставляемого софта, это то-же нужно понимать, и только во вторую очередь всех остальных качеств.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от Урри (ok), 30-Авг-21, 13:34
	пох, ты конечно идиот. Но здесь отлично выступил. Зацени как у народца подгорает-то, что их любимый растик полторы платформы всего поддерживает.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	73. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (20), 30-Авг-21, 17:57
	Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и арм? Лигаси платформы не нужны, потому что кто под них будет переписывать? Надо новый код писать. А какой-нибудь авз микроконтроллер можно и на Си делать, там всё-таки проги должны быть маленькими и с памятью штык в штык работать (хотя кто-то вроде и Раст на микроконтроллеры запихивает).
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимость в libssh, приводящая к переполнению буфера"	–1 +/–
	Сообщение от Урри (ok), 30-Авг-21, 18:51
	> Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и > арм? Растишечным хелловорлдам, действительно, и одного windows/x86_64 хватать должно. Даже не могу поспорить, все так.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (20), 31-Авг-21, 03:12
	А не хелловордам? Ну хоть одна платформа не лигаси и не нишевая есть?
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (53), 29-Авг-21, 09:52
	В продакшн версиях приложений на расте нет никаких проверок переполнения.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	60. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (20), 30-Авг-21, 02:04
	Откуда инфа? В расте вроде проверки никто вменяемый не выключает в сейф коде
	Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от Аноним (-), 28-Авг-21, 21:23
Переполненые буфера - это прекрасно!
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от СССР (?), 28-Авг-21, 23:14
а кто юзал полноценно и libssh b libssh2? Первый я покурил хорошо, написал класс для работы с pty, реализовал sudo -u ser -i. В целом достаточно удобно. Единственное пришлось подумать как фиксировать конец потока, sleep не вариант ) пока не нулевая длинна блока тоже. Но там есть калбэки, возможно они вызываются когда происходит реальный конец вывода. На libssh2 затэстил простой пример но не через pty. по факту что интереснее не сравнивал. У кого есть опыт с либами?
Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (56), 29-Авг-21, 20:03
	Расскажите, как ограничить возможность их использования в системе по максимуму, если их удалить нельзя, так как другие программы не работают без них.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от BorichL (ok), 30-Авг-21, 14:46
	Вероятно, пора перевестись в класс умственно отсталых по информатике и ВТ.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от СССР (?), 31-Авг-21, 00:09
	> Расскажите, как ограничить возможность их использования в системе по максимуму, если их > удалить нельзя, так как другие программы не работают без них. Не совсем понимаю вопрос. вам для чего их удалять? Просто отключите сервис в системе и будет вам счастье.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

49. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от СССР (?), 28-Авг-21, 23:18
"В качестве запасного метода защиты можно ограничить список поддерживаемых методов обмена ключами только алгоритмами с одинаковым размером хэша" -  это же для решения проблем на сервере?
Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
	Сообщение от Аноним (53), 29-Авг-21, 09:52
	Можно перейти на telnet внутри vpn
	Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимость в libssh, приводящая к переполнению буфера"	+/–
Сообщение от Аноним (-), 03-Сен-21, 07:39
> операция смены ключа допускает применение криптографических > хэшей с размером слепка, отличающимся от первоначально использованного алгоритма Кто вообще придумал такое переобувание в полете?
Ответить | Правка | Наверх | Cообщить модератору

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

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