Свежие комментарии

Ну у меня это первый опыт попадания в security reports.

А дальше есть два варианта действий
а) не писать что починена "страшная бага" (особенно если я ее таковой не считаю), а писать "исправлена ошибка там-то" (без конкретизации что за ошибка, чтобы всякие роботы, механические и билологические, не срабатывали на слова из описания)
б) писать именно что про buffer overrun и подобное с точным указанием версий.

С точки зрения моей головной боли, вариант "а" кажется предпочтительнее.

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

Вообще, если представить себе сетевой сервис, который торчит наружу LibRaw - то таки да.

Но представить себе такой я не могу.

> По сообщению авторитетных разработчиков,

Видимо, тех самых, из высокой корпоративной культуры...

> Рекомендуется для избегания подобные проблем использовать системы, разрабатываемые компаниями с высокой корпоративной культурой

Каждый подъезд борется за звание дома высокой культуры...

Всё блин держится на людях и только. Высока была корпоративная культура в японском олимпусе...

И в моем случае вендор и автор - тоже одно. Т.е. любой E-mail на вендорские контакты попадает опять ко мне.

Если так, то конечно позор им!!

Хотя, например, вот тут, owner (это vendor пакета как я понимаю) некий Limb, Linux Administrator in Chicago. Но, тем не менее, адрес проекта там указан.

trll md 1

По сообщению авторитетных разработчиков, анализ безопасности систем на базе Linux выполняется частично и выборочно, что вызвано проблемами во взаимодействии сообщества разработчиков, аналитиков и остальных специалистов. Рекомендуется для избегания подобные проблем использовать системы, разрабатываемые компаниями с высокой корпоративной культурой. От себя добавим, что такими в 2012 году журналом F>>> были признаны...

+)

RAII - хорошая штука, да. В данном случае, конечно, имел место хак: есть два буфера (для Raw и для обработанного изображения), но чтобы старый код работал без изменений, эти два буфера в момент работы этого кода - один буфер. А в обработчике исключений освобождаются оба.

И в моем случае вендор и автор - тоже одно. Т.е. любой E-mail на вендорские контакты попадает опять ко мне.

> Вендор - я.

Я в курсе ;)

> И вот хер я теперь буду писать нормальные описания решенных проблем в changelog.

Ну почему?
Реально заэксплоитить большинство таких вещей очень трудно, но иногда попадаются реальные проблемы, поэтому так и носятся с этой фигнёй.
Я бы в чейнжлоге писал "affected releases x.xx - y.yy" чтобы исключить какое-либо 2е толкование. Наверняка в чейнжлоге для 0.15.1 было написано, что пофиксено, а когда появилось - нет, вот они и вписали все релизы до фикса.
Скорее всего реально никто ничего не анализировал - просто увидели чейнжлог, увидели фикс попадающий по определённый патерн и отрепортили проблему в предыдущих релизах, чтобы народ знал и не наступал на грабли. А то, что он появилось только в 15.0 - там не было написано ;)
Но конечно обидно ;)

Или becomes. Или не becomes. Тут уж как пойдет....

> Равно как является ли проблемой такой псевдокод a = malloc(..); free(a); free(a);

http://cwe.mitre.org/data/definitions/415.html

When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

Вендор - я.

И вот хер я теперь буду писать нормальные описания решенных проблем в changelog.

А как? Нужно чтобы в окошке кто-то что-то аллоцировал?

free(0) и free(NULL) по стандартам C и C++ безопасно.

http://xkcd.com/1172/