| 1.1, Аноним (-), 09:14, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– | |
Вот вам и языки с ручным управлением памятью.
*садится и ждет еду*
| | |
| |
| 2.2, ползкрокодил (?), 09:58, 13/11/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
Ну а толку? Если есть доступ испортить po-файлы, то можно и исполняемые пошатать как угодно.
| | |
| |
| 3.3, Ordu (ok), 10:15, 13/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
 А разве нельзя подложить свой po файл без доступа в /usr?
| | |
| |
| 4.8, Аноним (8), 11:00, 13/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А разве нельзя подложить свой po файл без доступа в /usr?
.po для людей, для программ .gmo, их из .po получают.
И если вы в /usr писать можете, то у вас уже есть права root,
нафига вам уязвимость?
| | |
|
| 3.24, ig0r (??), 10:59, 14/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
А если ты написал программу, можно подумать ты будешь ревьюить .po файлы в PR если они для незнакомого тебе языка.
| | |
| |
| 4.32, ползкрокодил (?), 18:22, 28/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Можно даже отревьюить, а потом окажется, что какая-то последовательность иероглифов крашит макось.
| | |
|
|
| 2.5, Аноним (5), 10:32, 13/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Сейчас выдвинут тезис, что ручное управление памятью нужно "осилить". Тезис будет сопровождаться упоминанием о неких "макаках", которым "осиляторство" не под силу. Но то, что этот тезис появится под новостью о gettext, будет подразумевать, что авторы gettext - неисиляторы и макаки. Спрашивается, зачем тогда нам операционная система GNU, если его писали неосиляторы и макаки?
Но если этот тезис выдвинут не будет (в виду неприятных выводов), то это будет означать, что си действительно такой неудачный, что даже "осиляторы" и "немакаки" напишут в нем уязвимый код. Но из этого последует другой вывод -- что следует пользоваться другими языками, где нет ручного управления памятью.
| | |
| |
| 3.10, captcha 20168 (?), 11:06, 13/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> следует пользоваться другими языками, где нет ручного управления памятью
безбожно неэффективный код
| | |
| |
| 4.20, Аноним (20), 18:16, 13/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Предрассудки. Ручное управление памятью тоже требует ресурсов, а порой и медленнее GC, который может отрабатывать в отдельном потоке и даже устранять фрагментацию
| | |
|
| 3.17, Аноним (17), 14:14, 13/11/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
> ручное управление памятью нужно "осилить"
> "макаках", которым "осиляторство" не под силу
Всё правильно изложил.
Да, так оно и есть - с памятью надо обращаться аккуратно. Когда в том огромном объёме кода, написанного немакаками-осиляторами, косяки таки иногда обнаруживаются, это вызывает бурную радость макак, пишущих тормозные поделия на "безопасных" языках.
| | |
| |
| 4.21, Аноним (20), 18:18, 13/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вот только эксплуатировать уязвимость в интерпретаторе намного сложнее, чем в прикладном коде
| | |
|
| |
| 4.27, девелоперкодошлеп (?), 14:39, 14/11/2018 [^] [^^] [^^^] [ответить]
| +/– | |
как это нету, вон, gnu hurd, вчера только в эмуляторе ее запускал.
хотя, конечно, когда доломают все эмуляторы, еще как-то умеющие 32-бита, будут проблемы.
| | |
|
|
| 2.11, beck (??), 11:11, 13/11/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
 В языках с автоматическим управлением памятью управление памятью написано на тех же языках с ручным управлением памятью. И это конец рекурсии, так сказать.
Такого рода уязвимости будут всегда, так как всегда будут находить огрехи в реализациях, компиляторах, железе, драйверах, сочетании всего этого.
| | |
| |
| 3.19, Аноним (19), 16:19, 13/11/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
То есть споры о единственно верном подходе к программированию — удел балаболов и пустомель, в своём развитии ушедших не дальше чёрно-белой картины мира, свойственной подростковому возрасту. Судя по комментариям к новостям на подобную тематику, взрослые люди на опеннет встречаются крайне редко. Меня это печалит.
| | |
|
| 2.18, Аноним (18), 16:02, 13/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
А в языках с ручным управлением памяти давно существует Borrow Checker для защиты от таких ошибок.
| | |
|
| 1.4, Alex_K (??), 10:18, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ведь ничего не понятно в том, что написали про подверженные проблеме версии.
| | |
| |
| 2.9, ddd788 (?), 11:00, 13/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Что там непонятного? Последняя версия выпущена в 2016 году - она и подвержена. Не подверждены дистрибутивы, которые используют более древнюю версию.
| | |
| |
| 3.12, Аноним (12), 11:25, 13/11/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
Судя по написанному, также не подвержены дистрибутивы, собирающие себе свеженький пакет из гита. Ну либо использующие более античные версии. Хотя проблема не сказать чтобы критичная, разве что можно попытаться хакнуть ленивого разработчика, прислав тому перевод.
| | |
|
|
| 1.13, Аноним (13), 11:50, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Где мой фаззинг, а? Привыкли тестировать мультимедию, привыкайте фаззить пошки.
| | |
| 1.16, Аноним (16), 14:00, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Напоминает большинство новостей о якобы уязвимостях Linux типа - нужны 3 команды, чтобы сломать то-то и то-то ... Первая команда - sudo ... Бред.
| | |
|
