The OpenNET Project / Index page

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



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

"Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от opennews (??), 06-Янв-23, 21:28 
В библиотеке Hyper, предлагающей реализацию протоколов HTTP/1 и HTTP/2 на языке Rust, выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании  через исчерпание доступной процессу памяти. Для эксплуатации уязвимости достаточно отправить специально оформленный HTTP-запрос уязвимому обработчику, использующему Hyper. Библиотека достаточно популярна (67 млн загрузок) и используется в качестве зависимости у 2579 проектов, представленных в каталоге crates.io...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58444

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

Оглавление

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

1. Сообщение от Аноним (1), 06-Янв-23, 21:28   +5 +/
Шах и мат
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54, #72, #90

2. Сообщение от ПомидорИзДолины (?), 06-Янв-23, 21:35   +16 +/
Ожидаемое поведение, в документации все описано.

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #27, #68, #145

3. Сообщение от ПомидорИзДолины (?), 06-Янв-23, 21:38   +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.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #17, #73

4. Сообщение от Аноним (4), 06-Янв-23, 21:39   +13 +/
Безопасность не поместилась в оперативную память
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

6. Сообщение от Аноним (228), 06-Янв-23, 21:47   +/
> Rust
> выявлена особенность работы с памятью, которая может использоваться для инициирования отказа в обслуживании
> достаточно отправить специально оформленный HTTP-запрос

Ок, ясно

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

7. Сообщение от Аноним (228), 06-Янв-23, 21:49   +2 +/
> копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данных

Растоманы, что с лицом?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #231

8. Сообщение от pashev.ru (?), 06-Янв-23, 21:51   +1 +/
Всё правильно. Ещё со времён Юниксов и Си правильно. Программа или библиотечная функция должа делать ровно одну задачу и делать её хорошо. Проверка входящих параметров — это отдельная задача. Если она не нужна, зачем за неё платить? Это кстати, часть философии Раста.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #42

9. Сообщение от Alladin (?), 06-Янв-23, 21:53   –1 +/
как же тупо, тупо никаких ограничений на выделение по "Content-Length"...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #103

10. Сообщение от Аноним (228), 06-Янв-23, 21:54   +2 +/
боров-чекер оказался слишком жирным боровым и не влез в оперативку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #15

12. Сообщение от Аноним (133), 06-Янв-23, 22:10   –10 +/
Всё верно,товарищ.
Проверки выхода за границы массива - тоже отдельная задача.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #101

15. Сообщение от Alladin (?), 06-Янв-23, 22:29   +/
борров чекер проверяется и работает на этапе компиляции в скомпилированном коде он потребляет 0, вы белину сьели?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #19, #23

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #25

19. Сообщение от Аноним (228), 06-Янв-23, 23:07   +/
Я знаю что это такое, просто мне слово нравится... боров
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #43

20. Сообщение от Аноним (20), 06-Янв-23, 23:11   +/
Чудесное определение — "особенность работы с памятью". Запомню.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #351

21. Сообщение от Аноним (228), 06-Янв-23, 23:12   +2 +/
Сишник забывает очистить память в указателе
растоман: диды писали, надо переписать на раст

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #107

22. Сообщение от Аноним (25), 06-Янв-23, 23:16   –2 +/
Помнится си критиковали за то что программисту нужно слишком много думать и знать и о многом заботиться. И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось, зато мелкософт и гугл (текущих владельцев раста) захватили ещё немного влияния.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30

23. Сообщение от Аноним (228), 06-Янв-23, 23:16   +/
я может что-то не понимаю, но раст с кучей не умеет что ли работать? Если на этапе компиляции, то как он выполняет эти ваши боровы-чекеры с аллоцированной в рантайме памятью?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #49

24. Сообщение от Аноним (24), 06-Янв-23, 23:22   +6 +/
>> Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера, но предупреждение игнорировалось в различных продуктах
> Растоманы, что с лицом?

Воены Супротив Раста, что с чтением новости дальше первого абзатца?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #36

25. Сообщение от Аноним (25), 06-Янв-23, 23:24   +/
Можешь как угодно называть уязвимость (ниже уже назвали "задокументированным поведением"), как угодно критиковать архитектуры и как угодно выставлять диагнозы опеннетчикам, но отказ в обслуживании это не исправит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #194, #240

26. Сообщение от Аноним (29), 06-Янв-23, 23:25   +5 +/
> растоман: забывает проверить входные данные и вообще весь ответ целиком копирует в буфер.

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

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #28

27. Сообщение от Аноним (25), 06-Янв-23, 23:26   +1 +/
Так и в си UB описаны, необходимость проверок тоже. Но почему-то в си это фатальный недостаток, а в расте "задокументированное поведение".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #35, #104

28. Сообщение от Аноним (228), 06-Янв-23, 23:27   –1 +/
UB в ANSI C тоже задокументировано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #45

29. Сообщение от Аноним (29), 06-Янв-23, 23:28   +1 +/
> как же тупо, тупо никаких ограничений на выделение по "Content-Length"...

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #31, #80, #198, #241

30. Сообщение от Аноним (30), 06-Янв-23, 23:32   +3 +/
>>  Примечательно, что указанное поведение явно описано в документации, в которой рекомендуется выполнять отдельные проверки размера
> И что раст сейчас придёт и возьмёт всё на себя. Но чуда не случилось

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #164

31. Сообщение от Аноним (228), 06-Янв-23, 23:33   –1 +/
Очевидно, так как растоманы решили - чтоб отказ в обслуживании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #44

35. Сообщение от Аноним (35), 06-Янв-23, 23:40   +2 +/
> Так и в си UB описаны, необходимость проверок тоже.

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

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

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

36. Сообщение от Аноним (36), 06-Янв-23, 23:41   –1 +/
А что там?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #47

38. Сообщение от Аноним (38), 06-Янв-23, 23:42   +1 +/
У Си уязвимости, а у Раста ОСОБЕННОСТИ работы с памятью, понимать надо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #252

41. Сообщение от Dzen Python (ok), 06-Янв-23, 23:44   +/
Говори толерантнее, иначе к тебе приедет айнзац-команда и до реанимации будет учить тебя политкорректности: у раста не особенности, у раста ЗАДОКУМЕНТИРОВАННОЕ ПОВЕДЕНИЕ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #61, #169

42. Сообщение от Dzen Python (ok), 06-Янв-23, 23:48   +/
Так если подумать и реализовано неправильно.
Если заведомо нет проверок на длину сырых (задача обработки и формирования буфера ДОКУМЕНТИРОВАНО возложена на приложение, вызывающее функцию) данных, значит функция просто обязана обрезать данные по внутреннему буферу, беря первые MAX_BUF_SIZE байт, остальное отбрасывая.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #52

43. Сообщение от Dzen Python (ok), 06-Янв-23, 23:57   +/
Проверяльщик боровов, дядь. Который при компиляции бегает между каждым боровом и смотрит им...хм, пусть будет в пятачок, чтобы не залезли боровы и рылом дырок-уязвимостей не нарыл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

44. Сообщение от Аноним (44), 06-Янв-23, 23:59   +1 +/
> Очевидно, так как растоманы решили - чтоб отказ в обслуживании.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #46

45. Сообщение от Аноним (248), 07-Янв-23, 00:00   +/
>> Checking the Content-Length is a possibility, but it is not strictly mandated to be present.
> UB в ANSI C тоже задокументировано.

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

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

46. Сообщение от Alladin (?), 07-Янв-23, 00:37   –2 +/
я и сам никогда не ориентировался на content-length, прислушивался но не ориентировался
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от Аноним (47), 07-Янв-23, 00:39   +2 +/
А там читать доку нужно уметь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

48. Сообщение от Анонн (?), 07-Янв-23, 00:57   +6 +/
Мда, это даже смешно.
Это поведение не только записано в доке, там даже пример есть с комментом "// Just to protect ourselves from a malicious response"

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

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

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

49. Сообщение от Прохожий (??), 07-Янв-23, 01:18   +/
Компилятор не проверяет, сколько именно памяти есть в системе - это не его задача. Он проверяет, чтобы висячие ссылки не появлялись, чтобы use-after-free не происходило. Конечно же Rust умеет работать с кучей, но он не всемогущ, как некоторые ошибочно полагают. В нём по-прежнему возможны разные ошибки (в том числе утечка или переполнение памяти). В чём же смысл тогда, кто-то может спросить? В том, что Rust предотвращает наиболее распространённые ошибки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #53

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #69, #246

53. Сообщение от Проффесорemail (?), 07-Янв-23, 01:45   –1 +/
... способствует программисту потерять бдительность
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #56, #363

54. Сообщение от Прохожий (??), 07-Янв-23, 01:46   –1 +/
Ох уж эти голуби...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #154

55. Сообщение от Проффесорemail (?), 07-Янв-23, 01:48   +/
ой как интересно получилось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #62

56. Сообщение от Прохожий (??), 07-Янв-23, 01:48   +1 +/
Не способствует, а освобождает программиста от слежения за определённым классом ошибок, позволяя ему сосредотачиваться на других вещах, более полезных и продуктивных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #60, #123

60. Сообщение от Проффесорemail (?), 07-Янв-23, 01:55   +/
Способствует. Более того: создает впечатление у новичков что программирование - это очень просто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #67

61. Сообщение от Прохожий (??), 07-Янв-23, 01:57   +/
Эх, видимо, рано я порадовался за питониста. Эй, питонист. Не у Раста, а в стандарте такое поведение. Надеюсь, ты понимаешь разницу между стандартом и языком программирования? Или я опять слишком многого прошу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #112

62. Сообщение от Прохожий (??), 07-Янв-23, 01:59   –1 +/
Ой какой длинный список получается
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

