1.1, Аноним (1), 22:16, 24/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> размер определяется на основе параметра, указанного в заголовке запроса
>
> переполнение буфера
Детям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.
| |
|
2.5, Ordu (ok), 23:28, 24/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> инициировать переполнение буфера, приводящее к краху рабочего процесса.
Писали бы на расте, тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно. Попытка переполнить его обломалась бы с паникой.
| |
|
3.8, Аноним (8), 00:48, 25/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
- Дедушка, а бывает раст без unsafe?
- Нет, внучек, это фантастика.
| |
|
4.9, Ordu (ok), 01:15, 25/03/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
> - Дедушка, а бывает раст без unsafe?
> - Нет, внучек, это фантастика.
Мне вот интересно, что надо сказать анониму опеннета, чтобы тот понял наконец, что он не может сказать мне про unsafe в rust'е ничего, чего я бы не знал? Что он вообще мне ничего о расте не может сказать, чего я бы не знал. Какая словесная формулировка может мне помочь пробить дубовый череп анонима с опеннета и донести до него эту простую мысль?
Или я тебя не понял, и ты сам хочешь что-то у меня узнать про unsafe? Если так, то не стесняйся, не ходи вокруг да около, а задай вопрос прямо. Будь мужиком, блеа...
| |
|
3.11, leap42 (ok), 04:02, 25/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Писали бы на расте...
или на Ada, или на C++, в них тож памятью можно автоматически управлять. но не писали.
> ... тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно.
переполнения действительно бы не было, как и ни одной рабочей реализации memcached.
безопасность - это хорошо конечно, но программистам нужны готовые, рабочие инструменты.
| |
|
2.6, kai3341 (ok), 23:56, 24/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Детям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.
Анонимуса ни в коем случе нельзя пускать в комментарии
| |
2.13, Аноним (13), 08:01, 25/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не сишников, а фейсбуковских программистов, учившихся программировать на примере php.
У тех сишников, которые изначально разрабатывали мемкеш, подобных проблем не возникало.
| |
|
|
|
|
4.23, deeaitch (ok), 02:22, 27/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ты или кто-то уже написали годный и полноценный продукт на Rust и можете с уверенностью сказать что было бы лучше.
Например (из того что не хватает лично мне и многим кого знаю):
1) Нормальный почтовый клиент, уровня kmail из kde3. Чтобы нормально подхватывал системные темы и настройки, в идеале на выход интерфейс умел и qt и gtk. Кому что больше нравиться.
Не?
2) Нормальную IDE на Rust для Rust. Не редактор текста с подсветкой синтаксиса и конфликтующими плагинами, а именно IDE, поставил и работай. С теми же требованиями к интерфейсу?
Не?
Брайзер я не упоминаю, браузер у меня уже есть нормальный (не хром и не firefox).
Появиться - дайте знать. С удовольствием посмотрю.
| |
|
|
2.12, nonamenogame (?), 07:54, 25/03/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Конечно, у Си есть недостатки, однако, давайте будем вещи называть своими именами.
Виноваты,
во-первых: стандартная библиотека языка Си, а не сам язык Си (а это две абсолютно разные вещи)!
во-вторых:
программист, который не знает то, как правильно использовать элементы стандартной библиотеки (плохому танцору, сами прекрасно знаете что мешает)!
| |
|
3.14, Fracta1L (ok), 08:19, 25/03/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Канеш виновато всё на свете, кроме самого Си. То, что подавляющая часть дыр и багов вообще - следствие некорректной работы с памятью, видимо, вас не смущает.
| |
3.15, Ordu (ok), 10:27, 25/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Прежде чем сваливать вину на стандартную библиотеку сходи и посмотри на патч. Там явно видно, что программист не справился с вычислениями размеров. Он забыл про '\0', и соответственно не увеличил размер буфера на единичку, и потом ещё забыл проверить размер копируемых данных: буфер выделяется на стеке, размер его задан статически, а extlen берётся, как я понимаю из внешних данных, и может оказаться больше допустимого.
А прежде чем сваливать вину на программиста, сходи и посмотри на git blame: я сам этого не делал, поэтому не скажу, насколько твои обвинения попадают в цель, но если ты не заглядывал в git blame, то под твоими обвинениями совершенно определённо нет никаких оснований, это взятые с потолка обвинения. Хотя git blame не всегда даёт ответ -- иногда дыра возникает из-за изменений в стороннем коде, который после очередного патча вдруг начинает пропускать невалидные данные.
| |
|
4.16, kai3341 (ok), 10:58, 25/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дополню
Ищещь виноватого? А насколько ты компетентен в вопросе? Покажи свой профиль на github. А то у нас каждая кухарка знает, как управлять государством, и каждый школьник знает, как писать большие проекты
| |
4.18, Ололо (?), 08:30, 26/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Он забыл про '\0', и соответственно не увеличил размер буфера на единичку
О каком '\0' ты говоришь? Show me the code.
| |
|
5.19, kai3341 (ok), 14:11, 26/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нуль-терминатор же, классика. Если у тебя стандартизирована длина строки (например, WPA password не более 63 символов), то размер буфера надо сделать на 1 больше (в частности, 64 байта)
| |
|
6.20, Ололо (?), 14:15, 26/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не спеши рассказывать мне очевидные вещи. Лучше покажи, где в обсуждаемом коде в последний байт буфера extbuf записывается '\0' или ещё что-либо.
| |
|
7.21, kai3341 (ok), 15:01, 26/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я даже в код не смотрел, так как не использую Memcached нигде -- не заинтересован
А так сорян -- экспертиза анонимуса опеннета в среднем требует объяснения элементарного
| |
|
|
|
4.22, Аноним (22), 16:29, 26/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Он забыл про '\0'
Там это, нуль только в asciiz и в релевантных функциях работы со строками -- с памятью не обязательно работать как с нуль-терминированными строками (более того, это может быть менее эффективно на больших массивах данных). Нужно только учитывать, что некоторые функции будут помещать нуль последним элементом строки, т.е. твоя строка должна быть либо на 1 байт меньше, либо памяти должно быть на 1 байт больше (последнее зачастую вызывает повышенную фрагментацию и неэффективную работу)
| |
|
|
|
|