The OpenNET Project / Index page

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

Уязвимость в приложениях на базе HTTP-библиотеки Hyper

06.01.2023 20:48

В библиотеке Hyper, предлагающей реализацию протоколов HTTP/1 и HTTP/2 на языке Rust, имеется особенность работы с памятью, которая при использовании в приложениях без учёта рекомендаций из документации, может привести к появлению уязвимостей, дающих возможность вызвать отказ в обслуживании (исчерпание доступной процессу памяти) через отправку специально оформленного HTTP-запроса уязвимому обработчику. Библиотека достаточно популярна (67 млн загрузок) и используется в качестве зависимости у 2579 проектов, представленных в каталоге crates.io.

Причиной появления уязвимостей является отсутствие ограничений на размер ресурсов, передаваемых в HTTP-запросах и ответах. В библиотеке Hyper для копирования запроса или тела ответа предлагается функция body::to_bytes, копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данных. Соответственно, атака сводится к передаче очень большого запроса или ответа, обработка которого приведёт к выделению буфера, не вмещающегося в доступную память. Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера, но предупреждение игнорировалось в различных продуктах, использующих Hyper (например, проблема всплыла в проектах Axum, Salvo и conduit-hyper).

В реальных условиях для атаки нет необходимости отправлять большой объём данных - так как при обработке chunked-запросов буфер выделяется на основе информации в заголовке Content-Length, для выделения большого блока памяти или аварийного завершения процесса достаточно отправить начальный пакет с большим значением в Content-Length.

  1. Главная ссылка к новости (https://jfrog.com/blog/watch-o...)
  2. OpenNews: Уязвимости в пакетном менеджере Cargo, применяемом для проектов на языке Rust
  3. OpenNews: Уязвимость в стандартной библиотеке языка Rust
  4. OpenNews: GitHub добавил поддержку отслеживания уязвимостей в проектах на языке Rust
  5. OpenNews: Уязвимость в сетевых библиотеках языков Rust и Go, позволяющая обойти проверку IP-адресов
  6. OpenNews: Уязвимости в Please, альтернативе sudo, написанной на языке Rust
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/58444-rust
Ключевые слова: rust, hyper
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (279) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 21:28, 06/01/2023 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +5 +/
     
     
  • 2.54, Прохожий (??), 01:46, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 3.154, Аноним (-), 06:03, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 4.189, Прохожий (??), 12:27, 07/01/2023 Скрыто модератором
  • +/
     
  • 2.72, Аноним (72), 02:30, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 3.74, Свидетель ржавоговы (?), 02:33, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 4.77, Прохожий (??), 02:36, 07/01/2023 Скрыто модератором
  • +1 +/
     
     
  • 5.79, Свидетель ржавоговы (?), 02:37, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 6.82, Прохожий (??), 02:39, 07/01/2023 Скрыто модератором
  • +1 +/
     
     
  • 7.84, Свидетель ржавоговы (?), 02:40, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 8.88, Прохожий (??), 02:42, 07/01/2023 Скрыто модератором
  • +/
     
  • 7.86, Свидетель ржавоговы (?), 02:41, 07/01/2023 Скрыто модератором
  • +1 +/
     
     
  • 8.91, Прохожий (??), 02:43, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 9.155, Аноним (-), 06:04, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 10.172, Прохожий (??), 11:33, 07/01/2023 Скрыто модератором
  • +1 +/
     
  • 8.102, Прохожий (??), 02:53, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 9.129, Свидетель ржавоговы (?), 03:22, 07/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 10.130, Прохожий (??), 03:26, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 11.133, Аноним (133), 03:41, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 12.138, Аноним (138), 03:57, 07/01/2023 Скрыто модератором
  • –1 +/
     
  • 12.144, Прохожий (??), 04:07, 07/01/2023 Скрыто модератором
  • +/
     
  • 9.170, YetAnotherOnanym (ok), 11:23, 07/01/2023 Скрыто модератором
  • +1 +/
     
     
  • 10.171, Прохожий (??), 11:31, 07/01/2023 Скрыто модератором
  • +/
     
  • 5.83, Свидетель ржавоговы (?), 02:39, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 6.94, Аноним (72), 02:48, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 7.124, Аноним (133), 03:15, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 8.158, Sw00p aka Jerom (?), 09:09, 07/01/2023 Скрыто модератором
  • +/
     
  • 4.78, Свидетель ржавоговы (?), 02:36, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 5.85, Прохожий (??), 02:40, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 6.89, Свидетель ржавоговы (?), 02:42, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 7.95, Прохожий (??), 02:48, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 8.180, Ананимаз (?), 11:53, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 9.185, Прохожий (??), 12:02, 07/01/2023 Скрыто модератором
  • +/
     
  • 9.233, Аноним (233), 16:45, 07/01/2023 Скрыто модератором
  • +/
     
  • 7.96, Аноним (72), 02:49, 07/01/2023 Скрыто модератором
  • +/
     
  • 3.76, Свидетель ржавоговы (?), 02:34, 07/01/2023 Скрыто модератором
  • +1 +/
     
     
  • 4.81, Прохожий (??), 02:37, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 5.228, Аноним (228), 16:18, 07/01/2023 Скрыто модератором
  • +/
     
  • 4.234, Аноним (233), 16:47, 07/01/2023 Скрыто модератором
  • +/
     
  • 2.90, Аноним (90), 02:43, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 3.139, Аноним (138), 04:00, 07/01/2023 Скрыто модератором
  • +/
     
     
  • 4.192, Прохожий (??), 12:33, 07/01/2023 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (41)

  • 1.2, ПомидорИзДолины (?), 21:35, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Ожидаемое поведение, в документации все описано.

    JFrog решили в очередной раз попиарится - ок. Зачем это сюда принесли?

     
     
  • 2.3, ПомидорИзДолины (?), 21:38, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Второй параграф в документации

    > Care needs to be taken if the remote is untrusted. The function doesn’t implement any length checks and an malicious peer might make it consume arbitrary amounts of memory. Checking the Content-Length is a possibility, but it is not strictly mandated to be present.

     
     
  • 3.17, НяшМяш (ok), 22:35, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Делают комбайн со 100500 возможностей - фуфуфу гигантская кодовая база, сложно проводить аудит и вообще не юниксвейно.
    Делают библиотеку с ограниченной функциональностью - о нет она не валидирует штуканейм и это уязвимость.

    Типичная биполярка различных экспертов.

    P.S. https://docs.rs/tower-http/latest/tower_http/limit/struct.RequestBodyLimitLaye

     
     
  • 4.25, Аноним (25), 23:24, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Можешь как угодно называть уязвимость (ниже уже назвали "задокументированным поведением"), как угодно критиковать архитектуры и как угодно выставлять диагнозы опеннетчикам, но отказ в обслуживании это не исправит.
     
     
  • 5.194, Прохожий (??), 12:40, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Проблема этой ветки обсуждения в том, что некоторые комментаторы пытаются экстраполировать человеческую ошибку пользователей библиотеки на якобы имеющиеся изъяны языка программирования.

    И при этом эти же комментаторы в упор не замечают изъяны в логической цепочке своих рассуждений.

     
     
  • 6.261, keydon (ok), 23:21, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проблема этой ветки в том что раст преподносился (и преподносится) как язык решающий человеческие ошибки. Но по факту он решает их малую часть (и создает новые). То есть от чего уходили (человеческие ошибки в си) к тому и пришли (человеческие ошибки в расте).
    Люди разделились на тех кто решил этого не замечать (растоманы) и тех кто об этом говорил с момента зарождения раста (сишники). В зависимости от этого и разное отношение к каждой подобной новости.
     
     
  • 7.273, Аноним (90), 00:10, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но по факту он решает их малую часть (и создает новые).

    Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не создвал. Просвети насчет новых. Главная ошибка - ты не смог осилить новый ЯП?

     
     
  • 8.284, keydon (ok), 01:00, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давай посчитаем Какие конкретно ошибки в твоих программах с использованием совр... текст свёрнут, показать
     
     
  • 9.362, Анимус (?), 18:58, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стан... текст свёрнут, показать
     
     
  • 10.370, keydon (ok), 12:50, 11/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так ты и в расте ими обмазываешься, только выбора у тебя нет в отличии от плюсов... текст свёрнут, показать
     
  • 7.300, Аноним (300), 13:43, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > раст преподносился (и преподносится) как язык решающий человеческие ошибки

    Вот только не было обещаний, что он решит их все.

     
     
  • 8.306, keydon (ok), 14:38, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я еще с первых форсов раста писал что чуда не случится и все имеет свою цену, да... большой текст свёрнут, показать
     
  • 5.240, НяшМяш (ok), 17:45, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты бездумно используешь метод "я буду сохранять все байтики в память", который явно в документации помечен опасным - надо свою кукуху лечить, а не низкоуровневую библиотеку. А вот почему создатели более высокоуровневых реализаций серверов не поставили ограничение по-умолчанию - это уже совершенно обоснованная претензия.
     
  • 3.73, Аноним (72), 02:32, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Care needs to be taken if the remote is untrusted.

    У них там с башкой проблема? Remote is always implicitly untrusted.

     
     
  • 4.125, ПомидорИзДолины (?), 03:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Remote может быть nginx в режиме reverse proxy, который сделает все проверки за тебя.
     
  • 4.148, Аноним (148), 04:13, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Это же библиотека для сборки из кирпичиков, а не полнофункциональный сервер. А лимит понятие относительное. На видеохостинге он обычно чуть больше, чем на смарт-часах.

    Это примерно как в malloc() засунуть проверку, чтобы слишком много не выделяли :-)

     
  • 2.27, Аноним (25), 23:26, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и в си UB описаны, необходимость проверок тоже. Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".
     
     
  • 3.35, Аноним (35), 23:40, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Так и в си UB описаны, необходимость проверок тоже.

    Правда, сам ты весь список не читал, просто слышал звон.
    > Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".

    Никаких "почему-то" не было, если бы ты черпал свои познания по ЯП не только лишь из комментов на опеннете - тебе бы вряд ли пришло в голову сравнивать один ЯП с HTTP-библиотекой на другом.
    Но увы, увы ...

     
  • 3.104, Аноним (90), 02:55, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >  а в расте "задокументированное поведение".

    В расте или в имплементации какой-то библиотеки на расте? Ты чем читал? Молодец, сравнил недостатки языка программирования си с недостатками кем-то написанной библиотекой-фреймворком. Никто не мешает тебе сознательно на расте написать пучок "полезных" фреймворков, специально впендюрить туда что-то типа "извне запросили выделить 1 мегабайт памяти? Выделю 1 гигабайт, ха-ха-ха", а потом кричать на каждом углу: "-раст гнилой! Он ошибки памяти делает! Жрет как не в себя!". Ну или не проверять переданные извне параметры. И опять у тебя будет раст виноват, чего это ЯП, а не программист, не проверил, что там в JSON/XML прилетело.

     
     
  • 4.157, Аноним (25), 08:55, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну пошли отмазки. Лет 9 назад вас, растоманов, не волновало что ещё и библиотеки надо писать с новыми багами(между прочим один из аргументов сишников против раста) и вообще думать все равно придется. Наоборот, растоманы писали что "разработчики раста уже подумали за программиста". Теперь вот на ходу (последние несколько лет) меняете риторику.
    Всё чем вы оправдываетесь в последнее время, всё это писали вам сишники лет 9 назад.
     
     
  • 5.175, Прохожий (??), 11:41, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это не отмазки. Это попытка объяснить слабым разумом, что данная конкретная ошибка не имеет никакого отношения к языку программирования. Но некоторым, что в лоб, что по лбу. Увы.
     
     
  • 6.236, Аноним (228), 17:05, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Библиотека на чем написана? Значит обгадился раст.
     
     
  • 7.249, freecoder (ok), 22:13, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Попытка выделить большой кусок памяти не является небезопасной операцией. Safe Rust такое разрешает и подобные "ошибки" (а на самом деле и не ошибки вовсе) не устраняет.
     
  • 7.272, Аноним (90), 00:08, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    хе, представляю. Пишет кто-то какой-нибудь хайлоад для суперкомпа с терабайтом озу. Выделяет такой память под буфер, скажем, 10ГБ (ну там наколеночно-велосипедный in-memory-db), а тебе такой компилятор (или код в рантайме) раз: " - ошибка! разрешается выделять не более 1МБ ОЗУ, я так решил, 1 МБ должно хватить всем! Читай мануал языка, там это написано, в мануале запрещено выделять более 1МБ памяти!". Я правильно тебя понял?

    > Библиотека на чем написана? Значит обгадился раст.

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

     
  • 6.264, keydon (ok), 23:29, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Об этом сишники писали 10 лет назад. Что ЯП не исправит человеческие ошибки, даже наоборот - либ нет, а пока сделают новые наклепают и новых ошибок (что и произошло).
    В ответ им заявлялось что де раст то все исправит, якобы разработка на расте изначально безопаснее и намного проще и быстрее (поэтому все дедовские либы перепишут гораздо быстрее чем писали на си).
    Чуда не случилось и теперь аргументы сишников 9 летней давности отправляют обратно сишникам и считают что это ок.
     
     
  • 7.268, Аноним (90), 23:57, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    наглая ложь И ты это понимаешь Троллишь наверное Всем понятно и тебе тоже , ... большой текст свёрнут, показать
     
     
  • 8.281, keydon (ok), 00:46, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет Так это и заявлялось противниками раста и лично мной ЕМНИП даже пример прив... большой текст свёрнут, показать
     
     
  • 9.301, Аноним (300), 13:48, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так почему так и не решили ... текст свёрнут, показать
     
     
  • 10.369, keydon (ok), 12:47, 11/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так в основном и решили ... текст свёрнут, показать
     
  • 2.68, kai3341 (ok), 02:14, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ожидаемое поведение, в документации все описано.

    Дополню. Запросы со слишком большим телом почикает nginx. Расходимся

     
     
  • 3.75, Аноним (228), 02:34, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почикает нгиннкс на С
     
  • 3.160, Sw00p aka Jerom (?), 09:13, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а че с чанками делать и крывыми размерами контента в заголовках?
     
  • 2.145, MaleDog (?), 04:07, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я бы сказал безмозглое поведение - выделять оперативную память под запрос целиком на основе "Content-Length". Рустоманы так упоролись на том чтобы всем доказать "безопасность работы с памятью", что их поделие заболело детскими болячками Apache. Так скоро LOIC опять станет актуален.
     
     
  • 3.149, MaleDog (?), 04:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Еще поди можно так:
    - кидаем много запросов с небольшим Content-Length, но с телом усеченным до нуля и одного байта.
    - сервер выделяет под них память, но освобождает ее с лагом, так как ждет нужное количество байт которых нет.
     
     
  • 4.161, Sw00p aka Jerom (?), 09:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >так как ждет нужное количество байт которых нет.

    в смысле? освобождает ровно столько сколько выделил

     
     
  • 5.184, MaleDog (?), 12:02, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Выделяет столько сколько сказали Затем он по какому-то таймауту должен понять, ... большой текст свёрнут, показать
     
     
  • 6.330, Аноним (330), 19:44, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > добрый сервер выделил боту 10G оперативной памяти? А если столько нет?

    overcommit

    > что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду

    Лимит по времени на запрос

     
     
  • 7.359, MaleDog (?), 11:01, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но при этом на "лимит времени" память будет занята. Притом атакующий затратит гораздо меньше ресурсов. Так ему нужна память только на заголовки одного запроса, а в качестве тела будет "мусор". Нет, так дела не делаются. Выделяем буфер на заголовки. Парсим проверяем. Далее либо буферизуем тело небольшим буфером передавая по частям обработчику, либо просто пробрасываем TCP-соединение ему - пусть сам разбирается.
     
  • 3.176, Прохожий (??), 11:44, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В данном случае упоролись всё же Воины Борьбы Супротив Раста, раз и после нескольких десятков комментариев не понимают, что данная конкретная ошибка не имеет никакого отношения к возможностям языка программирования.
     
     
  • 4.245, Аноним (245), 19:40, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    упоролись растоманы которые всегда утверждали, что раст решает все проблемы безопасности.
     
     
  • 5.250, freecoder (ok), 22:16, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности. А не подмножество проблем, связанных с безопасностью работы с памятью и безопасностью типов.
     
     
  • 6.271, keydon (ok), 00:04, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Давненько я лично писал на опеннете что раст не решает всех проблем, а только не... большой текст свёрнут, показать
     
     
  • 7.283, freecoder (ok), 00:52, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Rust решает некоторые проблемы, но большие и очень важные. Линтерами на плюсах они не решаются в той мере, которой решаются растом. Как видите, это совсем не "тот же самый аргумент".

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

     
  • 3.267, Аноним (267), 23:40, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так это специальная функция для чтения запроса целиком. Когда он заведомо небольшой. Если больше лимита - проверь и отдай HTTP 413 Payload Too Large. Лимит, разумеется, на усмотрение разработчика, а не автора библиотеки - а как еще?

    Для чтения по кускам там есть функция aggregate(), и, внезапно, в мануале рекомендуется использовать именно её.

     

     ....большая нить свёрнута, показать (43)

  • 1.4, Аноним (4), 21:39, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Безопасность не поместилась в оперативную память
     
     
  • 2.10, Аноним (228), 21:54, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    боров-чекер оказался слишком жирным боровым и не влез в оперативку
     
     
  • 3.15, Alladin (?), 22:29, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    борров чекер проверяется и работает на этапе компиляции в скомпилированном коде он потребляет 0, вы белину сьели?
     
     
  • 4.19, Аноним (228), 23:07, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я знаю что это такое, просто мне слово нравится... боров
     
     
  • 5.43, Dzen Python (ok), 23:57, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проверяльщик боровов, дядь. Который при компиляции бегает между каждым боровом и смотрит им...хм, пусть будет в пятачок, чтобы не залезли боровы и рылом дырок-уязвимостей не нарыл.
     
  • 4.23, Аноним (228), 23:16, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    я может что-то не понимаю, но раст с кучей не умеет что ли работать? Если на этапе компиляции, то как он выполняет эти ваши боровы-чекеры с аллоцированной в рантайме памятью?
     
     
  • 5.49, Прохожий (??), 01:18, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Компилятор не проверяет, сколько именно памяти есть в системе - это не его задача. Он проверяет, чтобы висячие ссылки не появлялись, чтобы use-after-free не происходило. Конечно же Rust умеет работать с кучей, но он не всемогущ, как некоторые ошибочно полагают. В нём по-прежнему возможны разные ошибки (в том числе утечка или переполнение памяти). В чём же смысл тогда, кто-то может спросить? В том, что Rust предотвращает наиболее распространённые ошибки.
     
     
  • 6.53, Проффесор (?), 01:45, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ... способствует программисту потерять бдительность
     
     
  • 7.56, Прохожий (??), 01:48, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не способствует, а освобождает программиста от слежения за определённым классом ошибок, позволяя ему сосредотачиваться на других вещах, более полезных и продуктивных.
     
     
  • 8.60, Проффесор (?), 01:55, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Способствует Более того создает впечатление у новичков что программирование - ... текст свёрнут, показать
     
     
  • 9.67, Прохожий (??), 02:11, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скажем так, у слабых разумом такое может случиться Но мы ж о нормальных, правда... текст свёрнут, показать
     
     
  • 10.121, Свидетель ржавоговы (?), 03:12, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Какой же ты тупой Это не архитектурный изъян Такими словами можно сказать инте... текст свёрнут, показать
     
     
  • 11.134, Прохожий (??), 03:41, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - э... большой текст свёрнут, показать
     
     
  • 12.237, Аноним (228), 17:11, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    what В Си контроллировать память можно когда угодно и как угодно Про какой изъ... текст свёрнут, показать
     
  • 8.123, Свидетель ржавоговы (?), 03:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так таким значит надо писать на Java, Go, Dart, C , JS наконец с Питоном -- вы ж... текст свёрнут, показать
     
     
  • 9.135, Прохожий (??), 03:48, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Каким таким Все люди подвержены ошибкам Исключений нет И это, как я уже сказа... большой текст свёрнут, показать
     
  • 7.363, Анимус (?), 19:08, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Добывай огонь трением, мало ли, спички закончатся
     

     ....большая нить свёрнута, показать (16)

  • 1.6, Аноним (228), 21:47, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Rust
    > выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании
    > достаточно отправить специально оформленный HTTP-запрос

    Ок, ясно

     
     
  • 2.204, Прохожий (??), 13:14, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не думаю, что тебе стало что-либо ясно. Но ок.
     

  • 1.7, Аноним (228), 21:49, 06/01/2023 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +2 +/
     
     
  • 2.24, Аноним (24), 23:22, 06/01/2023 Скрыто модератором
  • +6 +/
     
     
  • 3.36, Аноним (36), 23:41, 06/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 4.47, Аноним (47), 00:39, 07/01/2023 Скрыто модератором
  • +2 +/
     
  • 2.231, псевдонимус (?), 16:25, 07/01/2023 Скрыто модератором
  • –1 +/
     

     ....ответы скрыты модератором (4)

  • 1.8, pashev.ru (?), 21:51, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всё правильно. Ещё со времён Юниксов и Си правильно. Программа или библиотечная функция должа делать ровно одну задачу и делать её хорошо. Проверка входящих параметров — это отдельная задача. Если она не нужна, зачем за неё платить? Это кстати, часть философии Раста.
     
     
  • 2.12, Аноним (133), 22:10, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • –10 +/
    Всё верно,товарищ.
    Проверки выхода за границы массива - тоже отдельная задача.

    Эту Unix/C  философию разгребаем уже 30 лет.

     
     
  • 3.101, Свидетель ржавоговы (?), 02:53, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Проверки выхода за границы массива - тоже отдельная задача.

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

     
     
  • 4.132, Аноним (133), 03:31, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тыкну тебя в единственный по-настоящему системный язык программирования. Он называется Zig.

    Ближе к железу только чистый ассемблер.

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

    В Debug все проверки есть. В ReleaseFast проверок выхода за границы нет. Можно же было сделать такое и в С (лет 15 назад)?

    А в С++ только если .at() есть проверки, в [] проверок нет.


     
     
  • 5.162, Вы забыли заполнить поле Name (?), 09:16, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Можно же было сделать такое и в С (лет 15 назад)?

    Это уже давно есть. Открой для себя санитайзеры наконец.

     
     
  • 6.206, Прохожий (??), 13:19, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты понимаешь разницу между специализированным ПО (которое, несмотря на все усилия, не в состоянии выловить все ошибки)  и архитектурными особенностями языка программирования, не дающими тебе совершать такие ошибки априори? Это был риторический вопрос, потому что из твоего комментария и так всё понятно.
     
     
  • 7.262, Вы забыли заполнить поле Name (?), 23:23, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты понимаешь разницу между специализированным ПО

    А ты понимаешь, что компилятор раста - это тоже специализированное ПО?

    > которое, несмотря на все усилия, не
    > в состоянии выловить все ошибки

    А компилятор раста способен выловить все ошибки? Может санитайзеры и фазинг не нужен?

    > Это был риторический вопрос

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

     
  • 4.150, Прохожий (??), 04:20, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Но раст не дотягивает до крестов.

    Чего не хватает Rust, о гуру системного программирования?

    > а не какие-то чистилки мусора, виртуалки, обслуживалки

    В Rust всего этого нет. Сюрприз?

     
     
  • 5.277, Вы забыли заполнить поле Name (?), 00:31, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Но раст не дотягивает до крестов.
    > Чего не хватает Rust, о гуру системного программирования?

    * Прибитость гвоздями к LLVM
    * Обработки ошибок аллокации памяти
    * Float-free libcore
    * Работа без cargo
    * Работа без стандартной либы
    * Работа с динамически разделяемыми билиотеками
    * Стабильного ABI и внятного версионирования


     
     
  • 6.280, Andrewpotam (?), 00:46, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > * Прибитость гвоздями к LLVM

    Cranelift

    > * Обработки ошибок аллокации памяти

    set_alloc_error_hook

    > * Float-free libcore

    зачем?
    > * Работа без cargo

    есть
    > * Работа без стандартной либы

    есть
    > * Работа с динамически разделяемыми билиотеками

    можно использовать C ABI, идет работа над нормальным ABI

    > * Стабильного ABI и внятного версионирования

    опять же, работа над ABI идет, что не так с версионированием? По моему намного лучше чем в C/C++

     
     
  • 7.285, Вы забыли заполнить поле Name (?), 01:23, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> * Прибитость гвоздями к LLVM
    > Cranelift

    Судя по описанию это еще сырой проект и нацелен в первую очередь на WASM?

    >> * Обработки ошибок аллокации памяти

    Это nightly-only experimental API. К тому же хочется какой-то реальный пример с этим увидеть. А так обычно все просто сводится к панике.

    >> * Float-free libcore
    > зачем?

    https://github.com/rust-lang/rfcs/issues/1364

    >> * Стабильного ABI и внятного версионирования
    > опять же, работа над ABI идет, что не так с версионированием? По
    > моему намного лучше чем в C/C++

    У С++ есть стандарт. Код переписывают в соответствии со стандартами, которые выходят не так часто.

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

     
     
  • 8.364, Анимус (?), 19:15, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты бы не позорился У Раст так же стандарты выходят раз в три года ... текст свёрнут, показать
     
     
  • 9.366, Вы забыли заполнить поле Name (?), 21:34, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ссылкой на стандарт поделишься ... текст свёрнут, показать
     
  • 2.42, Dzen Python (ok), 23:48, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так если подумать и реализовано неправильно.
    Если заведомо нет проверок на длину сырых (задача обработки и формирования буфера ДОКУМЕНТИРОВАНО возложена на приложение, вызывающее функцию) данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.

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

     
     
  • 3.52, Прохожий (??), 01:39, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А если не только подумать, тыкая пальчиком в небо, а ещё почитать доку, например? Понимаю, некоторым питонистам это слишком тяжело, и я, наверное, многого хочу, но всё же. Вот же, несколько раз уже выдержку из стандарта приводили: "Checking the Content-Length is a possibility, but it is not strictly mandated to be present."

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

    И каким должен быть этот внутренний буфер, уважаемый эксперт?

    > Т.е. так и запишем

    Очередной Воин Супротив Раста сел в лужу.

     
     
  • 4.69, Аноним (228), 02:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?
     
     
  • 5.71, Прохожий (??), 02:28, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?

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

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

     
     
  • 6.87, Аноним (72), 02:42, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Претензии к растоманам, питонистам и JS/TypeScript-ам (не всем!) простые - они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.
     
     
  • 7.106, Прохожий (??), 02:56, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.

    Какой-то поток сознания, не распарсил, сорри.

     
     
  • 8.117, Свидетель ржавоговы (?), 03:09, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    свайпай дальше ... текст свёрнут, показать
     
     
  • 9.178, Прохожий (??), 11:49, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаешь, каждую вспышку больного сознания комментировать Сорри, это не ко м... текст свёрнут, показать
     
  • 4.246, Аноним (245), 19:46, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    дебилизм какой-то, давайте напишем в документации ядра линукс, что хакеры не должны использовать дыры для целей порочащих безопасность и ядро автоматически станет безопасным. а от сбоев памяти защититься всюду ECC.
     
     
  • 5.251, freecoder (ok), 22:24, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Функция выделяет памяти столько, сколько её попросили. Никаких UB при этом нет. В чем дебилизм- то?
     
  • 5.278, Аноним (90), 00:36, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там написали, что ты не должен это выставлять наружу, в недоверенное окружение ... большой текст свёрнут, показать
     

  • 1.9, Alladin (?), 21:53, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    как же тупо, тупо никаких ограничений на выделение по "Content-Length"...
     
     
  • 2.29, Аноним (29), 23:28, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > как же тупо, тупо никаких ограничений на выделение по "Content-Length"...

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


     
     
  • 3.31, Аноним (228), 23:33, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очевидно, так как растоманы решили - чтоб отказ в обслуживании.
     
     
  • 4.44, Аноним (44), 23:59, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Очевидно, так как растоманы решили - чтоб отказ в обслуживании.

    Очевидно, открыта перепись Ыкспердов опеннета.
    Правда, Ыксперды не знали (а так как дальше заголовка не читали - и не смогли узнать), что Content-Length - "not strictly mandated to be present."

     
     
  • 5.46, Alladin (?), 00:37, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    я и сам никогда не ориентировался на content-length, прислушивался но не ориентировался
     
  • 3.80, Аноним (72), 02:37, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Очевидно: библиотека должна посмотреть размер свободной памяти на машине, помножить на коэффициент нехило меньше 1 (напр. 0.25), далее помножить на (1. - 0.005 + random(0.01)), и такое ограничение и выставить.
     
     
  • 4.93, Аноним (330), 02:46, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что если на машине 64гб рам, а в слайсе сигруппы приложению выделили всего 256мб рам?
     
     
  • 5.99, Аноним (72), 02:52, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а приложение в этой группе, когда дёрнет API, увидит, что у неё доступно для выделения 64 гига?
     
     
  • 6.136, Аноним (133), 03:49, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Какая нахрен разница, в С / libc / Linux нет реального выделения памяти. Выделяй на выделяй всё равно получишь...

    Выделить можно всю память + swap. На каждый процесс:)))

     
     
  • 7.297, Аноним (297), 13:17, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Адекватные люди отключают оверкоммит. И тут же выясняется, что говно и линукс и его экосистема (бочка мёда с ложкой говна есть бочка говна), программы на нём памяти жрут на порядки больше, чем на винде, и фиксить это никто не будет, потому что "у кого нет денег на железо, тот пусть пользуется софтом для быдла, а мы, илитка, можем себе позволить жрущий софт".
     
  • 4.190, Омномним (?), 12:27, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очевидно: чтение реквеста должно быть блочным, а не "запихать всё в память и отдать вызывающему".
     
     
  • 5.197, Прохожий (??), 12:57, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты про такой протокол, как UDP и на нем основанных слышал? Знаешь, как там всё работает?
     
     
  • 6.243, Аноним (228), 18:29, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Дед, ты таблетки забыл принять на ночь? Что ты, блин, несешь, старый идиот?
    Ты для начала хотя бы попробуй написать простейший UDP-сервер, к-й принимает пакет по сети, дак вот сразу перестанешь такой бред нести про UDP.

    По твоей логике, я должен потоковое видео, льющеяся по UDP сохранять в буфер полностью? o_O Ты дурак? Что ты тут кичишься знаниями UDP, хотя сам в этом нихера не понимаешь. Знаем мы как UDP работает, и даже софт, использующий его пишем. А вот ты видимо нет, раз приводишь его тут в пример в контексе копирования ответ в мега-огромный буфер без проверки.

     
     
  • 7.299, Аноним (297), 13:29, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если оно по HTTP - то да. HTTP/3 включает в себя свой TCP поверх UDP. Протоколы, основанные на TCP, не занимаются обработкой потери и перетасовкой пакетов, за них это должен делать TCP-слой. HTTP/1 и HTTP/2 и TLS основаны на TCP, поэтому обработка потери пакетов не есть зона ответственности приложения, использующего эти протоколы. HTTP/3 есть прозрачная замена для HTTP/2 и HTTP,  добавление которой в приложение заключа5тся в обновлении версии библиотеки и, возможно, включении возможности.

    Поэтшму гнать потоковое видео по HTTP - плохая идея. Для этого есть RTP и более новые протоколы, вроде https://www.haivision.com/products/srt-secure-reliable-transport/ и https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic .

     
  • 6.244, Аноним (228), 19:22, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И вообще, дед, причем тут UDP или TCP? Это нижележащий уровень, транспортные протоколы. Их задача - доставить тебе в приложение (идентифицируемое по номеру порта) payload, всё. Какая разница как тебе их доставили, через TCP или UDP? Ну вот что ты так бредишь то, зачем ты так позоришься? Выпей кефиру на ночь, или что вы там злобные стариканы пьёте, и ложись уже спать.
     
  • 4.238, Анонн (?), 17:16, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Добавить рандом в либу... И привязать его к параметру окружения...
    Да ты просто злой гений! Пусть эти зaсрaнцы попробуют найти почему оно иногда не работает!
     
     
  • 5.296, Аноним (297), 13:13, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Документацию читать надо, а ошибки - писать в лог вместе с причинами. Рандом нужен для того, чтобы удаленные атакующие не могли определить количество свободной памяти на машине в данном окне по времени.
     
  • 3.198, MaleDog (?), 12:58, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Э-э. Выделить небольшой буфер на проверку заголовков. Передать их обработчику, чтобы тот авторизовал, проверил и сам выделил нужное количество оперативы. Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению буфера или даже раньше передавать их обработчику. Что он с ними будет делать уже его проблема, главное буфер тут нужен чтобы избежать задержек. Но точно не пытаться считать весь запрос в оперативку.
     
     
  • 4.208, MaleDog (?), 13:33, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а chunked-запрос - это извращение. Насколько я помню изначально chunked был только для ответа сервера. Но потом реализовали и для запроса. При этом у chunked отсутствует заголовок Content-Length. Сколько читать указано перед чанком. Наиболее безопасно выделять буфер непосредственно перед чтением чанка проверив предварительно, что тот не слишком длинный, так как стандартом не оговорены ни максимальная длинна, ни то что чанки должны быть одинаковой длинны.
    В любом случае chunked это не про быстродействие, это скорее про "бедность" передающего на оперативку. Так что нет никаких причин быстро его на сервере обрабатывать помещая весь запрос в оперативку.
     
     
  • 5.339, Омномним (?), 20:47, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему извращение?
    Допустим мы хотим залить контент заранее не известного объёма.
    Какую-нибудь телеметрию например, которая идёт потоком, но лить хотим по HTTP.
    Why not?
     
     
  • 6.367, MaleDog (?), 22:28, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому, что заранее не известно когда закончится запрос. Теоретически я хоть целый день могу развлекать сервер одним запросом(насколько хватит терпения у проектировавшего сервер). Кроме того ему нужно будет решать вопросы с увеличивающимся или уменьшающимся буфером или склеиванием, ведь максимальная длинна чанка не известна заранее и нигде не сказано что они могут быть одной и той же длинны. и эта проблема умножается на два или на три, если со стороны сервера или клиента есть прокси. Лучше уж тогда TCP и бинарный протокол, где все, включая длинну сообщения будет заранее оговорено. Не спорю то же самое можно оговорить и в заголовке HTTP, но зачем? Учитывая что выбрав бинарь вы минимум вдвое сэкономите на длинне сообщения.
     
     
  • 7.368, MaleDog (?), 22:56, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тем более, что часто люди просто не думают Вот к примеру реальный случай Мне п... большой текст свёрнут, показать
     
  • 7.371, Омномним (?), 15:07, 11/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Про read timeout что-нибудь слышал?
    Ну и да - чанк не обязательно читать целиком, снова растожаберство какое-то в голове :)
     
     
  • 8.372, MaleDog (?), 23:15, 12/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут вся суть в том Как отличить добросовестное использование от недобросовестно... текст свёрнут, показать
     
     
  • 9.373, Омномним (?), 00:45, 13/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чичиго ... текст свёрнут, показать
     
  • 4.248, Аноним (248), 21:27, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению

    Э-э, там, в той самой библиотеке, для этого есть aggregate - читает в буфер, размер буфера устанавливается по вкусу. Кто ж виноват, что нельзя никак заставить использовать именно это API?

     
  • 3.241, Аноним (241), 18:00, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Можно посмотреть как эту проблему решили высокооплачиваемые программисты из Sun.
    https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#readAllByte)

    OutOfMemoryError - if an array of the required size cannot be allocated, for example the file is larger that 2GB

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

     
     
  • 4.307, Аноним (307), 14:50, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    и вообще смог понять что за проблема
     
  • 2.103, Свидетель ржавоговы (?), 02:55, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это норм. Просто макакинг-девелопмент
     

  • 1.20, Аноним (20), 23:11, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чудесное определение — "особенность работы с памятью". Запомню.
     
     
  • 2.55, Проффесор (?), 01:48, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ой как интересно получилось
     
     
  • 3.62, Прохожий (??), 01:59, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой какой длинный список получается
     
  • 2.351, Аноним (351), 15:11, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Программы на Rust текут из-за особенности работы с памятью."
     
     
  • 3.355, Аноним (355), 20:20, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > "Программы на Rust текут из-за особенности работы с памятью."

    Нет, зато опеннетные экспертусы-по-всему не владеют даже элементарной терминологией.

     

  • 1.21, Аноним (228), 23:12, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Сишник забывает очистить память в указателе
    растоман: диды писали, надо переписать на раст

    растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.
    опять растоман: это задокументировано!

     
     
  • 2.26, Аноним (29), 23:25, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.

    Питонист, расскажи куда его еще копировать, заодно выдай, каким должен быть "разумный" ограничитель по дефолту.
    > опять растоман: это задокументировано!

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


     
     
  • 3.28, Аноним (228), 23:27, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    UB в ANSI C тоже задокументировано.
     
     
  • 4.45, Аноним (248), 00:00, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Checking the Content-Length is a possibility, but it is not strictly mandated to be present.
    > UB в ANSI C тоже задокументировано.

    А в огороде бузина.

     
  • 2.107, Свидетель ржавоговы (?), 02:57, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да нее, тут опять сишники виноваты
     
     
  • 3.211, Прохожий (??), 13:44, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не тут. Но виноваты, конечно.
     

  • 1.22, Аноним (25), 23:16, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Помнится си критиковали за то что программисту нужно слишком много думать и знать и о многом заботиться. И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось, зато мелкософт и гугл (текущих владельцев раста) захватили ещё немного влияния.
     
     
  • 2.30, Аноним (30), 23:32, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>  Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера
    > И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось

    Очередная перепись не читающих дальше заголовка?

     
     
  • 3.164, Аноним (25), 09:51, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".
    Потом было "мы ещё сырые, но вот ещё чуток подпилим".
    Сейчас вот "раст не виноват, это всё...".
    Собственно всё это мы уже проходили с джавой, а единственный результат который получили это зависимость от корпораций (в данном случае гугель и мелкософт).
     
     
  • 4.177, Аноним (300), 11:48, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Изначально было "раст все порешает" и "программисты не будут совершать ошибки"

    Где это заявлялось?

     
  • 4.258, Аноним (90), 23:01, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой звездуны-ы-ы-ы Вкладывать свои слова и мысли в уста оппонента и потом с па... большой текст свёрнут, показать
     

  • 1.38, Аноним (38), 23:42, 06/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    У Си уязвимости, а у Раста ОСОБЕННОСТИ работы с памятью, понимать надо.
     
     
  • 2.41, Dzen Python (ok), 23:44, 06/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Говори толерантнее, иначе к тебе приедет айнзац-команда и до реанимации будет учить тебя политкорректности: у раста не особенности, у раста ЗАДОКУМЕНТИРОВАННОЕ ПОВЕДЕНИЕ.
     
     
  • 3.61, Прохожий (??), 01:57, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Эх, видимо, рано я порадовался за питониста. Эй, питонист. Не у Раста, а в стандарте такое поведение. Надеюсь, ты понимаешь разницу между стандартом и языком программирования? Или я опять слишком многого прошу?
     
     
  • 4.112, Свидетель ржавоговы (?), 03:01, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Способность обращаться по любому адресу памяти это нормальное поведение кода, исполняющегося на процессоре.
     
     
  • 5.122, Прохожий (??), 03:13, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    С точки зрения процессора - да, нормальное. А с точки зрения программиста, который в здравом уме находится - нет, не всегда это нормально, и часто это надо пресекать.
     
  • 5.259, Аноним (90), 23:12, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не любого кода. Подавляющая часть программ (состоящих из данных и кода) категорически не должна иметь доступ _по любому_ адресу памяти. С точки зрения современной (относительно) универсальной (многопроцессной, многопользовательской) операционной системы. Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти. Или к уже освобожденной. Или выделенной другой программе, если у них специально разделяемую область не создал, с казино и шлю... с доступом примитивы синхронизации (семафоры и т.п.). В своих наколенных ОС-поделках воруй память наперегонки из разных программ как тебе вздумается. Т.е. подозреваю кроме как под DOS, используя хитрые "хакирские" трюки, ты ничего не писал.
     
     
  • 6.276, Аноним (228), 00:27, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Не любого кода

    Тебе сказали - работающего на процессоре, а не под ОС, работающей на процессоре.

     
  • 6.279, Аноним (228), 00:42, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти

    кем не выделенной, куда не выделенной? Вот есть у меня ядро, оно стартует, и... кто и как мне должен память выделить? MINIX3 в IntelME что ли?

    > Или к уже освобожденной

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

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

     
  • 3.169, раст переусложнён (?), 11:12, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >ЗАДОКУМЕНТИРОВАННОЕ

    от слова "док", как в док-станции?

     
     
  • 4.179, Прохожий (??), 11:53, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе далеко пока до Евгения Вагановича. Тренируйся ещё.
     
  • 2.252, freecoder (ok), 22:32, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уязвимость, но не в Rust и даже не в библиотеке Hyper, а в тех серверах, которые реализовали ошибочную логику.
     
     
  • 3.270, Аноним (228), 00:01, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В Си тоже нету уязвимостей, они могут встречаться в софте на нем написаном
     

  • 1.48, Анонн (?), 00:57, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Мда, это даже смешно.
    Это поведение не только записано в доке, там даже пример есть с комментом "// Just to protect ourselves from a malicious response"

    И из всех проектов которые использую hyper нашлась тройка особенных которые на это забили, причем один из которых - участник web-frameworks-benchmark - которые известны "победа любой ценой".

    Просто для "оценки значимости" этих проектов - у хипера 68кк загрузок и примерно 60-100к ежедневно.
    Внимания заслуживает наверное только axum у которого в 10 раз меньше общих загрузок и где-то в 3-5 раз меньше ежедневных. Потому что у Сальво же - 1600 ежедневно (да, просто 1600, без к), а у кондуита - вообще в пике 45 в день.
    Т.е. кому-то было не лень найти эти проекты и написать об УЖАСНОЙ УЯЗВИМОСТИ!!!111

     
     
  • 2.196, Аноним (-), 12:49, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кондуит конечный продукт, естественно у него будет меньше загрузок с сайта «библиотек», странно сравнивать.
     

  • 1.141, Аноним (-), 04:04, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > на языке Rust, выявлена
    > особенность работы с памятью

    Да ну ладно?!

     
     
  • 2.147, Прохожий (??), 04:12, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы мог подумать.
     
     
  • 3.156, Аноним (-), 06:05, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы
    > мог подумать.

    "Но как, Холмс?!"

     
  • 3.232, псевдонимус (?), 16:31, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Галустян,  залогинься.
     

  • 1.143, Аноним (138), 04:06, 07/01/2023 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –1 +/
     
     
  • 2.146, Прохожий (??), 04:12, 07/01/2023 Скрыто модератором
  • +2 +/
     
  • 2.260, Аноним (90), 23:19, 07/01/2023 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (2)

  • 1.165, Анонимусс (?), 10:38, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот она победа раста над древней сишкой!
    Растоманы накосячили с памятью и все лишь получили DoS, а не RCE-дырень с получением рута и тыреньем всех твоих данных.
    Не зря его сделали, не зря его добавили в ядро!
     
     
  • 2.166, An (??), 10:50, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну и развивали бы дальше свой победоносный redox. Нафига в сишный linux полезли?
     
     
  • 3.168, Анонимусс (?), 11:09, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что это будет просто преступлением оставить линукс таким дырявым какой он сейчас!
     
  • 3.173, Аноним (173), 11:36, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, просто за драйверами зашли. Сейчас с ними и уйдут обратно.
     
     
  • 4.187, Прохожий (??), 12:17, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Никто уже никуда не уйдёт, не переживай. Учить язык придётся. Хотя для некоторых это может оказаться и непосильной задачей.
     
  • 4.294, Аноним (294), 11:45, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но дрова то на небезопасном Си, все равно их переписывать с нуля надо
     
  • 3.186, Прохожий (??), 12:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Redox - это почти домашний проект, просто чтобы убедиться, на данном языке можно писать системный софт.
    Полезли в сишный Линукс, потому что последний стал очень распространённым, что означает, что каждая ошибка программиста очень дорого обходится в итоге конечным пользователям. И с этим надо что-то делать. Раст оказался как нельзя кстати.
     

  • 1.174, Аноним (173), 11:37, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А можно написать еще хотя бы одну библиотеку для работы с HTTP, а то что-то свет клином столкнулся с этим Хайпером.
     
  • 1.181, Омномним (?), 11:54, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D
     
     
  • 2.183, Омномним (?), 11:55, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    (так-то вообще школьная ошибка, чтение из сети по заданному размеру без лимитов...)
     
  • 2.201, Прохожий (??), 13:03, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О великий эксперт. А где ты потом собирать будешь эти чанки? Почитай на досуге про UDP, например.
     
     
  • 3.210, Аноним (228), 13:38, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Никогда не останавливайся на полпути, позорься до конца!

    Ты хотя бы посмотри как чтение кусками из UDP реализовано в популярном софте. Боже, растоманы РЕАЛЬНО думают, что UDP весь(!!!) целиком(!!!) надо прочитать в мега-огромный-буфер  прям из сети?

     
     
  • 4.212, Прохожий (??), 13:56, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Упоминание UDP - это была попытка намекнуть, что не все так просто, как сишники себе вообразили.

    Заодно предлагаю тебе поразмыслить (понимаю, для сишников это сложная когнитивная задача, но ты хоть попытайся) , что в данном конкретном случае речь идёт об универсальной  БИБЛИОТЕКЕ, а не о конечном продукте, который, конечно, знает, что ему следует ожидать из сети, а что может игнорировать.

     
     
  • 5.223, Омномним (?), 16:01, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хорошее упоминание. Ты собрался весь поток UDP за неизвестный период в память тащить, или всё-таки будешь его "клиенту" отдавать, чтобы тот решал сам, что с ним делать?
     
  • 5.224, Омномним (?), 16:02, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной, а заточенной только на очень специфичный вариант применения - когда всё в память помещается. Растожабаскриптерство - оно такое.
     
     
  • 6.266, Аноним (90), 23:35, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если ты туда всунешь какой-то лимит на размер буфера она перестанет быть универсальной. На малинке с 2Г оперативы для кастомной программы там одни лимиты будут, для суперкомпа с терабайтом оперативы в защищенном периметре, где к нему не обращаются неавторизованные хосты и программы - другие лимиты. А так впендюришь ты 640KB и скажешь - "этого должно хватить на всё! Универсально!". Универсальность как раз в том, что её могут использовать по разному, под разные нужды. Проблема в том, что кто-то не прочел документацию и не проникся этой универсальностью создавая уже свой продукт. Тут уже от ЯП не зависит. И чего я бисер мечу перед вами...
     
     
  • 7.295, Омномним (?), 11:56, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты в курсе, что лимит может быть конфигурируемым со стороны клиента?
     
  • 6.269, Аноним (269), 23:57, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной,
    > а заточенной только на очень специфичный вариант применения - когда всё
    > в память помещается. Растожабаскриптерство - оно такое.

    https://docs.rs/hyper/latest/hyper/body/fn.aggregate.html
    > Aggregate the data buffers from a body asynchronously.
    > The returned impl Buf groups the Bufs from the HttpBody without copying them. This is ideal if you don’t require a contiguous buffer.

    https://docs.rs/hyper/latest/hyper/body/trait.Buf.html
    > fn remaining(&self) -> usize
    > Returns the number of bytes between the current position and the end of the buffer

    И зачем ты так громко пустил метан в лужу?

     
  • 3.222, Омномним (?), 16:00, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Жаборастера видно издалека, да.
    Собирать будет "клиентский" код - там, где ему надо. С лимитами и т.п.
    Простая проблема мерзкого дизайна. Либа должна отдавать не весь контент целиком, если он большой, а его куски, наподобие read(), с предзаданной длиной. Тогда и чанки будут читаться кусочками, и сборка будет мягкой и шелковистой. Зачем например тащить в память весь гиговый файл, если его можно на диск кусками писать?
     
  • 3.225, Омномним (?), 16:04, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И чего?
    У меня сейчас допустим есть асинхронная корутинная реализация HTTP на PHP.
    Она вполне себе клиенту что хедеры, что контент в обе стороны отдаёт кусками - через эксплицитный запрос на чтение. Кусками читает с сокета, кусками парсит (попутно применяя лимиты на те же хедеры, чтобы многомегабайтный хедер не скушать), и кусками же отдаёт по readHeader() / readHeaders() / readContent(). Клиент сам решит, что делать с очередным куском - буферизовать или свалить куда-либо.
     
     
  • 4.226, Омномним (?), 16:11, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А для универсальности там же есть - readAllHeaders() / readFullContent(), первое читает с лимитом, второе - когда длина контента клиенту уже известна, и клиент хочет всё целиком. Внутри это просто обвязка к вышеупомянутым.
     
  • 2.247, Аноним (248), 21:21, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D

    Бугагашно, читать дальше заголовка местные Воены Супротив Раста так и не научились?
    https://docs.rs/hyper/latest/hyper/body/fn.aggregate.html


     
  • 2.265, Аноним (267), 23:32, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А ты по ссылочке-то пробовал пройти?

    This may require copying the data into a single buffer. If you don’t need a contiguous buffer, prefer the aggregate function.


    С английского перевести, или сам осилишь буковки?

     

  • 1.191, анон (?), 12:29, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Пациенты клиники Кащенко в комментах в полном сборе.

    "Но вы же гаварили что в расте нет проблем а тут праблемка ихихихихихих" - пишут они на разный лад в новости про задокументированное поведение http библиотеки.

     
     
  • 2.200, Вы забыли заполнить поле Name (?), 13:02, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано. А из какой клиники сами будете?
     
     
  • 3.202, Прохожий (??), 13:05, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано

    Ещё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось. Подозрительно много.

     
     
  • 4.286, Вы забыли заполнить поле Name (?), 01:24, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано
    > Ещё один сравниватель Си с реализацией конкретной библиотеки. Как-то много вас развелось.
    > Подозрительно много.

    Подозрительно много тут только твоих комментариев.

     
  • 3.203, анон (?), 13:07, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты читать умеешь? Проблема в библиотеке ебтвм, можешь форкнуть и поправить если хочешь. Но больные люди видят ключевое слово "раст" и ну никак не могут сдержаться.
     
     
  • 4.205, Аноним (205), 13:16, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > можешь форкнуть и поправить если хочешь

    Новаторство в борьбе с уязвимостями.

     
  • 4.209, Прохожий (??), 13:36, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очевидно, и читать, и писать он умеет. А вот с осмысливанием прочитанного у него явные проблемы, как и у 90 процентов здешних комментаторов.

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

     
  • 4.256, freecoder (ok), 22:46, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Строго говоря, это не проблема библиотеки Hyper, это проблема тех нескольких серверов, которые её лениво используют. В Hyper есть возможность как читать все в один присест, так и читать кусками. На выбор вызывающей стороны. Просто кто-то сделал неверный выбор.
     
     
  • 5.340, Омномним (?), 20:49, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У чтения в один присест должны быть лимиты.
    Потому что всем, кроме хрустоманов, очевидно, что доступная память - не резиновая.
     
     
  • 6.353, freecoder (ok), 15:27, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Еще скажите, что у обращения по индексу всегда должна быть проверка выхода за границы. Потому что размеры буфера не бесконечны.
     
     
  • 7.374, Омномним (?), 10:44, 18/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Только в случае, если индекс зависит от пользовательского ввода.
    Проверять границы буфера во внутреннем обходном цикле - так себе затея :D
     
     
  • 8.375, freecoder (ok), 12:31, 20/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В цикле и так будет проверка на каждом шаге условия достижения конца цикла Чтоб... текст свёрнут, показать
     
     
  • 9.376, Омномним (?), 21:02, 20/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проверка на каждом шаге условия Ну удачки, чего ... текст свёрнут, показать
     
  • 9.377, Омномним (?), 21:13, 20/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Есть допустим у меня кадр 7680x4320 Мне его надо вдоль и поперёк обработать, ... текст свёрнут, показать
     
     
  • 10.378, freecoder (ok), 21:23, 21/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ваше предыдущее сообщение было про цикл Как вы себе представляете цикл без пров... текст свёрнут, показать
     
     
  • 11.379, Омномним (?), 09:39, 22/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Между проверкой условия выхода и проверкой границ есть небольшая разница, не ... текст свёрнут, показать
     
  • 2.214, Аноним (214), 14:38, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мы(пациенты) смеемся не с новости, а с ваших попыток оправдаться. Особенно смешно это читать после ваших набегов на темы вида "Уязвимость в коде на Си в проекте Х...", где каждый писал что-то в духе
    >ряяя дырявая сишка, швятой хруст бы помог

    хотя разрабы просто забыли поставить сравнение и патч выглядел в одну строчку. Пытался найти ссылку на эту тему, но наткнулся на другую:
    https://www.opennet.ru/opennews/art.shtml?num=56551

     
     
  • 3.215, анон (?), 14:46, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Ваших попыток оправдаться

    Понятно.
    Этого пока рано выписывать.

     
     
  • 4.216, Аноним (214), 14:51, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Понятно.

    А разве это не так?
    Происходит жирный наброс в духе "Ха, самый безопастный язык не помог, растаманы слились"
    И тут же десятки опрадвний на это сообщение:
    >Ряяя вы ничего не понимаете, раст не виноват
    >тупые сишники, ряяя
    > пук-среньк, это библиотека виновата
    > и т.д.

     
     
  • 5.227, Анонимусс (?), 16:15, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Какие оправдания? Это (безуспешные) попытки объяснить недалеким, что вообще-то так оно и должно работать. Если в мануале написано что rm -rf удаляет папку и проверьте что вы туда передаете, чтобы не сжечь свой стул, то те кто это не делают ССЗБ.

    Разве эти можно сравнить с оправданиями при разыменовании null или при очередном выходе за границы массива с получением рута? Хотя в последнем случае, оправдаться пытаються только самые клинические сишники...

     
     
  • 6.230, Аноним (214), 16:23, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Какие оправдания?

    Которые ты написал...

     
  • 3.255, freecoder (ok), 22:43, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы убедиться, что в том случае растоманы действительно были неправы (если они такое писали), нужно найти новость и понять, не вызывала ли подобная ошибка сравнения в С далее обращение к уже освобожденной памяти или к выходу за пределы буфера. Сама по себе логическая ошибка сравнения может быть допущена как в Rust, так и в С. Но важен также контекст и последствия, к которым приводит эта ошибка: возможно в Rust действительно просто не было бы смысла/возможности писать такой код, который бы привел к порче памяти из-за подобной логической ошибки.
     
  • 2.219, Аноним (219), 15:49, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А у тебя как всегда сишники виноваты.
     
  • 2.292, Аноним (294), 11:41, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Пациенты клиники Кащенко в комментах в полном сборе.

    Тут согласен, пациенты клиники Кащенко пишут, что чтобы избегать какой-то тип ошибок нужен новый язык

     
     
  • 3.304, Аноним (300), 14:16, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То ли дело молиться, что всё порешают линтеры, санитайзеры, да прямые руки.
     
     
  • 4.314, Аноним (314), 16:01, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Толи дело написать язык, на котором ничего невозможно написать.
     

  • 1.217, Аноним (217), 14:55, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хах растобезопасность снова превратилась в тыкву
     
     
  • 2.254, freecoder (ok), 22:37, 07/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Безопасность Rust'а? Или безопасность Hyper? Или безопасность Axum, Salvo и conduit-hyper? Перечитайте новость внимательно.
     
  • 2.324, freecoder (ok), 17:23, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Хах растобезопасность снова превратилась в тыкву

    Какая именно безопасность? Боров-чекер перестал работать?

     

  • 1.253, freecoder (ok), 22:35, 07/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати, новость написана правильно. А вот комментаторы неверно интерпретируют сказанное. Тут нет уязвимости в Rust, даже нет уязвимости в Hyper. Но есть уязвимость в нескольких проектах, построенных на Hyper.
     
     
  • 2.328, anonymous (??), 18:21, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ваш растопроект вылетел в DoS из-за непроверки входных данных? Знаете кто виноват? Нет, не Раст, который декларировал безопасность работы с аллокацией, и не Hyper, который не делает проверок входных данных, но только документирует это. Виноваты ВЫ - потому что доверились сказкам растоманов про безопасность кода и выключили голову, когда писали свой проект, опираясь на библиотеку, которая в перекладывает проверки на клиента.
     
     
  • 3.332, freecoder (ok), 20:09, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Rust и растоманы нигде не обещают избавления от логических ошибок. Те гарантии, которые давал Rust, он их не нарушил: никакой гонки не произошло, никто не вышел за пределы буфера, не обратился к неинициализированной памяти и пр. Остальное - это уже ваши додумки и домыслы тех, кто Rust и не видел вовсе, и даже дня на нем не программировал, судя по всему.
     
     
  • 4.354, Аноним (294), 16:12, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Прикол в том, что в Расте вероятность совершить логическую ошибку повышается из-за того, что даже простейший код раздувается до ненормальных размеров. Это не говоря уже о том, что приходится структурировать код не в угоду читабельности, а чтобы угодить компилятору. Ну и не стоит забывать про сумасшедший синтаксис
     
     
  • 5.356, freecoder (ok), 20:28, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Код раздувается из-за того, что развитая строгая типизация требует больше явных проверок и обработки всех веток на месте. Из-за этого же наоборот, вероятность совершить ошибку понижается.

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

     
     
  • 6.357, Аноним (294), 20:33, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я говорю о ЛОГИЧЕСКИХ ошибках
     
     
  • 7.361, freecoder (ok), 14:01, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так я тоже о них говорю. Обработка не всех вариантов - в общем случае ведет к логическим ошибкам.


     
  • 3.349, Аноним (349), 14:03, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    +1. Причём "растаманить" на их неуклюжем языке в 2 раза сложнее и они это оправдывали повышенной безопасностью. Так накой мне лишний геморой, если всё равно раст дырявый?!
    Даже С++ со смарт указателями стократ надёжнее.
     
  • 2.346, Аноним (307), 11:31, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вызвать команду на загрузку всех данных в память и обвинять язык в том что память закончилась это какой-то особый способ идиотизма.

    Вывод. Не верь сказкам растоманов и джаваманов о том что их языки безопасные. Пиши на ANSI C где даже элементарные арифметические операции продолжают неопределенное проведение.

     
     
  • 3.360, Аноним (228), 12:37, 10/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > элементарные арифметические операции продолжают неопределенное проведение

    болобол

     

  • 1.282, Аноним (90), 00:49, 08/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Когда новость про ошибки в программах на расте не связаны с самим растом, у наСИльников особенно ярко и гулко полыхает. Что только подкидывает в копилку надежности и нужности раста: вот, очередная ошибка! ан нет, не переполнение буфера, не обращение к невыделенной/освобожденной памяти, не двойное освобождение. Это пока не пропускается, если только с сишным легаси не взаимодействует. Просто знаки больше-меньше перепутали или входные данные не проверили. Отрадно. Так держать. Не, понятно, никто не безгрешен, наверное раз в пятилетку проблемы с памятью и от самого раста будут находить, но я готов это терпеть.
     
     
  • 2.287, Аноним (287), 01:50, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не очень на пятилетку похоже(удивительно как много ошибок в стандартной библиотеке и тулчейне):
    https://www.opennet.ru/opennews/art.shtml?num=55167
    https://www.opennet.ru/opennews/art.shtml?num=55607
    https://www.opennet.ru/opennews/art.shtml?num=56551
    https://www.opennet.ru/opennews/art.shtml?num=57787
    Ну и хотите верьте, хотите нет, но мне не будет легче если программа просто упадет, займет всю память или даст рут-доступ, но ЗАТО безопастно и не портя память.
     
     
  • 3.293, Аноним (47), 11:43, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно верим, потому что сразу видно админа локалхоста...
    Тебе будет легче если она не упадет и продолжить работу, но при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?
     
     
  • 4.318, Аноним (318), 16:57, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?

    А что мешает это сделать из под раста, если возможность получения рут-доступа никуда не исчезла?

     
     
  • 5.323, freecoder (ok), 17:21, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как получить рут-доступ, если сервер замедлился или упал из-за перерасхода памяти?
     
     
  • 6.325, Аноним (318), 17:37, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https www opennet ru opennews art shtml num 55607 https www opennet ru openn... большой текст свёрнут, показать
     
     
  • 7.331, freecoder (ok), 20:05, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Эти случаи уже много раз обсудили, обмусолили и сделали выводы. Давайте здесь обсуждать тему топика и не перескакивать, а то иначе не понять, кто что имеет ввиду и о каких проблемах вообще говоря речь. Проблема, вызванная отсутствием проверки реального объема загружаемых данных и попыткой резервировать большой кусок памяти, никак не приведет к повышению привилегий в системе.
     
     
  • 8.341, Аноним (341), 23:35, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Классика ... текст свёрнут, показать
     
  • 2.291, Аноним (294), 11:39, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нужен новый язык. Раст решает не все проблемы
     
     
  • 3.322, freecoder (ok), 17:20, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Новый будет создан на основе Раста и с учетом его преимуществ и недостатков. Ещё не скоро.
     
     
  • 4.350, Аноним (351), 15:03, 09/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Rust with classes, Objective-Rust, Rust++
     
  • 2.312, Аноним (314), 16:00, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ещё в сортах уязвимость разбираешься? Типа когда тебя взломают через неправильный знак это что будет смягчающем обстоятельством? Да пофиг тебе уже взломали.
     

  • 1.290, Аноним (294), 11:38, 08/01/2023 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +1 +/
     
     
  • 2.311, Аноним (314), 15:57, 08/01/2023 Скрыто модератором
  • +/
     
  • 2.316, Вы забыли заполнить поле Name (?), 16:17, 08/01/2023 Скрыто модератором
  • +/
     
  • 2.321, freecoder (ok), 17:18, 08/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 3.337, Ыыыыыы (?), 20:25, 08/01/2023 Скрыто модератором
  • –1 +/
     
     
  • 4.352, freecoder (ok), 15:23, 09/01/2023 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (5)

  • 1.305, Карбон лучший (?), 14:35, 08/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Когда же вы поймёте что самый безопасный язык это Carbon
     
     
  • 2.309, Аноним (314), 15:56, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда пройдет фанатизм == никогда.
     
  • 2.338, Ыыыыыы (?), 20:27, 08/01/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не ври, most wanted лучше!
     

  • 1.348, Аноним (349), 14:00, 09/01/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данных

    Что и требовалось доказать: баги полностью зависят от криворуких погромиздов, язык не причём.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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