LINUX.ORG.RU
ФорумTalks

70% багов в Chrome из-за неверной работы с памятью

 , , ,


1

4

https://www.chromium.org/Home/chromium-security/memory-safety

Не прошло и года с последних откровений: Про статическую типизацию и безопасный доступ к памяти, как гугл пришёл к тем же выводам, что и MS.

Что на это скажут приверженцы «они просто не умеют писать на C/C++», «в C++ тоже есть умные указатели, зачем вам этот раст» и «понанимали дебилов»?

Из интересного, они рассматривают вариант использования своей/патченой std и бан сырых указателей на уровне компилятора.

★★★★★

Последнее исправление: RazrFalcon (всего исправлений: 1)

Ответ на: комментарий от rumgot

Вот этот героический поток мыслей - это твои фантазии.

Что именно фантазии? Не нужно эти правила соблюдать? Если не соблюдать, то ноги целые останутся? Или просто сказать нечего?

red75prim ★★★
()
Ответ на: комментарий от kirk_johnson

Ну не так я ставлю утверждение. Ты не то мне доказываешь.

rumgot ★★★★★
()
Ответ на: комментарий от kirk_johnson

Это TLS библиотека. Ты можешь выкинуть дырявый openssl и взять её.

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

bread
()
Ответ на: комментарий от kirk_johnson

для всякой веб-ерунды и микропе^W микросервисов

Что, нишу себе наконец-то нашли? А не тесновато там?

bread
()
Ответ на: комментарий от bread

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

А юзеры возникнут из астрала, да?

kirk_johnson ★☆
()

:) не падает и не имеет cve только то, чем никто не пользуется. Вот на расте ничего популярного нет, вот на нем все и стабильно.

mrdeath ★★★★★
()
Ответ на: комментарий от mrdeath

не имеет cve

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

kirk_johnson ★☆
()
Ответ на: комментарий от rumgot

О-хо-хонюшки. Подход «не надо ошибаться и ошибок не будет» абсолютно нереалистичен до тех пор пока программированием занимаются живые люди. Люди склонны ошибаться, путаться, забываться, терять концентрацию, отвлекаться, торопиться, а то и вовсе халтурить. В общем, пока сильный ИИ не будет создан (а может быть и после того), мы можем положить, что если какая-то ошибка может быть совершена, значит она будет совершена. И не раз.

ugoday ★★★★★
()
Ответ на: комментарий от kirk_johnson

а фоннаты раста переводят стрелки, когда просят привести примеры софта которым люди пользуются.

я не отрицаю что на С писать это сложно и работа с памятью там это полный п-ц. Но я не вижу альтернатив. Дайте мне аналог nginx, mysql, asterisk, haproxy, supervisord, pacemaker хотябы, я только спасибо скажу.

раст и хаскель настолько гениальны, что писать на нем могут только пет проекты для фана. Все остальное пишется на мейнстримных языках.

mrdeath ★★★★★
()
Ответ на: комментарий от mrdeath

Дайте мне аналог nginx, mysql, asterisk, haproxy, supervisord, pacemaker хотябы, я только спасибо скажу.

Вы в курсе, что весь веб на Java, JS, Python и тд. C/C++ там фактически нет. Некоторые критичные к производительности прослойки - да, но львиная доля на современных языках.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от mrdeath

Писать на Rust проще чем на C++.

На Go проще.

Ваш КО.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

меня сложно назвать сишником :) Я возьмусь за проект на С только за ооочень много денег ито 100 раз пытаясь переубедить клиента не писать на нем.

Но это не отменяет факта, с которым нам придется жить.

mrdeath ★★★★★
()
Последнее исправление: mrdeath (всего исправлений: 1)
Ответ на: комментарий от mrdeath

моя команда смотрела на этот раст. мы стали писать на голанге. раст он совсем нифига не простой.

А мы за неделю, почти не зная раста, запилии сервис, который мало чем уступал в скорости C.

kirk_johnson ★☆
()
Ответ на: комментарий от mrdeath

Большая часть «серьезного» софта написана на джаве. На втором месте C++.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от mrdeath

бОльшая часть серьезного софта написано

… в прошлом. Причём в далёком прошлом. На том, что там в прошлом доступно было. nginx (2002), mysql (1994), asterisk (1999), haproxy (2000) — это всё технологии двадцатилетней давности. А то и больше. Я сам отношу себя к консервативной (ультраконсервативной!!!) части лора, но линию рассуждений «деды наши палкой-копалкой наяривали и мы будем!» категорически не приемлю.

