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

"Уязвимость в zlib, проявляющаяся при сжатии специально оформленных данных"	+/–
Сообщение от opennews (ok), 27-Мрт-22, 13:32
В библиотеке zlib выявлена уязвимость (CVE-2018-25032), приводящая к переполнению буфера при попытке сжатия специально подготовленной последовательности символов во входящих данных. В текущем виде исследователями продемонстрирована возможность вызова аварийного завершения процесса. Может ли проблема иметь более серьёзные последствия ещё не изучено... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56918
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
Сообщение от _kusb (ok), 27-Мрт-22, 13:32
Как же одинаковы все эти уязвимости.
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
Сообщение от васёк (?), 27-Мрт-22, 13:39
спасите мои gz архивы 😱
Ответить | Правка | Наверх | Cообщить модератору

	5. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–3 +/–
	Сообщение от timur.davletshin (ok), 27-Мрт-22, 13:50
	Разве оно не используется прямо тут, на opennet? Судя по заголовку, тут трафик gzip жмётся.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Ан2 (?), 27-Мрт-22, 14:05
	gzip - это не zlib.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–5 +/–
	Сообщение от timur.davletshin (ok), 27-Мрт-22, 14:13
	> gzip - это не zlib Ну, для начала, не я про gzip сказал. Я же ни слова про zlib не говорил.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (12), 27-Мрт-22, 14:14
	Zlib это опенсорс реализация deflate, всё, что не zlib -- часто копия/форк. Тот же zip это (среди прочего) формат архива, использующий этот самый deflate (по появился он до png и zlib). А Gzip это не архив.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	16. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от timur.davletshin (ok), 27-Мрт-22, 14:36
	Всё это конечно классно и правильно, что ты сказал. Но я советую всё же распаковать исходники Firefox и поискать там файлик deflate.c, который и надо в основном пропатчить.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+8 +/–
	Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 15:03
	> советую всё же распаковать Давно не встречал такого филигранно тонкого троллинга.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–1 +/–
Сообщение от Аноним (12), 27-Мрт-22, 13:42
Мне интересно, как они получили эту последовательность? А вообще, выглядит довольно опасно, такая уязвимость может быть куда серьёзнее уязвимости в openssl и всего-то надо подставить строку текста под сжатие.
Ответить | Правка | Наверх | Cообщить модератору

	6. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+5 +/–
	Сообщение от Аноним (6), 27-Мрт-22, 13:50
	У чувака программа падала при сжатии. Он начал копать и определил, что причина в zlib. А потом и последовательность для повторения бага подобрал.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Jajauma (?), 27-Мрт-22, 14:13
	Адлер сказал да ладно я всё решу(R) и уязвимость фигня https://github.com/madler/zlib/issues/605#issuecomment-10798...
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

4. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
Сообщение от Аноним (4), 27-Мрт-22, 13:43
> патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него внимания Опять... 🤦
Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–1 +/–
	Сообщение от Аноним (13), 27-Мрт-22, 14:28
	Опен сорс пауер во всей красе.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (63), 28-Мрт-22, 16:20
	Лицензия AS IS наше всё.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+8 +/–
	Сообщение от КО (?), 27-Мрт-22, 16:09
	Современным хакерам даже не нужно ничего придумывать, все в закрытых/висящих issue.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	31. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+3 +/–
	Сообщение от Kuromi (ok), 27-Мрт-22, 17:07
	Поэтому и появляются вот эти громкие заголовки, только на хайпе можно заставить разработчика пофиксить проблему которая в обычных условиях признается "слишком редкой, мудреной и сложной в применении"
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	69. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от adolfus (ok), 31-Мрт-22, 11:45
	Из таких проблем и состоит, например, libreoffice. Правда только на треть, у второй трети ноги растут из xml, а у третьей -- из использования ООП-наследования.
	Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
Сообщение от commiethebeastie (ok), 27-Мрт-22, 14:07
Так это сразу куча серверов под удар попадают.
Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (39), 27-Мрт-22, 23:29
	Осталось подсунуть файл на сервер и заставить его сжимать...
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (6), 28-Мрт-22, 09:26
	> Осталось подсунуть файл на сервер и заставить его сжимать... Любой web-сервер по дефолту начнёт сжимать что укажешь. https://en.wikipedia.org/wiki/HTTP_compression Или волшебную последовательность можно отправить в любую форму на сайте и СУБД сожмёт их при сохранении, или прислать в числе изменений для Git.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Kuromi (ok), 31-Мрт-22, 20:31
	Не факт, иногда серверу надо явно включать модули сжатия. Опять же есть более новые методы, тот же brotli
	Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