67. Сообщение от Прохожий (??), 07-Янв-23, 02:11   +/
Скажем так, у слабых разумом такое может случиться. Но мы ж о нормальных, правда?

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #121

68. Сообщение от kai3341 (ok), 07-Янв-23, 02:14   +1 +/
> Ожидаемое поведение, в документации все описано.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #75, #160

69. Сообщение от Аноним (228), 07-Янв-23, 02:15   –2 +/
В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #71

71. Сообщение от Прохожий (??), 07-Янв-23, 02:28   +1 +/
> В стандартах на протоколы не пишут, что можно делать use-after-free, что память должна течь и тп. Дак какие претензии к сишника? Или это другое?

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #87

72. Сообщение от Аноним (72), 07-Янв-23, 02:30   –1 +/
Как будто Си-макаки читают документацию и пишут скучные проверки. Только в сишке подобный "тяп-ляп-в продакшн" бы привел к RCE, а не к исчерпанию памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #74, #76

73. Сообщение от Аноним (72), 07-Янв-23, 02:32   +3 +/
>Care needs to be taken if the remote is untrusted.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #125, #148

74. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:33   +/
Я всегда делаю проверки, особенно параллельно разрабатывая на Го привычка выработалась. А документацию на что? У нас же нет миллионов импортов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #77, #78

75. Сообщение от Аноним (228), 07-Янв-23, 02:34   +/
Почикает нгиннкс на С
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

76. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:34   +1 +/
И называть макакими сишников это отчаяние. Всех тех, кто всю твою жизнь и до твоего существования всё это нынешнее рабочее разработал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #81, #234

77. Сообщение от Прохожий (??), 07-Янв-23, 02:36   +1 +/
> Я всегда делаю проверки

А причём здесь ты?

> У нас же нет миллионов импортов.

Каждый раз велосипед с нуля изобретаете, что ли?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #79, #83

78. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:36   +/
Нам проще написать leftpad, чем подключать заголовок или добавлять в сборку либу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #85

79. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:37   +/
Это язык системного уровня. А не одно название языка ногами запиханное в ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #82

80. Сообщение от Аноним (72), 07-Янв-23, 02:37   –2 +/
Очевидно: библиотека должна посмотреть размер свободной памяти на машине, помножить на коэффициент нехило меньше 1 (напр. 0.25), далее помножить на (1. - 0.005 + random(0.01)), и такое ограничение и выставить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #93, #190, #238

81. Сообщение от Прохожий (??), 07-Янв-23, 02:37   +/
> всё это нынешнее

дырявое и дорогое в конечной эксплуатации по этой причине. Низко кланяюсь (нет).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #228

82. Сообщение от Прохожий (??), 07-Янв-23, 02:39   +1 +/
> Это язык системного уровня.

Это сплошная дыра системного уровня. Костыль, которому давно пора на свалку, потому что с нынешней сложностью По он уже явно не справляется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #84, #86

83. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:39   +/
Документацию читать надо уметь, т.к. метод тыка в Си не работает. Макаки это когда стэковерфлоу программинг, галопом по европам запихнуть, скомпилилось и дальше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #94

84. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:40   +/
Это у вас в мозгах сложность. Buttplug можно и на Си делать, только никому в голову не пришло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #88

85. Сообщение от Прохожий (??), 07-Янв-23, 02:40   +/
А бедные пользователи должны платить потом за эту "простоту". Гениально, чего уж.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #89

86. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:41   +1 +/
Это ж как 40 лет костыль работу всей мировой техники обеспечил? Революционеры малолетние.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #91, #102

87. Сообщение от Аноним (72), 07-Янв-23, 02:42   +/
Претензии к растоманам, питонистам и JS/TypeScript-ам (не всем!) простые - они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #106

88. Сообщение от Прохожий (??), 07-Янв-23, 02:42   +/
Это не у меня в мозгах сложность. Это очевидный и хорошо задокументированный факт, подтверждённый разными независимыми источниками. А вот ваши высказывания - да, их происхождение обусловлено исключительно вашим ограниченным представлением о современном ПО.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

89. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:42   +/
Ты видишь текст новости? Там макаки не глядя запихали свою простоту, ведь великий и могучий канпилятор позволяет не думать ни о чем, а кратеры позволяют собирать как лего (у вас в детстве уже существовало лего или еще нет?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #95, #96

90. Сообщение от Аноним (90), 07-Янв-23, 02:43   +/
Да, шах и мат сишникам. Ибо ещё раз доказывает, что "70% ошибок" исключает (в safe-режиме), а на оставшиеся 30% включай голову - domain-бизнес-логику за тебя язык не напишет и документацию к продукту не прочтет. Плюс в карму расту. Разве что с циклическими ссылками надо быть осторожным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #139

91. Сообщение от Прохожий (??), 07-Янв-23, 02:43   –1 +/
> Это ж как 40 лет костыль работу всей мировой техники обеспечил?

Мягко скажем, очень и очень плохо. Хотя люди старались, да.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #155

93. Сообщение от Аноним (330), 07-Янв-23, 02:46   +1 +/
А что если на машине 64гб рам, а в слайсе сигруппы приложению выделили всего 256мб рам?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #99

94. Сообщение от Аноним (72), 07-Янв-23, 02:48   +/
А откуда, сишные дырени (тм) берутся? Нет, метод тыка везде работает. Особенно в сложных системах, написанных с запасом избыточности. Так что ты можешь и не узнать, что система работает, но не по той спецификации "на неё", что у тебя в голове.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #124

95. Сообщение от Прохожий (??), 07-Янв-23, 02:48   +/
Я вижу. Но не только вижу, а ещё и анализирую. Макаки есть в любой сфере, от них нельзя оградиться. Но причём тут язык программирования? Никто никогда не говорил, что данный конкретный компилятор защищает от любого класса ошибок. Если ты, или тебе подобный, почему-то представлял в своём воображении иначе - у меня есть способ, как это исправить - RTFM до посинения.

> у вас в детстве уже существовало лего или еще нет?

Нет, я родом из СССР. Было, скажем так, подобие Лего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #180

96. Сообщение от Аноним (72), 07-Янв-23, 02:49   +/
Как будто сишники делают иначе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

99. Сообщение от Аноним (72), 07-Янв-23, 02:52   –1 +/
а приложение в этой группе, когда дёрнет API, увидит, что у неё доступно для выделения 64 гига?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #136

101. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:53   –3 +/
> Проверки выхода за границы массива - тоже отдельная задача.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #132, #150

102. Сообщение от Прохожий (??), 07-Янв-23, 02:53   +/
> Революционеры малолетние.

О, давай приборами меряться. Мне шестой десяток пошёл уже. А тебе?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #129, #170

103. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:55   +/
Это норм. Просто макакинг-девелопмент
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

104. Сообщение от Аноним (90), 07-Янв-23, 02:55   +4 +/
>  а в расте "задокументированное поведение".

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #157

106. Сообщение от Прохожий (??), 07-Янв-23, 02:56   –1 +/
>  они карго-культисты, которые делают сумасшедшие вещи только потому, что какой-то сумасшедший либо за них решил, дибо им порекомендовал так делать.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #117

107. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 02:57   –1 +/
Да нее, тут опять сишники виноваты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #211

112. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:01   –2 +/
Способность обращаться по любому адресу памяти это нормальное поведение кода, исполняющегося на процессоре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #122, #259

117. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:09   –1 +/
свайпай дальше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #178

121. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:12   +/
Какой же ты тупой. Это не архитектурный изъян. Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #134

122. Сообщение от Прохожий (??), 07-Янв-23, 03:13   +/
С точки зрения процессора - да, нормальное. А с точки зрения программиста, который в здравом уме находится - нет, не всегда это нормально, и часто это надо пресекать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

123. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:15   –1 +/
Так таким значит надо писать на Java, Go, Dart, C#, JS наконец с Питоном -- вы же бизнес-логику прикладную пишете? Или у вас комплекс называться системным языком, зачем лезете к железу близко, но при этом избегаете его? Это как девочки у вас в вебкамах -- на расстоянии только, а IRL Buttplug и единороги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #135

124. Сообщение от Аноним (133), 07-Янв-23, 03:15   +/
Да тут нет С программистов, тут одни админы которые, как я понял воюют за "тру".

Откуда им знать про документацию, он её и в глаза то не видел.

А если бы реально читал линуксовые маны, то знал бы что чтобы их хотя бы в целом понять надо раз 10 прочитать. И вчитываться в каждую буковку, в каждую запятую.

99% С-программистов так не делают, иначе писали бы по 10 строчек (корректных) в день. И этих чтецов нахрен бы повыгоняли.

Моё любимое - любой системный (и libc-шный) вызов может завершиться неудачей (быть прерван) и, даже для read нужно организовывать цикл со 2-3 условиями (всё прочитал, прочитал часть, и прерван - перечитать).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #158

125. Сообщение от ПомидорИзДолины (?), 07-Янв-23, 03:15   +/
Нет. Remote может быть nginx в режиме reverse proxy, который сделает все проверки за тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

129. Сообщение от Свидетель ржавоговы (?), 07-Янв-23, 03:22   –1 +/
А где ты был, почему раст не изобрел? ведь 60 лет назад любой чел мог в гараже зачать мировое лидерство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #130

130. Сообщение от Прохожий (??), 07-Янв-23, 03:26   +/
У тебя с головушкой всё в порядке? Или после НГ никак отойти не можешь?

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

Мне не 60 лет. Мне шестой десяток пошёл. У тебя и с математикой нелады. Теперь понятно, почему ты так новому сопротивляешься. Что ж, мне жаль.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #133

132. Сообщение от Аноним (133), 07-Янв-23, 03:31   –2 +/
Тыкну тебя в единственный по-настоящему системный язык программирования. Он называется Zig.

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

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

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

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #162

133. Сообщение от Аноним (133), 07-Янв-23, 03:41   +/
Это тот который "документацию читать надо, и не будет ошибок".

Но так и не смог прочитать "6ой десяток" и отличить от "60 лет". И что-то там ещё втирает про чтение документации и неделание ошибок.

В двух словах потерялся. Рановато тебя к Сишной документации допускать. Тебе только Python пока выписываю. Приходи после Computer Science 101.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #138, #144

134. Сообщение от Прохожий (??), 07-Янв-23, 03:41   +/
> Это не архитектурный изъян.

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

> Такими словами можно сказать интелам и амд с ARM -- почему вы на уровне ядер и конвеера кода позволяете обращаться не туда?

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

> Какой же ты тупой.

Ты ни в зуб ногой о современных способах разработки ПО, а тупой - я. Говорю же, ты забавен. :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #237

135. Сообщение от Прохожий (??), 07-Янв-23, 03:48   +/
> Так таким

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

> Java, Go, Dart, C#, JS наконец с Питоном --

Эти все языки придумали не от хорошей жизни. Люди осознали, что надо что-то делать с дыренями Си, и сложностью Плюсов.

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

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

> Это как девочки у вас в вебкамах

Какие девочки, у кого у вас? Ты точно трезвый?

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

136. Сообщение от Аноним (133), 07-Янв-23, 03:49   +3 +/
Какая нахрен разница, в С / libc / Linux нет реального выделения памяти. Выделяй на выделяй всё равно получишь...

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #297

138. Сообщение от Аноним (138), 07-Янв-23, 03:57   –1 +/
школоте не спится на каникулах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

139. Сообщение от Аноним (138), 07-Янв-23, 04:00   +/
вижу "шах и мат" - ставлю минус. где шах, где мат, ты хоть правила знаешь или только конём могёшь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #192

141. Сообщение от Аноним (-), 07-Янв-23, 04:04   +/
> на языке Rust, выявлена
> особенность работы с памятью

Да ну ладно?!

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

143. Сообщение от Аноним (138), 07-Янв-23, 04:06   –1 +/
When lights go down, I see no reason
For you to cry, we've been through this before
In every time, in every season
God knows I've tried
So please don't ask for more

Can't you see Rust in my eyes?
That this might be our last goodbye
Caa-arbon
Caa-arbon
Things they change my friend, whoa oh
Caa-arbon
Caa-arbon
Maybe we'll meet again
Somewhere, again

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #146, #260

144. Сообщение от Прохожий (??), 07-Янв-23, 04:07   +/
Э-э-э, ты кому это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

145. Сообщение от MaleDog (?), 07-Янв-23, 04:07   +1 +/
Я бы сказал безмозглое поведение - выделять оперативную память под запрос целиком на основе "Content-Length". Рустоманы так упоролись на том чтобы всем доказать "безопасность работы с памятью", что их поделие заболело детскими болячками Apache. Так скоро LOIC опять станет актуален.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #149, #176, #267

146. Сообщение от Прохожий (??), 07-Янв-23, 04:12   +2 +/
Напомни, пожалуйста, какая текущая версия у Carbon? Мне гуглить лень, честно признаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

147. Сообщение от Прохожий (??), 07-Янв-23, 04:12   +1 +/
Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы мог подумать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #156, #232

148. Сообщение от Аноним (148), 07-Янв-23, 04:13   +8 +/
Это же библиотека для сборки из кирпичиков, а не полнофункциональный сервер. А лимит понятие относительное. На видеохостинге он обычно чуть больше, чем на смарт-часах.

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

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

149. Сообщение от MaleDog (?), 07-Янв-23, 04:15   +/
Еще поди можно так:
- кидаем много запросов с небольшим Content-Length, но с телом усеченным до нуля и одного байта.
- сервер выделяет под них память, но освобождает ее с лагом, так как ждет нужное количество байт которых нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #161

150. Сообщение от Прохожий (??), 07-Янв-23, 04:20   +3 +/
> Но раст не дотягивает до крестов.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #277

154. Сообщение от Аноним (-), 07-Янв-23, 06:03   –1 +/
> Ох уж эти голуби...

Вы научили голубей играть в шахматы? О...еть, дайте две!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #189

155. Сообщение от Аноним (-), 07-Янв-23, 06:04   –1 +/
> Мягко скажем, очень и очень плохо. Хотя люди старались, да.

Ну ты то пока и так не смог, так что чья бы мычала. Хотя нагадить под себя у таких как ты норма, конечно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #172

156. Сообщение от Аноним (-), 07-Янв-23, 06:05   –1 +/
> Ещё один подражатель Евгения Вагановича. Такая популярная на Опеннете личность, кто бы
> мог подумать.

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

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

157. Сообщение от Аноним (25), 07-Янв-23, 08:55   –1 +/
Ну пошли отмазки. Лет 9 назад вас, растоманов, не волновало что ещё и библиотеки надо писать с новыми багами(между прочим один из аргументов сишников против раста) и вообще думать все равно придется. Наоборот, растоманы писали что "разработчики раста уже подумали за программиста". Теперь вот на ходу (последние несколько лет) меняете риторику.
Всё чем вы оправдываетесь в последнее время, всё это писали вам сишники лет 9 назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #175

158. Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:09   +/
>и прерван - перечитать

ага перечитай с битого диска, думаю там у вас while(true)

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

160. Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:13   +/
а че с чанками делать и крывыми размерами контента в заголовках?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

161. Сообщение от Sw00p aka Jerom (?), 07-Янв-23, 09:15   +/
>так как ждет нужное количество байт которых нет.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #184

162. Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 09:16   –3 +/
> Можно же было сделать такое и в С (лет 15 назад)?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #206

164. Сообщение от Аноним (25), 07-Янв-23, 09:51   –2 +/
Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".
Потом было "мы ещё сырые, но вот ещё чуток подпилим".
Сейчас вот "раст не виноват, это всё...".
Собственно всё это мы уже проходили с джавой, а единственный результат который получили это зависимость от корпораций (в данном случае гугель и мелкософт).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #177, #258

165. Сообщение от Анонимусс (?), 07-Янв-23, 10:38   +/
Вот она победа раста над древней сишкой!
Растоманы накосячили с памятью и все лишь получили DoS, а не RCE-дырень с получением рута и тыреньем всех твоих данных.
Не зря его сделали, не зря его добавили в ядро!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #166

166. Сообщение от An (??), 07-Янв-23, 10:50   –1 +/
Ну и развивали бы дальше свой победоносный redox. Нафига в сишный linux полезли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #168, #173, #186

168. Сообщение от Анонимусс (?), 07-Янв-23, 11:09   +1 +/
Потому что это будет просто преступлением оставить линукс таким дырявым какой он сейчас!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

169. Сообщение от раст переусложнён (?), 07-Янв-23, 11:12   –1 +/
>ЗАДОКУМЕНТИРОВАННОЕ

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #179

170. Сообщение от YetAnotherOnanym (ok), 07-Янв-23, 11:23   +1 +/
> Мне шестой десяток пошёл уже.

И ты до сих пор не научился сохранять холодный ум и не воспламеняться энтузиазмом по поводу любого выс*ра, который авторы объявляют спасением человечества?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #171

171. Сообщение от Прохожий (??), 07-Янв-23, 11:31   +/
Я не только этому научился за это время, а ещё и думать, анализировать. Чего не скажешь о многих из присутствующих здесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

172. Сообщение от Прохожий (??), 07-Янв-23, 11:33   +1 +/
Ну да, ну да. Сперва добейся. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

173. Сообщение от Аноним (173), 07-Янв-23, 11:36   +/
Да, просто за драйверами зашли. Сейчас с ними и уйдут обратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #187, #294

174. Сообщение от Аноним (173), 07-Янв-23, 11:37   +/
А можно написать еще хотя бы одну библиотеку для работы с HTTP, а то что-то свет клином столкнулся с этим Хайпером.
Ответить | Правка | Наверх | Cообщить модератору

175. Сообщение от Прохожий (??), 07-Янв-23, 11:41   +/
Это не отмазки. Это попытка объяснить слабым разумом, что данная конкретная ошибка не имеет никакого отношения к языку программирования. Но некоторым, что в лоб, что по лбу. Увы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #236, #264

176. Сообщение от Прохожий (??), 07-Янв-23, 11:44   +/
В данном случае упоролись всё же Воины Борьбы Супротив Раста, раз и после нескольких десятков комментариев не понимают, что данная конкретная ошибка не имеет никакого отношения к возможностям языка программирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #245

177. Сообщение от Аноним (300), 07-Янв-23, 11:48   +3 +/
> Изначально было "раст все порешает" и "программисты не будут совершать ошибки"

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

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

178. Сообщение от Прохожий (??), 07-Янв-23, 11:49   +/
Предлагаешь, каждую вспышку больного сознания комментировать? Сорри, это не ко мне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

179. Сообщение от Прохожий (??), 07-Янв-23, 11:53   +/
Тебе далеко пока до Евгения Вагановича. Тренируйся ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

180. Сообщение от Ананимаз (?), 07-Янв-23, 11:53   +/
"подобие", которое развивало фантазию, а не заставляла лепить заранее заготовленные блоки друг к другу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #185, #233

181. Сообщение от Омномним (?), 07-Янв-23, 11:54   –1 +/
Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #183, #201, #247, #265

183. Сообщение от Омномним (?), 07-Янв-23, 11:55   –1 +/
(так-то вообще школьная ошибка, чтение из сети по заданному размеру без лимитов...)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

184. Сообщение от MaleDog (?), 07-Янв-23, 12:02   +/
Выделяет столько сколько сказали. Затем он по какому-то таймауту должен понять, что столько байт ему никто передавать столько не собирается. Думаю не меньше нескольких секунд. К примеру, открыл какой-нибудь бот 1000 соединений, в каждом попросил принять 10M, и ... добрый сервер выделил боту 10G оперативной памяти? А если столько нет? Да и затраты на выделение не нулевые. Допустим через секунду бот отвалился и все соединения сброшены, а память освобождена, но что мешает боту еще "медленной записью" заняться передавая эти 10M по паре байт в секунду, тогда и таймаут не сработает и у сервера 10G оперативки будут заняты на неопределенный срок.
Выделять под буфер нужно столько памяти, чтобы обработчик запроса успевал обрабатывать без задержек(к примеру парсер JSON успевал обработать ключ и привести его значение к нужному типу), а не помещать весь запрос в оперативную память, а потом обрабатывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #330

185. Сообщение от Прохожий (??), 07-Янв-23, 12:02   +/
На самом деле, те конструкторы были практически полной копией Лего. Спионерены один к одному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

186. Сообщение от Прохожий (??), 07-Янв-23, 12:15   +1 +/
Redox - это почти домашний проект, просто чтобы убедиться, на данном языке можно писать системный софт.
Полезли в сишный Линукс, потому что последний стал очень распространённым, что означает, что каждая ошибка программиста очень дорого обходится в итоге конечным пользователям. И с этим надо что-то делать. Раст оказался как нельзя кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

187. Сообщение от Прохожий (??), 07-Янв-23, 12:17   +/
Никто уже никуда не уйдёт, не переживай. Учить язык придётся. Хотя для некоторых это может оказаться и непосильной задачей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

189. Сообщение от Прохожий (??), 07-Янв-23, 12:27   +/
Нет, это голуби вообразили, что они умеют играть в шахматы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

190. Сообщение от Омномним (?), 07-Янв-23, 12:27   –1 +/
Очевидно: чтение реквеста должно быть блочным, а не "запихать всё в память и отдать вызывающему".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #197

191. Сообщение от анон (?), 07-Янв-23, 12:29   +3 +/
Пациенты клиники Кащенко в комментах в полном сборе.

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #200, #214, #219, #292

192. Сообщение от Прохожий (??), 07-Янв-23, 12:33   +/
Я знаю. И даже когда-то (давно, на самом деле) играл на уровне первого взрослого разряда. А что не так он написал? Или надо было к чему-то придолбаться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

194. Сообщение от Прохожий (??), 07-Янв-23, 12:40   +5 +/
Проблема этой ветки обсуждения в том, что некоторые комментаторы пытаются экстраполировать человеческую ошибку пользователей библиотеки на якобы имеющиеся изъяны языка программирования.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #261

196. Сообщение от Аноним (-), 07-Янв-23, 12:49   +/
Кондуит конечный продукт, естественно у него будет меньше загрузок с сайта «библиотек», странно сравнивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

197. Сообщение от Прохожий (??), 07-Янв-23, 12:57   +/
Ты про такой протокол, как UDP и на нем основанных слышал? Знаешь, как там всё работает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #243, #244

198. Сообщение от MaleDog (?), 07-Янв-23, 12:58   +1 +/
Э-э. Выделить небольшой буфер на проверку заголовков. Передать их обработчику, чтобы тот авторизовал, проверил и сам выделил нужное количество оперативы. Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению буфера или даже раньше передавать их обработчику. Что он с ними будет делать уже его проблема, главное буфер тут нужен чтобы избежать задержек. Но точно не пытаться считать весь запрос в оперативку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #208, #248

200. Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 13:02   –4 +/
Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано. А из какой клиники сами будете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #202, #203

201. Сообщение от Прохожий (??), 07-Янв-23, 13:03   –1 +/
О великий эксперт. А где ты потом собирать будешь эти чанки? Почитай на досуге про UDP, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #210, #222, #225

202. Сообщение от Прохожий (??), 07-Янв-23, 13:05   +2 +/
>Ну то, что си по умолчанию не проверяет границы массивов тоже задокументировано

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #286

203. Сообщение от анон (?), 07-Янв-23, 13:07   +/
Ты читать умеешь? Проблема в библиотеке ебтвм, можешь форкнуть и поправить если хочешь. Но больные люди видят ключевое слово "раст" и ну никак не могут сдержаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #205, #209, #256

204. Сообщение от Прохожий (??), 07-Янв-23, 13:14   +3 +/
Не думаю, что тебе стало что-либо ясно. Но ок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

205. Сообщение от Аноним (205), 07-Янв-23, 13:16   +/
> можешь форкнуть и поправить если хочешь

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

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

206. Сообщение от Прохожий (??), 07-Янв-23, 13:19   –1 +/
Ты понимаешь разницу между специализированным ПО (которое, несмотря на все усилия, не в состоянии выловить все ошибки)  и архитектурными особенностями языка программирования, не дающими тебе совершать такие ошибки априори? Это был риторический вопрос, потому что из твоего комментария и так всё понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #262

208. Сообщение от MaleDog (?), 07-Янв-23, 13:33   +/
Ну а chunked-запрос - это извращение. Насколько я помню изначально chunked был только для ответа сервера. Но потом реализовали и для запроса. При этом у chunked отсутствует заголовок Content-Length. Сколько читать указано перед чанком. Наиболее безопасно выделять буфер непосредственно перед чтением чанка проверив предварительно, что тот не слишком длинный, так как стандартом не оговорены ни максимальная длинна, ни то что чанки должны быть одинаковой длинны.
В любом случае chunked это не про быстродействие, это скорее про "бедность" передающего на оперативку. Так что нет никаких причин быстро его на сервере обрабатывать помещая весь запрос в оперативку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #339

209. Сообщение от Прохожий (??), 07-Янв-23, 13:36   +2 +/
Очевидно, и читать, и писать он умеет. А вот с осмысливанием прочитанного у него явные проблемы, как и у 90 процентов здешних комментаторов.

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

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

210. Сообщение от Аноним (228), 07-Янв-23, 13:38   –1 +/
Никогда не останавливайся на полпути, позорься до конца!

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #212

211. Сообщение от Прохожий (??), 07-Янв-23, 13:44   +/
Не тут. Но виноваты, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

212. Сообщение от Прохожий (??), 07-Янв-23, 13:56   +/
Упоминание UDP - это была попытка намекнуть, что не все так просто, как сишники себе вообразили.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #223, #224

214. Сообщение от Аноним (214), 07-Янв-23, 14:38   +/
Мы(пациенты) смеемся не с новости, а с ваших попыток оправдаться. Особенно смешно это читать после ваших набегов на темы вида "Уязвимость в коде на Си в проекте Х...", где каждый писал что-то в духе
>ряяя дырявая сишка, швятой хруст бы помог

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #215, #255

215. Сообщение от анон (?), 07-Янв-23, 14:46   +/
>Ваших попыток оправдаться

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214 Ответы: #216

216. Сообщение от Аноним (214), 07-Янв-23, 14:51   –1 +/
>Понятно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #227

217. Сообщение от Аноним (217), 07-Янв-23, 14:55   +/
Хах растобезопасность снова превратилась в тыкву
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #254, #324

219. Сообщение от Аноним (219), 07-Янв-23, 15:49   +/
А у тебя как всегда сишники виноваты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

222. Сообщение от Омномним (?), 07-Янв-23, 16:00   –1 +/
Жаборастера видно издалека, да.
Собирать будет "клиентский" код - там, где ему надо. С лимитами и т.п.
Простая проблема мерзкого дизайна. Либа должна отдавать не весь контент целиком, если он большой, а его куски, наподобие read(), с предзаданной длиной. Тогда и чанки будут читаться кусочками, и сборка будет мягкой и шелковистой. Зачем например тащить в память весь гиговый файл, если его можно на диск кусками писать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

223. Сообщение от Омномним (?), 07-Янв-23, 16:01   –1 +/
Хорошее упоминание. Ты собрался весь поток UDP за неизвестный период в память тащить, или всё-таки будешь его "клиенту" отдавать, чтобы тот решал сам, что с ним делать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

224. Сообщение от Омномним (?), 07-Янв-23, 16:02   –1 +/
Собственно об чём и речь. УНИВЕРСАМНАЯ либлиотека оказалась ни фига не универсальной, а заточенной только на очень специфичный вариант применения - когда всё в память помещается. Растожабаскриптерство - оно такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #266, #269

225. Сообщение от Омномним (?), 07-Янв-23, 16:04   –1 +/
И чего?
У меня сейчас допустим есть асинхронная корутинная реализация HTTP на PHP.
Она вполне себе клиенту что хедеры, что контент в обе стороны отдаёт кусками - через эксплицитный запрос на чтение. Кусками читает с сокета, кусками парсит (попутно применяя лимиты на те же хедеры, чтобы многомегабайтный хедер не скушать), и кусками же отдаёт по readHeader() / readHeaders() / readContent(). Клиент сам решит, что делать с очередным куском - буферизовать или свалить куда-либо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #226

226. Сообщение от Омномним (?), 07-Янв-23, 16:11   –1 +/
А для универсальности там же есть - readAllHeaders() / readFullContent(), первое читает с лимитом, второе - когда длина контента клиенту уже известна, и клиент хочет всё целиком. Внутри это просто обвязка к вышеупомянутым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #230

228. Сообщение от Аноним (228), 07-Янв-23, 16:18   +/
удОли весь сишный код со своего компа, с телефона и с домашнего роутера. Вангую ты сразу пропадешь из Интернета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

230. Сообщение от Аноним (214), 07-Янв-23, 16:23   –2 +/
>Какие оправдания?

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

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

231. Сообщение от псевдонимус (?), 07-Янв-23, 16:25   –1 +/
Ах,  так это лицо! ©
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

232. Сообщение от псевдонимус (?), 07-Янв-23, 16:31   –1 +/
Галустян,  залогинься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

233. Сообщение от Аноним (233), 07-Янв-23, 16:45   +/
Друк, а ты понимаешь значение слова "конструктор"? Оно если что как раз про лепление блоков друг к другу)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