ugoday ★★★★★
()
Ответ на: комментарий от mrdeath

бОльшая часть серьезного софта написано на C. Можешь погуглить, разрешаю. :)

Смешно, оценил чувство юмора! Большая часть серьезного софта написана на коболе. Потом идет фортран. А вы со своими Си сидите в песочнице.

VIT
()
Ответ на: комментарий от kirk_johnson

Веб-ерунда самая широкая ниша.

Возможно, но там же стадо слонов. Затопчут. Причем любой из этих слонов удобнее и проще раста.

bread
()
Ответ на: комментарий от bread

Возможно, но там же стадо слонов. Затопчут. Причем любой из этих слонов удобнее и проще раста.

Ну как-то пока никого не затоптали %)

kirk_johnson ★☆
()
Ответ на: комментарий от ugoday

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

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 2)
Ответ на: комментарий от rumgot

Так не нужно все возводить в абсолют.

Вот и я считаю логику «rust — ерунда, т.к. не позволяет избавиться от абсолютно всех ошибок» глубоко порочной.

Кроме того на результат влияет сам процесс.

Просто, чтобы понимать вас правильно. Вы считаете «912 high or critical severity security bugs since 2015, affecting the Stable channel»:

а) хорошим результатом.

б) результатом плохо выстроенных процессов в гугле?

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Вы считаете 1813 открытых багов в компиляторе языка, который уберегает от ошибок:

https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AC-bug

а) хорошим результатом

б) результатом плохо выстроенных процессов в мозиле?

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

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

Но да, хотелось бы поменьше багов. (:

DarkEld3r ★★★★★
()
Ответ на: комментарий от fsb4000

Во-первых, я считаю, что прибегнув к «а у вас негров вешают» вы полностью и окончательно расписались в поражении своей позиции.

Во-вторых, не знаю. Могу дополнить список возможностей:

в) плохим результатом.

г) результатом хорошо выстроенных процессов.

ugoday ★★★★★
()
Ответ на: комментарий от DarkEld3r

Я всё-таки предлагаю разделять ошибки на обнаруженные в процессе разработки и тестирования (тут их количество само по себе не говорит ни о чём), и ошибки в уже выпущенных программах (стыд и позор за каждую!). Кроме того вряд ли нужно объяснять, что ошибки наподобие «злоумышленник получил доступ к моему банковскому счёту» несколько неприятнее чем «компилятор падает через раз», хотя и то, и другое относятся к critical issue.

ugoday ★★★★★
()
Ответ на: комментарий от fsb4000

И сколько из этих багов вызывают значительные или критические проблемы с безопасностью rustc?

Для справки: вот все 6 штук обнаруженных на текущий момент уязвимостей https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/Rust-lang-Rust.html

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 2)
Ответ на: комментарий от fsb4000

Это не баги, а запросы пользователей.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от mrdeath

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

ну так и я про то. :) Топикстартер говорит «нужно переходить на новые языки». Оно то может быть и нужно и было бы очень круто, но делать это никто не будет. Потому что старые решения настолько круты, что их переписывать нужно не один год. И пока оно вычистится от багов и обрастет приличным функционалом пройдет еще больше времени, а к этому времени любители «нового и лучшего» найдут еще один новый язык и захотят переписать все еще один раз ибо «чего копаться в этом куске легаси».

mrdeath ★★★★★
()
Ответ на: комментарий от mrdeath

Топикстартер говорит «нужно переходить на новые языки».

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

не совсем. хэллоуворды и всякие саасы будут писать(уже пишут) на модных языках, а база так и будет дальше крутиться на C/C++/Java. :)

mrdeath ★★★★★
()
Ответ на: комментарий от mrdeath

Довольно странно объединять C и Java в одну категорию, а rust — в другую. Я бы скорее скомпоновали их как C/Rust для низко и Java для высокоуровневых задач.

ugoday ★★★★★
()
Ответ на: комментарий от mrdeath

а база так и будет

Это зависит от прогресса в развитии железа. Большинство старых продуктов написаны в синхронном однопоточном стиле. Это имело смысл во времена PDP-11, но сейчас принято делать по другому.

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.