Сообщение от Аноним (14), 27-Мрт-22, 14:28
Переполнение буфера, классика
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–4 +/–
Сообщение от Аноним (15), 27-Мрт-22, 14:31
Ну и как обычно, Rust реализация неуязвима https://github.com/Frommi/miniz_oxide
Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+4 +/–
	Сообщение от Аноним (22), 27-Мрт-22, 15:26
	Сегфолта может и не будет, но поток же будет повреждён? Windows 10 тоже до сих пор extended разделы портит, если в самом начале EBR встречается дырка. Толку с того, что diskpart не упал, потом все равно ковыряться в hex-редакторе и вручную править смещения для EBR. Хоть на C, хоть на C#, хоть на javascript пиши...
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–1 +/–
	Сообщение от Kusb (?), 27-Мрт-22, 18:04
	Haiku что-то нехорошее делает с разделами, причём по моему даже если другие были подключены только для чтения.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от morphe (?), 29-Мрт-22, 16:17
	> Сегфолта может и не будет, но поток же будет повреждён? Переполнение буфера выльется либо в панику (если код не обрабатвает его, проверить можно через инструменты для запрета паник https://docs.rs/no-panic), либо в ошибку Молча проглотить в Rust будет сложно Я посмотрел - компрессор статичных блоков везде переполнения переводит в ошибки https://github.com/Frommi/miniz_oxide/blob/991e3154b49e56cf7...
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	67. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от morphe (?), 29-Мрт-22, 19:30
	Ну и пример из уязвимости корректно обрабатывает
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–3 +/–
	Сообщение от Аноним (27), 27-Мрт-22, 16:21
	А чего же там 68% кода на некошерной Сишке? C 68.4% Rust 26.4% C++ 4.9% Shell 0.3%
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	30. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от Аноним (39), 27-Мрт-22, 16:57
	Как обычно, взяли сишный код, обернули слоем раста...
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (37), 27-Мрт-22, 21:34
	>> Pure rust Rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code >> This project is organized into a C API shell and a rust crate. >> The C API is intented to replicate the api exported from miniz, and in turn also part of zlib. > Как обычно, взяли сишный код, обернули слоем раста... Как обычно, опеннетные эксперты сморозили глупость, ведь сделали там обертку для сишного кода. Но ЖСники и прочие питонисты опеннета в таких деталях не разбираются, они видят знакомые слова и сразу идут в газовую атаку ...
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-22, 18:18
	> А чего же там 68% кода на некошерной Сишке? > C 68.4% > Rust 26.4% > C++ 4.9% > Shell 0.3% С того, что как истинный Опеннетный Воен Супротив Раста - читал опой? > miniz_oxide_C_API > The C API is intented to replicate the api exported from miniz, and in turn also part of zlib. > The C header is generated using cbindgen ... > the miniz C code used for tests ... > or to compare to miniz > $ ./travis-after-success.sh
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	45. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–3 +/–
	Сообщение от Аноним (45), 28-Мрт-22, 09:06
	Чтож этот суперский раст не может сам себя протестировать. Это просто ор.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+2 +/–
	Сообщение от Аноним (50), 28-Мрт-22, 11:23
	>> Pure rust Rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code. >> The C API is intented to replicate the api exported from miniz, > Чтож этот суперский раст не может сам себя протестировать. Для неумеющих в английский, переведу: оно написано как замена miniz. А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней? > Это просто ор. С опеннетовского воинствующего ламерья ...
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (54), 28-Мрт-22, 13:56
	> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней? Какая же каша в голове. В таких случаях пишутся заглушки которые обрабатывают запросы. Использовать реальную библиотеку? Какой версии? Для какой архитектуры? В каком окружении? С какими параметрами собранную?
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (55), 28-Мрт-22, 14:27
	>> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней? > Какая же каша в голове. Какой же юлеж у Военов, которые опять не потрудились глянуть в сорцы, зато готовы заглушками в либе тестировать совместимость, ага. > В таких случаях пишутся заглушки которые обрабатывают запросы. Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (54), 28-Мрт-22, 16:15
	> Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ... То есть тестироваться будет на одной архитектуре с одним набором окружения и одним набором параметров сборки. Красавцы! У вас все так? Или только это?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (-), 28-Мрт-22, 17:29
	> То есть тестироваться будет на одной архитектуре с одним набором окружения и > одним набором параметров сборки. Т.е., если бы Воен соизволил заглянуть дальше заголока, то знал бы, что тестироваться будет точно так же, как и miniz. > Красавцы! > У вас все так? Или только это? У кого "у вас" и кто вообще "вы", Воены-Знатоки?
	Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 15:00
Хммм... а ведь я не очень давно поимел странный эпизод, когда у меня почему-то при распаковке архива распаковалась только часть одного из файлов. Полдня угробил в поисках ошибки у себя, прежде чем догадался сделать просто tail и увидел, что файл битый. Не удивлюсь, если и в распаковщике какая-нибудь фигня обнаружится. Воспроизвести не удалось.
Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Аноним (12), 27-Мрт-22, 15:46
	Почему-то? Как можно не проверять код завершения? Я только вчера столкнулся (впервые на самом деле), что все архивы с пикабу выдают такую ошибку: error: invalid zip file with overlapped components (possible zip bomb) Error: extraction wasn't successfull Распаковался только 100гб архив. Но я проверял код завершения, поэтому rm -rf /* не случился (и да, там много rm-rf в инструкциях, это удобно).
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 16:08
	Там унзип в пайп пихал, там скрипт не ждал кода завершения.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (12), 27-Мрт-22, 16:22
	Звучит достаточно ненадёжно, большая часть zip архивов идёт в неправильной кодировке. Стримить можно только данные, которые пожаты потоковым компрессором. Но и в таком случае есть всякие set -o pipefail и shopt -s inherit_errexit.
	Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
Сообщение от Gedweb (ok), 27-Мрт-22, 15:01
Произошла чудовищная ошибка! Подобная уязвимость в любимом языке stackoverflow заняла бы 10 экарнов коментов
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
Сообщение от Аноним (22), 27-Мрт-22, 15:16
Это фиаско, такого от древнего и изученного алгоритма не ожидаешь!
Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+4 +/–
	Сообщение от Аноним (38), 27-Мрт-22, 21:57
	проблема в реализации, а не алоритме
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от Аноним (39), 28-Мрт-22, 00:46
	реализация и есть своего рода алгоритм.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Брат Анон (ok), 28-Мрт-22, 07:56
	Вы путаете понятие "программирование" и "кодинг". Алгоритм стоит уровнем выше реализации. Реализации может не быть, а алгоритм будет. Реализаций может быть несколько, а алгоритм один. И проблема здесь -- в дырявом Си и псевдобезопасном Расте, который дырявость Си заметает под ковёр ансейва. Самое плохое решение -- делать вид, что ты умный и красивый таковым не являясь. Го в этом смысле -- гораздо честнее. Старается не лезть в Си и не обещает того, что невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–1 +/–
	Сообщение от Аноним (45), 28-Мрт-22, 09:08
	Сказал А говори Б. Го это второй божественный раст.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+2 +/–
	Сообщение от PnD (??), 28-Мрт-22, 11:04
	Тогда уж java. После лечебного голодания и трудотерапии. * Я ещё помню флэш-моб времён фидонета "перепишем всё с C на Java". И "java-процессоры" (там до 2010 движ продолжался и даже остался кое-какой выхлоп в виде "продвинутого" сборщика мусора). История повторяется через ≈25 лет. Но, похоже что в виде фарса. Ресурсов нету на новый банкет.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от burjui (ok), 28-Мрт-22, 14:46
	Вот чего у растохейтеров не отнять, так это умение приплести Rust к любой теме.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	57. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от burjui (ok), 28-Мрт-22, 14:58
	И да, unsafe (читается "ансейф") - не для заметания под ковёр, а для локализации небезопасных операций, которые всё равно неизбежны. Просто когда нужно убедиться в корректности реализации, в Rust ты вручную проверяешь только блоки unsafe, а в C - весь код. И ничего невозможного Rust не обещает, в документации прямо сказано, что безопасность работы с памятью гарантирована только для той части кода, которая не обёрнута в unsafe. В типичном проекте на Rust это 100% кода, потому что unsafe нужен крайне редко для нетривиальных вещей. Короче, RTFM нубы, надоело уже читать ваш straw man бред.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	58. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Брат Анон (ok), 28-Мрт-22, 15:42
	> Короче, RTFM нубы, надоело уже читать ваш straw man бред. Угу. Ждём дыру в компиляторе, связанную с концепцией владения и гонкой данных. Всё впереди.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от burjui (ok), 28-Мрт-22, 16:12
	Баги есть в любом ПО. Давайте не будем писать на C тогда, а то вдруг компилятор сгенерит некорректный машинный код.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от burjui (ok), 28-Мрт-22, 16:13
	А чего мелочиться, давайте не использовать ПО вообще.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	62. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
	Сообщение от Аноним (63), 28-Мрт-22, 16:15
	Просто ты недалекий пыхер. Твой уровень интеллекта это максимум «не использовать ПО ваще». Мне тебя жалко.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	–2 +/–
	Сообщение от burjui (ok), 28-Мрт-22, 16:51
	Пожалей лучше себя. И при чём тут вообще "пыхер"?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от morphe (?), 29-Мрт-22, 19:39
	Такие есть и были, но это именно что баги, которые со временем пофиксят, и которые не проявляются при нормальных условиях Баги в borrow чекере позволяют лишь писать некорректный код, но сами по себе баги в коде не создают, т.к borrow checker не влияет на поведение В данный момент есть 2 давно живущих такие баги: https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/85099 (Не совсем в borrow checkerе, но близко)
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	71. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Andrew (??), 01-Апр-22, 13:04
	...в unsafe требуется оборачивать даже разыменовывание указателя - эта операция требуется в любой производительной современной программе, чуть сложнее "привет мир". Я как только это увидел, сразу закинул Rust за шкаф, и продолжил дальше на Go.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	72. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от burjui (ok), 01-Апр-22, 19:34
	Вот мне всегда было интересно: каково это - быть упёртым хейтером. Наверное, это сродни религии. Ссылки в Rust - это просто указатели, для которых компилятором даются определённые СТАТИЧЕСКИЕ гарантии (во время компиляции). Разыменование ссылки, явное или неявное (скажем, через вызов метода) - то же самое, что и разыменование указателя. Скептикам - rust.godbolt.org в помощь: pub fn add1(num: &i32) -> i32 {     *num + 1 } Добавляем флаг -C opt-level=1 (самый слабый уровень оптимизаций) и видим: example::add1:         mov     eax, dword ptr [rdi]         add     eax, 1         ret Ну как, достаточно производительно? Оптимизации, если что - для краткости листинга. Без оптимизаций (-C opt-level=0) разыменование будет точно такое же, только будет добавлена обработка переполнения при сложении: example::add1:         push    rax         mov     eax, dword ptr [rdi]         inc     eax         mov     dword ptr [rsp + 4], eax         seto    al         test    al, 1         jne     .LBB0_2         mov     eax, dword ptr [rsp + 4]         pop     rcx         ret .LBB0_2:         lea     rdi, [rip + str.0]         lea     rdx, [rip + .L__unnamed_1]         mov     rax, qword ptr [rip + core::panicking::panic@GOTPCREL]         mov     esi, 28         call    rax         ud2 .L__unnamed_1:         .quad   .L__unnamed_2         .asciz  "\017\000\000\000\000\000\000\000\002\000\000\000\005\000\000" str.0:         .ascii  "attempt to add with overflow" А сырыми или "сишными" указателями приходится пользоваться КРАЙНЕ редко - скажем, для реализации умных указателей и тому подобных трюков. То есть, практически никогда, если вы не разработчик оных или просто любитель заниматься преждевременными "оптимизациями", если это можно так назвать, учитывая отсутствие практической разницы между сырыми указателями и идиоматическими ссылками. Но вы и дальше продолжайте собирать мусор на Go и считать, что что-то выиграли. В конечном итоге, с вашим походом к изучению документации и компитятора, ваши знания о Go будут столь же скудны и бесполезны, как и ваши знания о Rust, C и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+/–
	Сообщение от Andrew (??), 03-Апр-22, 20:03
	Да кому нужно голову морочать с Rust, тратить в 3-5 раз больше времени на язык, который ржавчиной обозвали и сделали в нем синтаксис еще хуже чем в птичьем языке, когда в Go есть всё что надо и указатели нормальные, и они работают как указатели. И В Go наверное уже лучший сборщик мусора в мире среди всех языков. Ваш пример с ассемблером в основной массе никому не нужен, даже для драйверов уже не нужен почти нигде, это удел гиков.
	Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+1 +/–
Сообщение от test (??), 28-Мрт-22, 10:34
А это точно не на бекдоор наткнулись ? Сложно представить последовательность влияющую на это.
Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."	+2 +/–
	Сообщение от Аноним (63), 28-Мрт-22, 12:03
	Конечно же нет такого не может быть. Это фантастика. Ты разве когда-нибудь видел чтобы бекдоры вставляли специально. Бред какой-то.  Ты смотришь неправильные ТВ каналы, тебя там наймиты зазомбировали. Начиная с этой строчки ты забудешь что такое бекдоры и что они вообще существуют.
	Ответить | Правка | Наверх | Cообщить модератору

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

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