234. Сообщение от Аноним (233), 07-Янв-23, 16:47   +/
Как же могучи эти аргументы "сперва добейся, не надо раскачивать лодку и знающие люди разберутся" (нет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

236. Сообщение от Аноним (228), 07-Янв-23, 17:05   –2 +/
Библиотека на чем написана? Значит обгадился раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #249, #272

237. Сообщение от Аноним (228), 07-Янв-23, 17:11   +1 +/
> Отсутствие возможности контролировать работу с памятью, когда тебе это нужно - это изьян

what? В Си контроллировать память можно когда угодно и как угодно? Про какой изъян ты бредишь?

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

238. Сообщение от Анонн (?), 07-Янв-23, 17:16   –1 +/
Добавить рандом в либу... И привязать его к параметру окружения...
Да ты просто злой гений! Пусть эти зaсрaнцы попробуют найти почему оно иногда не работает!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #296

240. Сообщение от НяшМяш (ok), 07-Янв-23, 17:45   +/
Если ты бездумно используешь метод "я буду сохранять все байтики в память", который явно в документации помечен опасным - надо свою кукуху лечить, а не низкоуровневую библиотеку. А вот почему создатели более высокоуровневых реализаций серверов не поставили ограничение по-умолчанию - это уже совершенно обоснованная претензия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

241. Сообщение от Аноним (241), 07-Янв-23, 18:00   –2 +/
Можно посмотреть как эту проблему решили высокооплачиваемые программисты из Sun.
https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...)

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #307

243. Сообщение от Аноним (228), 07-Янв-23, 18:29   +/
Дед, ты таблетки забыл принять на ночь? Что ты, блин, несешь, старый идиот?
Ты для начала хотя бы попробуй написать простейший UDP-сервер, к-й принимает пакет по сети, дак вот сразу перестанешь такой бред нести про UDP.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #299

244. Сообщение от Аноним (228), 07-Янв-23, 19:22   +/
И вообще, дед, причем тут UDP или TCP? Это нижележащий уровень, транспортные протоколы. Их задача - доставить тебе в приложение (идентифицируемое по номеру порта) payload, всё. Какая разница как тебе их доставили, через TCP или UDP? Ну вот что ты так бредишь то, зачем ты так позоришься? Выпей кефиру на ночь, или что вы там злобные стариканы пьёте, и ложись уже спать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

245. Сообщение от Аноним (245), 07-Янв-23, 19:40   +/
упоролись растоманы которые всегда утверждали, что раст решает все проблемы безопасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #250

246. Сообщение от Аноним (245), 07-Янв-23, 19:46   –2 +/
дебилизм какой-то, давайте напишем в документации ядра линукс, что хакеры не должны использовать дыры для целей порочащих безопасность и ядро автоматически станет безопасным. а от сбоев памяти защититься всюду ECC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #251, #278

247. Сообщение от Аноним (248), 07-Янв-23, 21:21   +1 +/
> Бугагашно, чанк по частям мегабезопастные кодеры читать не научились? :D

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


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

248. Сообщение от Аноним (248), 07-Янв-23, 21:27   +2 +/
> Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению

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

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

249. Сообщение от freecoder (ok), 07-Янв-23, 22:13   +2 +/
Попытка выделить большой кусок памяти не является небезопасной операцией. Safe Rust такое разрешает и подобные "ошибки" (а на самом деле и не ошибки вовсе) не устраняет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

250. Сообщение от freecoder (ok), 07-Янв-23, 22:16   +/
Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности. А не подмножество проблем, связанных с безопасностью работы с памятью и безопасностью типов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #271

251. Сообщение от freecoder (ok), 07-Янв-23, 22:24   +/
Функция выделяет памяти столько, сколько её попросили. Никаких UB при этом нет. В чем дебилизм- то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246

252. Сообщение от freecoder (ok), 07-Янв-23, 22:32   +2 +/
Уязвимость, но не в Rust и даже не в библиотеке Hyper, а в тех серверах, которые реализовали ошибочную логику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #270

253. Сообщение от freecoder (ok), 07-Янв-23, 22:35   +/
Кстати, новость написана правильно. А вот комментаторы неверно интерпретируют сказанное. Тут нет уязвимости в Rust, даже нет уязвимости в Hyper. Но есть уязвимость в нескольких проектах, построенных на Hyper.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #328, #346

254. Сообщение от freecoder (ok), 07-Янв-23, 22:37   +/
Безопасность Rust'а? Или безопасность Hyper? Или безопасность Axum, Salvo и conduit-hyper? Перечитайте новость внимательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217

255. Сообщение от freecoder (ok), 07-Янв-23, 22:43   +/
Чтобы убедиться, что в том случае растоманы действительно были неправы (если они такое писали), нужно найти новость и понять, не вызывала ли подобная ошибка сравнения в С далее обращение к уже освобожденной памяти или к выходу за пределы буфера. Сама по себе логическая ошибка сравнения может быть допущена как в Rust, так и в С. Но важен также контекст и последствия, к которым приводит эта ошибка: возможно в Rust действительно просто не было бы смысла/возможности писать такой код, который бы привел к порче памяти из-за подобной логической ошибки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

256. Сообщение от freecoder (ok), 07-Янв-23, 22:46   +/
Строго говоря, это не проблема библиотеки Hyper, это проблема тех нескольких серверов, которые её лениво используют. В Hyper есть возможность как читать все в один присест, так и читать кусками. На выбор вызывающей стороны. Просто кто-то сделал неверный выбор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #340

258. Сообщение от Аноним (90), 07-Янв-23, 23:01   –1 +/
> Это уже новая риторика. Изначально было "раст все порешает" и "программисты не будут совершать ошибки".

Ой звездуны-ы-ы-ы... Вкладывать свои слова и мысли в уста оппонента и потом с пафосом опровергать их - это уже дно, второе, после первого, в которое постучались снизу. Раст порешает только (примерно-условно) 70% проблем, определенные ошибки работы с памятью, да и то, с одним условием - никакого unsafe-кода. Даже взаимодействие с твоим "божественным си" через (ансейфовские) врапперы хоть и локализует проблему, но сводит часть работы на нет. Ну даже ложка дерь... дегтя бочку меда портит. Тем больше стимул заменять всё на мёд и не взаимодействовать с дёгтем. Просто дёготь пока везде вокруг, но это не повод сложить руки и отказаться от прогресса. Всё новое пиши на мёде, старое на дёгте, если еще хоть немного сопровождаемо, тяни дальше.

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

259. Сообщение от Аноним (90), 07-Янв-23, 23:12   +/
Не любого кода. Подавляющая часть программ (состоящих из данных и кода) категорически не должна иметь доступ _по любому_ адресу памяти. С точки зрения современной (относительно) универсальной (многопроцессной, многопользовательской) операционной системы. Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти. Или к уже освобожденной. Или выделенной другой программе, если у них специально разделяемую область не создал, с казино и шлю... с доступом примитивы синхронизации (семафоры и т.п.). В своих наколенных ОС-поделках воруй память наперегонки из разных программ как тебе вздумается. Т.е. подозреваю кроме как под DOS, используя хитрые "хакирские" трюки, ты ничего не писал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #276, #279

260. Сообщение от Аноним (90), 07-Янв-23, 23:19   +/
создатели карбона где-то недалеко от вводной написали, что если вы используете раст - то молодцы и используйте его дальше, а этот карбон - костыль для тех, кто за всю свою жизнь только плюсы смог как-то наполовину осилить или для тех, кому уже не разгрести унаследованные авгиевы конюшни плюсплюснутых решений, которые уже не выкинуть, а переписать на чем-то другом, совершенно отличном от плюсов - жизни или денег не хватит. А вот на карбон перенести якобы значительно легче и дешевле. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

261. Сообщение от keydon (ok), 07-Янв-23, 23:21   –1 +/
Проблема этой ветки в том что раст преподносился (и преподносится) как язык решающий человеческие ошибки. Но по факту он решает их малую часть (и создает новые). То есть от чего уходили (человеческие ошибки в си) к тому и пришли (человеческие ошибки в расте).
Люди разделились на тех кто решил этого не замечать (растоманы) и тех кто об этом говорил с момента зарождения раста (сишники). В зависимости от этого и разное отношение к каждой подобной новости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #273, #300

262. Сообщение от Вы забыли заполнить поле Name (?), 07-Янв-23, 23:23   +/
> Ты понимаешь разницу между специализированным ПО

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

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

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

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

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

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

264. Сообщение от keydon (ok), 07-Янв-23, 23:29   +/
Об этом сишники писали 10 лет назад. Что ЯП не исправит человеческие ошибки, даже наоборот - либ нет, а пока сделают новые наклепают и новых ошибок (что и произошло).
В ответ им заявлялось что де раст то все исправит, якобы разработка на расте изначально безопаснее и намного проще и быстрее (поэтому все дедовские либы перепишут гораздо быстрее чем писали на си).
Чуда не случилось и теперь аргументы сишников 9 летней давности отправляют обратно сишникам и считают что это ок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #268

265. Сообщение от Аноним (267), 07-Янв-23, 23:32   +/
А ты по ссылочке-то пробовал пройти?

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


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

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

266. Сообщение от Аноним (90), 07-Янв-23, 23:35   +1 +/
Если ты туда всунешь какой-то лимит на размер буфера она перестанет быть универсальной. На малинке с 2Г оперативы для кастомной программы там одни лимиты будут, для суперкомпа с терабайтом оперативы в защищенном периметре, где к нему не обращаются неавторизованные хосты и программы - другие лимиты. А так впендюришь ты 640KB и скажешь - "этого должно хватить на всё! Универсально!". Универсальность как раз в том, что её могут использовать по разному, под разные нужды. Проблема в том, что кто-то не прочел документацию и не проникся этой универсальностью создавая уже свой продукт. Тут уже от ЯП не зависит. И чего я бисер мечу перед вами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224 Ответы: #295

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

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

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

268. Сообщение от Аноним (90), 07-Янв-23, 23:57   +/
> В ответ им заявлялось что де раст то все исправит,

наглая ложь. И ты это понимаешь. Троллишь наверное. Всем понятно (и тебе тоже), что всё не исправит. Какой ЯП тебе исправит ошибку, где ты знаки "больше" "меньше" перепутал в логическом условии, где синтаксически могут быть оба знака? Или считал что-то из БД, а потом не вычел это из промежуточного результата, а сложил с ним? Или не проверил диапазон допустимых значений в поле полученного JSON и потом склеил из этого гов.а SQL-запрос, вместо всех предварительных проверок и использования переменных подстановки? В таких ошибках си и раст не отличаются друг от друга. Но печалька для тебя в том, что статистика показывает, что таких ошибок только процентов 30% в сишных программах. А остальных 70% в расте нет (если нет ансейфа), всё в си госталось.

> якобы разработка на расте изначально безопаснее и намного проще и быстрее

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #281

269. Сообщение от Аноним (269), 07-Янв-23, 23:57   +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

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

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

270. Сообщение от Аноним (228), 08-Янв-23, 00:01   +2 +/
В Си тоже нету уязвимостей, они могут встречаться в софте на нем написаном
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

271. Сообщение от keydon (ok), 08-Янв-23, 00:04   +2 +/
> Приведите доказательства, что растоманы утверждали, будто Rust решает ВСЕ проблемы безопасности.
> А не подмножество проблем, связанных с безопасностью работы с памятью и
> безопасностью типов.

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

Я конечно не буду тратить свое время на поиск доказательств и комментариев многолетней давности, но прекрасно помню как раст в начале преподносился (в основном на хабре и в комментариях опеннета, официально мозилла таких заявлений не делала) как серебрянная пуля решающая все проблемы как миниум с памятью и тредами. Какие конкретно проблемы и как это реализовано технически на тот момент растоманы опеннета внятно ответить не могли. За это время я видел как менялась позиция растоманов: сначала от фанатского "придёт и все-все-все решит" и "нужно все переписать на раст, он все делает лучше" до "это не проблема ЯП/на си тоже такие проблемы есть/никто и не обещал решить эту проблему". Радует что в ответах растоманов все меньше фанатизма и все больше технических подробностей, но забавно видеть как с каждым таким ответом от гиганта отваливается кусок и вместо непобедимого колосса до финиша доходит захудалый замухрышка, который "никому ничего не обещал".

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #283

272. Сообщение от Аноним (90), 08-Янв-23, 00:08   +/
хе, представляю. Пишет кто-то какой-нибудь хайлоад для суперкомпа с терабайтом озу. Выделяет такой память под буфер, скажем, 10ГБ (ну там наколеночно-велосипедный in-memory-db), а тебе такой компилятор (или код в рантайме) раз: " - ошибка! разрешается выделять не более 1МБ ОЗУ, я так решил, 1 МБ должно хватить всем! Читай мануал языка, там это написано, в мануале запрещено выделять более 1МБ памяти!". Я правильно тебя понял?

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

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

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

273. Сообщение от Аноним (90), 08-Янв-23, 00:10   +1 +/
> Но по факту он решает их малую часть (и создает новые).

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #284

276. Сообщение от Аноним (228), 08-Янв-23, 00:27   +/
> Не любого кода

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

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

277. Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 00:31   +/
>> Но раст не дотягивает до крестов.
> Чего не хватает Rust, о гуру системного программирования?

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #280

278. Сообщение от Аноним (90), 08-Янв-23, 00:36   –1 +/
Там написали, что ты не должен это выставлять наружу, в недоверенное окружение. Т.е. если ты аналогии про ядро кидаешь, то это не должно быть системным вызовом ядра для программ. Т.е., есть какой-то небезопасный, но универсальный механизм (молоток, которым можно гвоздь забить, а можно и голову пробить). Им можно пользоваться, как выше уже кто-то приводил пример, и в ядре для смарт-часов и в кластере из топ-500, т.е. условия эксплуатации разные. Наружу из ядра ты должен выставить другие вызовы, а не этот внутренний механизм. Этот механизм не может и не должен знать что творится снаружи и параметры этого "снаружи", это знают и проверяют клиенты этого механизма, т.е. другие вызовы ядра. А тут кто-то взял и написал прокси-сискол без проверок, который, скажем, условно, сквозным образом позволяет из юзерспейс программ читать любую страницу памяти в системе, хотя в документации написано что так делать нельзя, он не для этого предназначен. Этот внутренний механизм нужен многим другим сисколам. Большинство работает с ним правильно, согласно документации, а как появились 2-3 ленивых паршивых овцы - механизм стал нехорошим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246

279. Сообщение от Аноним (228), 08-Янв-23, 00:42   +/
> Ну, просто как пример, ты не должен обращаться к еще не выделенной памяти

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

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

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

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

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

280. Сообщение от Andrewpotam (?), 08-Янв-23, 00:46   +1 +/
> * Прибитость гвоздями к LLVM

Cranelift

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

set_alloc_error_hook

> * Float-free libcore

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #285

281. Сообщение от keydon (ok), 08-Янв-23, 00:46   +2 +/
> наглая ложь. И ты это понимаешь. Троллишь наверное.

Нет

> Всем понятно (и тебе тоже), что всё не исправит. Какой ЯП тебе исправит ошибку, где
> ты знаки "больше" "меньше" перепутал в логическом условии, где синтаксически могут
> быть оба знака? Или считал что-то из БД, а потом не
> вычел это из промежуточного результата, а сложил с ним? Или не
> проверил диапазон допустимых значений в поле полученного JSON и потом склеил
> из этого гов.а SQL-запрос, вместо всех предварительных проверок и использования переменных
> подстановки? В таких ошибках си и раст не отличаются друг от
> друга.

Так это и заявлялось противниками раста и лично мной. ЕМНИП даже пример
> знаки "больше" "меньше" перепутал в логическом условии

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

> Но печалька для тебя в том, что статистика показывает, что
> таких ошибок только процентов 30% в сишных программах. А остальных 70%
> в расте нет (если нет ансейфа), всё в си госталось.

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

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

Я такое уже слышал один в один, но в разное время про java (причем несколько раз в разное время), C#, js (nodejs, electron), очередную версию php, ruby. И конечно же по каждому из них были восторженные статьи от успешных компаний.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #301

282. Сообщение от Аноним (90), 08-Янв-23, 00:49   –1 +/
Когда новость про ошибки в программах на расте не связаны с самим растом, у наСИльников особенно ярко и гулко полыхает. Что только подкидывает в копилку надежности и нужности раста: вот, очередная ошибка! ан нет, не переполнение буфера, не обращение к невыделенной/освобожденной памяти, не двойное освобождение. Это пока не пропускается, если только с сишным легаси не взаимодействует. Просто знаки больше-меньше перепутали или входные данные не проверили. Отрадно. Так держать. Не, понятно, никто не безгрешен, наверное раз в пятилетку проблемы с памятью и от самого раста будут находить, но я готов это терпеть.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #287, #291, #312

283. Сообщение от freecoder (ok), 08-Янв-23, 00:52   +/
Rust решает некоторые проблемы, но большие и очень важные. Линтерами на плюсах они не решаются в той мере, которой решаются растом. Как видите, это совсем не "тот же самый аргумент".

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

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

284. Сообщение от keydon (ok), 08-Янв-23, 01:00   –1 +/
> Ложь. Решает бОльшую часть. Решает 70% ошибок. 30% < 70%. Новые не
> создвал. Просвети насчет новых.

Давай посчитаем. Какие конкретно ошибки в твоих программах с использованием современного C/C++ по современным методикам с линтерами и анализаторами решил раст и к каким последствиям эти ошибки привели лично для тебя и твоих пользователей?

> Главная ошибка - ты не смог осилить
> новый ЯП?

Спервадобейся в 2023? Серьезно?
"Но я же могу рассуждать о качестве омлета, хотя еще ни разу не снёс ни одного яйца."

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #362

285. Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 01:23   +2 +/
>> * Прибитость гвоздями к LLVM
> Cranelift

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #364

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

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

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

287. Сообщение от Аноним (287), 08-Янв-23, 01:50   +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
Ну и хотите верьте, хотите нет, но мне не будет легче если программа просто упадет, займет всю память или даст рут-доступ, но ЗАТО безопастно и не портя память.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #293

290. Сообщение от Аноним (294), 08-Янв-23, 11:38   +1 +/
А где обычная приписка, что Раст позволяет избегать ошибок и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #311, #316, #321

291. Сообщение от Аноним (294), 08-Янв-23, 11:39   +2 +/
Нужен новый язык. Раст решает не все проблемы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #322

292. Сообщение от Аноним (294), 08-Янв-23, 11:41   +2 +/
> Пациенты клиники Кащенко в комментах в полном сборе.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #304

293. Сообщение от Аноним (47), 08-Янв-23, 11:43   +1 +/
Конечно верим, потому что сразу видно админа локалхоста...
Тебе будет легче если она не упадет и продолжить работу, но при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #318

294. Сообщение от Аноним (294), 08-Янв-23, 11:45   +/
Но дрова то на небезопасном Си, все равно их переписывать с нуля надо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

295. Сообщение от Омномним (?), 08-Янв-23, 11:56   +/
Ты в курсе, что лимит может быть конфигурируемым со стороны клиента?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266

296. Сообщение от Аноним (297), 08-Янв-23, 13:13   +/
Документацию читать надо, а ошибки - писать в лог вместе с причинами. Рандом нужен для того, чтобы удаленные атакующие не могли определить количество свободной памяти на машине в данном окне по времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

297. Сообщение от Аноним (297), 08-Янв-23, 13:17   +/
Адекватные люди отключают оверкоммит. И тут же выясняется, что говно и линукс и его экосистема (бочка мёда с ложкой говна есть бочка говна), программы на нём памяти жрут на порядки больше, чем на винде, и фиксить это никто не будет, потому что "у кого нет денег на железо, тот пусть пользуется софтом для быдла, а мы, илитка, можем себе позволить жрущий софт".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

299. Сообщение от Аноним (297), 08-Янв-23, 13:29   +/
Если оно по 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-trans.../ и https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp... .

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

300. Сообщение от Аноним (300), 08-Янв-23, 13:43   +/
> раст преподносился (и преподносится) как язык решающий человеческие ошибки

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #306

301. Сообщение от Аноним (300), 08-Янв-23, 13:48   +1 +/
> На что задавался вопрос какие конкретно проблемы, почему их нельзя решить в си и плюсах, почему нужно городить новый велосипед. В итоге выяснялось что решить в плюсах с помощью линтеров и либ можно почти все

Так почему так и не решили?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #369

304. Сообщение от Аноним (300), 08-Янв-23, 14:16   –1 +/
То ли дело молиться, что всё порешают линтеры, санитайзеры, да прямые руки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #314

305. Сообщение от Карбон лучший (?), 08-Янв-23, 14:35   –2 +/
Когда же вы поймёте что самый безопасный язык это Carbon
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #309, #338

306. Сообщение от keydon (ok), 08-Янв-23, 14:38   +/
>> раст преподносился (и преподносится) как язык решающий человеческие ошибки
> Вот только не было обещаний, что он решит их все.

Я еще с первых форсов раста писал что чуда не случится и все имеет свою цену, давайте разбирать техническую сторону и смотреть трезво на то что раст предлагает и что он требует. Никто из растоманов тогда не удосужился адекватно ответить что же раст порешает и каким образом.
Это не мешало растоманам ругать си и основной упор был на дедовские библиотеки, необходимость бесконечных проверок в коде на си, сложности написания безопасного кода на си и т.д.. Проходит несколько лет и несколько относительно крупных проектов на расте..."забывают" добавить проверку описанную в документации. Прямо как деды в си. Конечно "это не проблема раста", но уязвимости в программах на си не были "проблемами ЯП", а именно так заявляли растоманы.
Я прекрасно помню как в новостях об очередной найденной нетривиальной уязвимости утилиты на си, допущенной программистом (а не ограничем ЯП), приходили растоманы и писали что на си невозможно написать безопасный код и что срочно надо все переписать на расте. Теперь ровно такая же ситуация (даже намного более тривиальная) с проектами на расте, но растоманы говорят "вы не понимаете! это другое! наш ЯП не виноват". Так и си был не виноват.
Двуличность растоманов мягко говоря зашкаливает.

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

307. Сообщение от Аноним (307), 08-Янв-23, 14:50   +/
и вообще смог понять что за проблема
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

309. Сообщение от Аноним (314), 08-Янв-23, 15:56   +1 +/
Когда пройдет фанатизм == никогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305

311. Сообщение от Аноним (314), 08-Янв-23, 15:57   +/
Будет в следующий раз. А когда ты дашь ссылку на эту новость тебе скажут что ты всё врёшь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290

312. Сообщение от Аноним (314), 08-Янв-23, 16:00   +/
Ты ещё в сортах уязвимость разбираешься? Типа когда тебя взломают через неправильный знак это что будет смягчающем обстоятельством? Да пофиг тебе уже взломали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282

314. Сообщение от Аноним (314), 08-Янв-23, 16:01   +/
Толи дело написать язык, на котором ничего невозможно написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

316. Сообщение от Вы забыли заполнить поле Name (?), 08-Янв-23, 16:17   +/
Это другое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290

318. Сообщение от Аноним (318), 08-Янв-23, 16:57   +/
>при этом твой диск зашифруют? или бд утечет? или просто станет частью ботнета?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #293 Ответы: #323

321. Сообщение от freecoder (ok), 08-Янв-23, 17:18   –1 +/
> А где обычная приписка, что Раст позволяет избегать ошибок и т.д.

Он и без приписки позволяет избегать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #337

322. Сообщение от freecoder (ok), 08-Янв-23, 17:20   +/
Новый будет создан на основе Раста и с учетом его преимуществ и недостатков. Ещё не скоро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #350

323. Сообщение от freecoder (ok), 08-Янв-23, 17:21   +/
Как получить рут-доступ, если сервер замедлился или упал из-за перерасхода памяти?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318 Ответы: #325

324. Сообщение от freecoder (ok), 08-Янв-23, 17:23   +/
> Хах растобезопасность снова превратилась в тыкву

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

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

325. Сообщение от Аноним (318), 08-Янв-23, 17:37   –1 +/
>Как получить рут-доступ,

https://www.opennet.ru/opennews/art.shtml?num=55607
>В Rust проблеме оказалась подвержена стандартная библиотека "std::net" (CVE-2021-29922). Парсер IP-адресов данной библиотеки отбрасывал ноль перед значениями в адресе, но только если указано не более трёх цифр, например, "0177.0.0.1" будет воспринято как недопустимое значение, а в ответ на 010.8.8.8 и 127.0.026.1 будет возвращён неверный результат. Приложения, использующие std::net::IpAddr при разборе указанных пользователем адресов потенциально подвержены атакам SSRF (Server-side request forgery), RFI (Remote File Inclusion) и LFI (Local File Inclusion).

https://www.opennet.ru/opennews/art.shtml?num=55167
>В ходе аудита была выявлена группа уязвимостей (CVE-2021-31153, CVE-2021-31154, CVE-2021-31155), приводящих к краху и не исключающих возможность создания эксплоитов для повышению привилегий в системе

Ну и не совсем рут-доступ, но удаление системных файлов тоже неприятно
https://www.opennet.ru/opennews/art.shtml?num=56551
>В стандартной библиотеке языка Rust выявлена уязвимость (CVE-2022-21658), связанная с состоянием гонки в функции std::fs::remove_dir_all(). В случае применения данной функции для удаления временных файлов в привилегированном приложении злоумышленник может добиться удаления произвольных системных файлов и каталогов, к удалению которых в обычных условиях у атакующего нет доступа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323 Ответы: #331

328. Сообщение от anonymous (??), 08-Янв-23, 18:21   +/
Ваш растопроект вылетел в DoS из-за непроверки входных данных? Знаете кто виноват? Нет, не Раст, который декларировал безопасность работы с аллокацией, и не Hyper, который не делает проверок входных данных, но только документирует это. Виноваты ВЫ - потому что доверились сказкам растоманов про безопасность кода и выключили голову, когда писали свой проект, опираясь на библиотеку, которая в перекладывает проверки на клиента.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #332, #349

330. Сообщение от Аноним (330), 08-Янв-23, 19:44   +/
> добрый сервер выделил боту 10G оперативной памяти? А если столько нет?

overcommit

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #359

331. Сообщение от freecoder (ok), 08-Янв-23, 20:05   +/
Эти случаи уже много раз обсудили, обмусолили и сделали выводы. Давайте здесь обсуждать тему топика и не перескакивать, а то иначе не понять, кто что имеет ввиду и о каких проблемах вообще говоря речь. Проблема, вызванная отсутствием проверки реального объема загружаемых данных и попыткой резервировать большой кусок памяти, никак не приведет к повышению привилегий в системе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #325 Ответы: #341

332. Сообщение от freecoder (ok), 08-Янв-23, 20:09   +/
Rust и растоманы нигде не обещают избавления от логических ошибок. Те гарантии, которые давал Rust, он их не нарушил: никакой гонки не произошло, никто не вышел за пределы буфера, не обратился к неинициализированной памяти и пр. Остальное - это уже ваши додумки и домыслы тех, кто Rust и не видел вовсе, и даже дня на нем не программировал, судя по всему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328 Ответы: #354

337. Сообщение от Ыыыыыы (?), 08-Янв-23, 20:25   –1 +/
Клоун, ты новость читал? Или сразу в каменты  как адвокат ржавого прибежал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #321 Ответы: #352

338. Сообщение от Ыыыыыы (?), 08-Янв-23, 20:27   +/
Не ври, most wanted лучше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305

339. Сообщение от Омномним (?), 08-Янв-23, 20:47   +/
Почему извращение?
Допустим мы хотим залить контент заранее не известного объёма.
Какую-нибудь телеметрию например, которая идёт потоком, но лить хотим по HTTP.
Why not?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #367

340. Сообщение от Омномним (?), 08-Янв-23, 20:49   –1 +/
У чтения в один присест должны быть лимиты.
Потому что всем, кроме хрустоманов, очевидно, что доступная память - не резиновая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #353

341. Сообщение от Аноним (341), 08-Янв-23, 23:35   +1 +/
>4:19: Какой рут? Из под раста нельзя ничего подобного получить
>приносятся ссылки
>4:20: Это уже сто раз обсудили, так что давайте не будем переводить тему, да и вообще забудем про данный разговор, ничего не было. Раст швятой

Классика.

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

346. Сообщение от Аноним (307), 09-Янв-23, 11:31   +1 +/
Вызвать команду на загрузку всех данных в память и обвинять язык в том что память закончилась это какой-то особый способ идиотизма.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #360

348. Сообщение от Аноним (349), 09-Янв-23, 14:00   +1 +/
> копирующая данные запроса и ответа целиком в один буфер без проверки размера полученных данных

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

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

349. Сообщение от Аноним (349), 09-Янв-23, 14:03   +1 +/
+1. Причём "растаманить" на их неуклюжем языке в 2 раза сложнее и они это оправдывали повышенной безопасностью. Так накой мне лишний геморой, если всё равно раст дырявый?!
Даже С++ со смарт указателями стократ надёжнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328

350. Сообщение от Аноним (351), 09-Янв-23, 15:03   +/
Rust with classes, Objective-Rust, Rust++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

351. Сообщение от Аноним (351), 09-Янв-23, 15:11   +1 +/
"Программы на Rust текут из-за особенности работы с памятью."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #355

352. Сообщение от freecoder (ok), 09-Янв-23, 15:23   +/
Клоун тут только ты: ошибка из новости не имеет никакого отношения к memory safety.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #337

353. Сообщение от freecoder (ok), 09-Янв-23, 15:27   +/
Еще скажите, что у обращения по индексу всегда должна быть проверка выхода за границы. Потому что размеры буфера не бесконечны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #340 Ответы: #374

354. Сообщение от Аноним (294), 09-Янв-23, 16:12   +2 +/
Прикол в том, что в Расте вероятность совершить логическую ошибку повышается из-за того, что даже простейший код раздувается до ненормальных размеров. Это не говоря уже о том, что приходится структурировать код не в угоду читабельности, а чтобы угодить компилятору. Ну и не стоит забывать про сумасшедший синтаксис
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332 Ответы: #356

355. Сообщение от Аноним (355), 09-Янв-23, 20:20   +/
> "Программы на Rust текут из-за особенности работы с памятью."

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

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

356. Сообщение от freecoder (ok), 09-Янв-23, 20:28   +/
Код раздувается из-за того, что развитая строгая типизация требует больше явных проверок и обработки всех веток на месте. Из-за этого же наоборот, вероятность совершить ошибку понижается.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354 Ответы: #357

357. Сообщение от Аноним (294), 09-Янв-23, 20:33   –1 +/
Я говорю о ЛОГИЧЕСКИХ ошибках
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356 Ответы: #361

359. Сообщение от MaleDog (?), 10-Янв-23, 11:01   +/
Но при этом на "лимит времени" память будет занята. Притом атакующий затратит гораздо меньше ресурсов. Так ему нужна память только на заголовки одного запроса, а в качестве тела будет "мусор". Нет, так дела не делаются. Выделяем буфер на заголовки. Парсим проверяем. Далее либо буферизуем тело небольшим буфером передавая по частям обработчику, либо просто пробрасываем TCP-соединение ему - пусть сам разбирается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330

360. Сообщение от Аноним (228), 10-Янв-23, 12:37   +/
> элементарные арифметические операции продолжают неопределенное проведение

болобол

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

361. Сообщение от freecoder (ok), 10-Янв-23, 14:01   +/
Так я тоже о них говорю. Обработка не всех вариантов - в общем случае ведет к логическим ошибкам.


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

362. Сообщение от Анимус (?), 10-Янв-23, 18:58   +/
Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом, если можно писать сразу удобно и в кайф?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #370

363. Сообщение от Анимус (?), 10-Янв-23, 19:08   +/
Добывай огонь трением, мало ли, спички закончатся
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

364. Сообщение от Анимус (?), 10-Янв-23, 19:15   –2 +/
Ты бы не позорился. У Раст так же стандарты выходят раз в три года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285 Ответы: #366

366. Сообщение от Вы забыли заполнить поле Name (?), 10-Янв-23, 21:34   +1 +/
> Ты бы не позорился. У Раст так же стандарты выходят раз в
> три года.

Ссылкой на стандарт поделишься?

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

367. Сообщение от MaleDog (?), 10-Янв-23, 22:28   –1 +/
Потому, что заранее не известно когда закончится запрос. Теоретически я хоть целый день могу развлекать сервер одним запросом(насколько хватит терпения у проектировавшего сервер). Кроме того ему нужно будет решать вопросы с увеличивающимся или уменьшающимся буфером или склеиванием, ведь максимальная длинна чанка не известна заранее и нигде не сказано что они могут быть одной и той же длинны. и эта проблема умножается на два или на три, если со стороны сервера или клиента есть прокси. Лучше уж тогда TCP и бинарный протокол, где все, включая длинну сообщения будет заранее оговорено. Не спорю то же самое можно оговорить и в заголовке HTTP, но зачем? Учитывая что выбрав бинарь вы минимум вдвое сэкономите на длинне сообщения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #339 Ответы: #368, #371

368. Сообщение от MaleDog (?), 10-Янв-23, 22:56   +/
Тем более, что часто люди просто не думают. Вот к примеру реальный случай. Мне предлагают использвать chunked HTTP(даже не HTTPS). Есть некий девайс на esp32(520 KB RAM), в нем есть буфер EEPROM на 128KB. Разработчик говорит: я не знаю сколько у меня записей будет потому не могу сказать заранее Content-Length. Но в данном случае это чистое лукавство. Судя по коду у него две третьих оперативы всегда свободны. Т. е. запрос содержащий если не половину, то четверть EEPROM можно спокойно затолкать в оперативку даже в формате JSON и посчитать его длинну.В 4-5 запросов можно передать все данные. Но нет, нужно же осложнить жизнь разработчику сервера и передать все в одном chunked, и пусть этот разработчик продумает все возможные способы атаки, где левый долбящийся бот может вызвать отказ.
Если что, реальный случай. Есть некая небольшая компания занимающаяся IOT, у них есть сайт с demo-кабинетом. Меня пригласили оценить и возможно сделать что-то подобное(я универсал, "сам пою, сам снимаю, сам по морде получаю"). Зашел в кабинет - красивенько. Ну там схема квартиры, и один датчик. Вижу кнопку "отчет" и datetimepicker. Пробую отчет за день - нормально. За неделю - сервер слегка задумался. За месяц - сервер упал. Да так что даже статус не возвращает. Вместе с сервером упал и сайт компашки. Вот специально попросил заказчика проверитть, что не меня забанили, а именно сервер упал. Да не может быть думаю. Через полчаса, когда кто-то видимо перезагрузил сервер повторяю операцию - сервер еще на полчаса в отрубе. Вот что бывает когда кто-то не продумал все возможные варианты использования его поделия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367

369. Сообщение от keydon (ok), 11-Янв-23, 12:47   +/
Так в основном и решили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301

370. Сообщение от keydon (ok), 11-Янв-23, 12:50   +/
> Зачем обмазываться линтерами, анализаторами и распухшим до безобразия новым стандартом,

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

> если можно писать сразу удобно и в кайф?

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

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

371. Сообщение от Омномним (?), 11-Янв-23, 15:07   +/
Про read timeout что-нибудь слышал?
Ну и да - чанк не обязательно читать целиком, снова растожаберство какое-то в голове :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367 Ответы: #372

372. Сообщение от MaleDog (?), 12-Янв-23, 23:15   –1 +/
Тут вся суть в том. Как отличить добросовестное использование от недобросовестного. Если это обычный http запрос с Content-Length, то довольно просто выделить буфер и установить таймаут. Если это Chunked, то придется устанавливать эти правила для каждого чанка. Что гораздо затратнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #371 Ответы: #373

373. Сообщение от Омномним (?), 13-Янв-23, 00:45   +/
Чичиго?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #372

374. Сообщение от Омномним (?), 18-Янв-23, 10:44   +/
Только в случае, если индекс зависит от пользовательского ввода.
Проверять границы буфера во внутреннем обходном цикле - так себе затея :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353 Ответы: #375

375. Сообщение от freecoder (ok), 20-Янв-23, 12:31   +/
В цикле и так будет проверка на каждом шаге условия достижения конца цикла. Чтобы проверку не дублировать ещё и при непосредственном доступе по индексу, и при этом не жертвовать безопасностью, лучше использовать итератор вместо прямого доступа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #374 Ответы: #376, #377

376. Сообщение от Омномним (?), 20-Янв-23, 21:02   +/
Проверка на каждом шаге условия?
Ну удачки, чего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375

377. Сообщение от Омномним (?), 20-Янв-23, 21:13   +/
Есть допустим у меня кадр. 7680x4320.
Мне его надо вдоль и поперёк обработать, согласно пользовательскому вводу.

На каждом шаге проверять выход за пределы буфера? Итераторы?
Жабоскрипт и прочие расты ГМ, однако. В здравом уме - проверяется однократно до обработки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375 Ответы: #378

378. Сообщение от freecoder (ok), 21-Янв-23, 21:23   +/
Ваше предыдущее сообщение было про цикл. Как вы себе представляете цикл без проверки условия выхода?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #377 Ответы: #379

379. Сообщение от Омномним (?), 22-Янв-23, 09:39   +/
Между проверкой условия выхода и проверкой границ есть небольшая разница, не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #378


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

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




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

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