The OpenNET Project / Index page

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

Уязвимость, устранённая в LibreSSL 2.0.2, подтолкнула к добавлению вызова getrandom в ядро Linux

18.07.2014 15:42

Разработчики проекта OpenBSD выпустили обновление переносимой редакции пакета LibreSSL 2.0.2, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. В новом выпуске устранена недоработка, которая может привести к серьёзным проблемам с безопасностью на платформе Linux.

Проблема связана с особенностью реализации в LibreSSL генератора псевдослучайных чисел (PRNG), который был завязан на возможности OpenBSD и не учитывал некоторые особенности платформы Linux. В частности, LibreSSL использовал изменение PID для отслеживания форков и инициирования переинициализации PRNG, но не учитывал, что один 16-разрядный PID-идентификатор может быть назначен двум и более ответвляемым процессам. В Linux гарантируется, что ответвлённые дочерние процессы будут иметь всегда разные PID, но допускается, что при определённых условиях PID может совпасть с идентификатором прародителя (после большого числа форков можно добиться совпадения PID дочернего процесса и прародителя).

В OpenSSL присутствует специальный код для отслеживания данной ситуации, но данный код был удалён в LibreSSL, так как он был неактуален для OpenBSD. В процессе создания переносимого варианта LibreSSL особенности формирования PID в Linux выпала из внимания разработчиков. Учитывая данную особенность исследователи безопасности подготовили тестовую программу, которая продемонстрировала возврат двух одинаковых значений при разных обращениях к генератору псевдослучайных чисел LibreSSL. Разработчики OpenBSD считают проблему раздутой и малоприменимой в реальных условиях. В частности, Bob Beck указывает на то, что недоработка является проблемой только автора демонстрирующей уязвимость тестовой программы, реальные приложения никогда не функционируют подобным образом.

Проанализировав возникшие в результате обсуждения проблемы и сомнения в корректности применения обходных путей для защиты от их проявления, Theodore Ts'o предложил включить в состав ядра Linux новый системный вызов getrandom, который является аналогом системного вызова getentropy, присутствующего в OpenBSD. Getrandom предоставит надёжную защиту от атак, основанных на исчерпании доступных файловых дескрипторов. При отсутствии свободных дескрипторов невозможно задействовать /dev/urandom, поэтому библиотеками активируется запасной вариант, использующий менее надёжный PRNG. Getrandom предоставит возможность получения случайных чисел от системного PRNG даже в условиях отсутствия свободных файловых дескрипторов.

  1. Главная ссылка к новости (http://threatpost.com/overblow...)
  2. OpenNews: Корректирующий выпуск LibreSSL 2.0.1
  3. OpenNews: Первый выпуск LibreSSL, форка OpenSSL от проекта OpenBSD
  4. OpenNews: Проект OpenBSD представил LibreSSL, форк OpenSSL
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: libressl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (63) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.3, Stax (ok), 17:25, 18/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD. Хотите, чтобы на других платформах нормально работало? Поддерживайте в своей ОС фичи из OpenBSD, и будет работать! Вот такая вот переносимость по-Теодоровски, ага..
     
     
  • 2.15, Клыкастый (ok), 18:34, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > Поддерживайте в своей ОС фичи из OpenBSD, и будет работать! Вот такая вот переносимость по-Теодоровски, ага..

    Собственно есть и строго обратная сторона: линуксизмы в софте, которые остальным приходится заменять. Если цель не холиварить, то очевиден выход. Кто заинтересован в портировании под свою платформу, тот и отслеживает такие моменты. Под BSD с солярки перетащили ZFS, да и под линукс втащили. Заменяя ОС-зависимые моменты. Пока никто не умер. Тем более у линукс разработчиков явно поболе, так что ситуация более выигрышная. Короче, отставить панику, всё ок.

     
     
  • 3.46, bOOster (?), 07:12, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это сплошь и рядом. Posix совместимость давно линуксоидов не интересует. Лепят все что Лукавый в голову стрельнет...
     
     
  • 4.58, Аноним (-), 11:43, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Это сплошь и рядом. Posix совместимость давно линуксоидов не интересует.

    Как видим, бздельники ничем не лучше в этом плане.

    > Лепят все что Лукавый в голову стрельнет...

    Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там лепят ни с чем не совместимые нетграфы, геомы, kqueue и что там еще. И это вроде как нормальным считается...

     
     
  • 5.68, bOOster (?), 16:39, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1 А ты никогда не задумывался что некоторые специфические фичи работающие по др... текст свёрнут, показать
     
  • 5.69, bOOster (?), 16:47, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там
    > лепят ни с чем не совместимые нетграфы, геомы, kqueue и что
    > там еще. И это вроде как нормальным считается...

    А да и Лукавый - это сатана а не чертенок со сковородой, который походу у многих Линуксоидов тут мягкое место подогревает. Да так что минусовать начинают даже не прочитав пост :)

     
     
  • 6.82, bOOster (?), 04:09, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там
    >> лепят ни с чем не совместимые нетграфы, геомы, kqueue и что
    >> там еще. И это вроде как нормальным считается...
    > А да и Лукавый - это сатана а не чертенок со сковородой,
    > который походу у многих Линуксоидов тут мягкое место подогревает. Да так
    > что минусовать начинают даже не прочитав пост :)

    У деревни Крюково - ВИА Пламя :) BSDшики :)

     
  • 3.59, Аноним (-), 11:48, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Собственно есть и строго обратная сторона: линуксизмы в софте, которые остальным
    > приходится заменять.

    Ну вон KMS+DRM стали новым стандартом взаимодействия ядер с юзермодом по части графики, не развалились. Почему оно в обратную сторону не должно работать, если некто хорошую идею подал - интересный вопрос. Наверное ЧСВ и NIH синдром надо строить, чтобы не вело к контрпродуктивным результатам.

     
  • 2.40, freehck (ok), 23:43, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD.

    На чём работать умеют, на то и затачивают.

     
     
  • 3.63, Аноним (-), 12:05, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > На чём работать умеют, на то и затачивают.

    Прекрасно, но зачем тогда было втирать очки про портабельность? Тогда systemd - тоже вполне портабельная программа.

     
     
  • 4.93, Аноним (-), 12:07, 22/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> На чём работать умеют, на то и затачивают.
    > Прекрасно, но зачем тогда было втирать очки про портабельность? Тогда systemd -
    > тоже вполне портабельная программа.

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

    А потом сделайте то же с systemd в OpenBSD/NetBSD/MacOS X.

    И вот только после этого что-то заявляйте.

     
  • 3.92, Аноним (-), 12:04, 22/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD.
    > На чём работать умеют, на то и затачивают.

    На самом деле, всё сделано просто: LibreSSL использует всё, что ему нужно, а если в искомой ОС (не-OpenBSD) нет каких-то возможностей, то при сборке подключается необходимая "добавка" кода. Таким образом имеем читаемый (ergo, понятный, ergo, менее грабельный) код и при этом хорошую переносимость. Именно таким образом организованы остальные дочерние проекты OpenBSD, и на их портабельность, вроде, особо не жалуются.

    А разработчики LibreSSL выпустили уже 2.0.3. :)

     

  • 1.8, Аноним (-), 18:21, 18/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Мало что-ли /dev/random и /dev/urandom устройств?
     
     
  • 2.11, Аноним (-), 18:26, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Мало что-ли /dev/random и /dev/urandom устройств?

    Ага, и оба - не аппаратные.

     
     
  • 3.42, Grammar_Nazi (?), 00:26, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > и оба - не аппаратные

    и оба неаппаратные

     
     
  • 4.43, Xasd (ok), 04:51, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    двоечник. :)

    "не аппаратные" -- раздельно.

    слово "неаппаратные" (слитно) -- тоже существует, но в данном случае нужно не оно.

     
     
  • 5.84, pavlinux (ok), 06:02, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > двоечник. :)
    > "не аппаратные" -- раздельно.
    > слово "неаппаратные" (слитно) -- тоже существует, но в данном случае нужно не оно.

    Программер отъымэл филолога =)
    Да Grammar_Nazi, срочно прими таблетку Даля и клизму Ожегова.

     
     
  • 6.89, arisu (ok), 10:56, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да, павлуша окончательно деградировал: xasd «программером» считает. осталось теперь подвальных бомжей в интеллектуалы записать — и будет совсем хорошо.
     
  • 3.60, Аноним (-), 11:50, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ага, и оба - не аппаратные.

    И это хорошо. Ибо на слово верить американскому дяде Сэму и его АНБ - нафиг надо!

     
     
  • 4.91, Аноним (-), 13:30, 21/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Точно, у меня в проекте чип имеет аппаратный генератор. Вся информация - это одна строчка в описании регистра:
    31:0 random_number R 0xXXXXXXXX This register contains a random 32 bit number which is
    computed each time it is read.
    О качестве генератора можно только догадываться.
     
  • 2.41, Grammar_Nazi (?), 00:20, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "что ли", ёпта
     
  • 2.45, Xasd (ok), 05:53, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Мало что-ли /dev/random и /dev/urandom устройств?

    согласен (особой надобности в этом getrandom нет)..

    хочу сказать что, если в самом начале (фаза инициализации) открыть файловый дескриптор связанный с /dev/(u)random ,

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

    всё равно уже открытый файловый дескриптор -- будет функионировать и клонироваться нормально.

    особой надобности в этом getrandom нет -- но если сделают это -- хорошо. пусть будет :) ..

     
     
  • 3.48, linux must _RIP__ (?), 07:33, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а что делать вновь запускаемым процессам? или процессы использующие криптографию должны запускаться строго из инит? лимит он такой.. в любой момент могли сказать ой.. при запуске очередного apache демона использующего ssl к примеру..
     
     
  • 4.51, Аноним (-), 08:31, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Открывать /dev/urandom (а потом уже всё остальное)
     
     
  • 5.71, linux must _RIP__ (?), 18:34, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Открывать /dev/urandom (а потом уже всё остальное)

    а точно php/питон/чтотам придумаешь - будет знать что будет работать именно с криптографией? у него доступа в /dev/astral нету.. угадывать по звездам еще не научился.. Да и держать лишний открытый дискритор из расчета - а вдруг что-то потребуется - это уже перебор.

     
  • 4.55, Аноним (-), 11:38, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а что делать вновь запускаемым процессам?

    Если процессу не хватило дескрипторов - там в общем случае даст дуба отнюдь не только криптография.

     
  • 4.67, Crazy Alex (ok), 15:19, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Умирать на старте, разумеется
     
     
  • 5.70, linux must _RIP__ (?), 18:32, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    зачем умирать когда можно работать? Не считая того что вызов syscall сильно дешевле чем open + read + close...
     
     
  • 6.78, Аноним (-), 20:31, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Только read считай :-) .. open только один раз, а close вообще не надо (fd закроется автоматом при закрытии процесса)
     
  • 4.77, pavlinux (ok), 20:26, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > а что делать вновь запускаемым процессам? или процессы использующие криптографию должны
    > запускаться строго из инит? лимит он такой.. в любой момент могли
    > сказать ой.. при запуске очередного apache демона использующего ssl к примеру..

    Проблема вроде банальная, а самом деле гиморрой сильнейший!

    Решений несколько, одно глобальное - делать /dev/random частью псевдодевайсов: STDIN, STDOUT, STDERR и добавить STDRND.

     
     
  • 5.90, Xasd (ok), 16:24, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    STDRND (плюс к SDTIN, STDOUT, STDERR) -- это было бы отличной идеей.

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

     
  • 3.76, слоупокк (?), 20:09, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Открою страшную тайну: счётчик открытых файловых дескрипторов уменьшается при создании процесса.
     
     
  • 4.83, pavlinux (ok), 05:59, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это чо за талант? o_0 Мож увеличивается?
     
  • 2.47, bOOster (?), 07:17, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Мало что-ли /dev/random и /dev/urandom устройств?

    И оба неприемлимы к использованию в криптографии.

     
     
  • 3.56, Аноним (-), 11:39, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > И оба неприемлимы к использованию в криптографии.

    С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого переламерит"?

     
     
  • 4.57, arisu (ok), 11:42, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого
    > переламерит"?

    нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.

    не стоит обращать внимания: это существо феерически тупое во всём, о чём говорить пытается.

     
     
  • 5.61, Аноним (-), 11:52, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не
    > знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.

    Капитан Очевидность спешит на помощь! Ну спасибо, Кэп, я подозревал :). Но до последнего момента надеялся что межушный нервный узел оппонента все-таки немного включится.

    > не стоит обращать внимания: это существо феерически тупое во всём

    Знаешь, Кэп, иногда достаточно посмотреть на ник и его написание чтобы многое осознать еще далеко на подлете. Так что я на самом деле всего лишь пытался потыкать корм палочкой на самом деле :)

     
     
  • 6.64, arisu (ok), 12:06, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > до последнего момента надеялся что межушный нервный узел оппонента все-таки немного
    > включится.

    я пробовал и добрыми словами, и словесными пинками. неа, там военно-полевая облегчённая модель, умеет только базовые функции.

     
     
  • 7.74, linux must _RIP__ (?), 18:41, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    да да. о компрометации /dev/random забыли ?

    http://everything2.com/title/Compromising+%252Fdev%252Frandom

    все еще можно использовать после этого в криптографии?

     
     
  • 8.75, arisu (ok), 18:55, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    всё-таки я не понимаю, как можно жить на свете с таким идиотизмом ... текст свёрнут, показать
     
     
  • 9.85, bOOster (?), 09:02, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я одного не понимаю, как ты живешь с генератором случайных чисел от таймера CPU ... текст свёрнут, показать
     
     
  • 10.86, bOOster (?), 09:06, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    u забыл Но недалеко ушел ... текст свёрнут, показать
     
  • 10.88, arisu (ok), 10:42, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    молодец, чётко свой идиотизм демонстрируешь ... текст свёрнут, показать
     
  • 9.87, bOOster (?), 09:42, 20/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А PRNG можешь засунуть себе в одно место и проворачивать Регулярно будешь зам... текст свёрнут, показать
     
  • 6.73, linux must _RIP__ (?), 18:37, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не
    >> знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.
    > Капитан Очевидность спешит на помощь! Ну спасибо, Кэп, я подозревал :). Но
    > до последнего момента надеялся что межушный нервный узел оппонента все-таки немного
    > включится.

    да да. за одно объясни почему их аж 2 рандома :-) и вспомни дыры в реализации датчиков случайных чисел которые находили в ядре.. забыл? так гугл в помощь.. после таких дыр ты точно согласен использовать данные напрямую ?

     
  • 5.72, linux must _RIP__ (?), 18:35, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого
    >> переламерит"?
    > нет, это просто написавший — идиот,

    как легко оскорблять другие мальчик. выучил уже уроки? понахватался на улице словечек? или мама не научила хорошим манерам? хорошие же у тебя родители были..

     

  • 1.22, Аноним (-), 19:24, 18/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура! Хорошая штука. Нужно!
     
  • 1.23, Сергей (??), 19:24, 18/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Может посмотрим по-другому, оказывается в линуксе могут существовать и выполняться 2-а процесса с одинаковым PID, это фича или бага ядра...
     
     
  • 2.29, Аноним (-), 19:45, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не могут.
     
     
  • 3.33, Сергей (??), 20:43, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> не могут.

    А как же это
    В Linux гарантируется, что ответвлённые дочерние процессы будут иметь всегда разные PID, но допускается, что при определённых условиях PID может совпасть с идентификатором прародителя (после большого числа форков можно добиться совпадения PID дочернего процесса и прародителя).

     
     
  • 4.36, Аноним (-), 21:02, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    для этого прародитель должен завершиться до этого. PID всего ничего, их приходится повторно использовать.
     
  • 2.44, Xasd (ok), 04:58, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –5 +/
    тоже мне синсация - два разных процесса с одинаковым pid -- существовать мо... текст свёрнут, показать
     
     
     
    Часть нити удалена модератором

  • 4.62, Аноним (-), 12:03, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А где он по крупному соврал? PID файлы могут указывать на посторонний PID, если например программа внепланово завершилась. При сильном желании это можно обнаружить, но большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.
     
     
  • 5.66, arisu (ok), 12:10, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот если бы он остановился на констатации фактов и не писал свои идиотические домыслы…
     
  • 5.79, Xasd (ok), 21:22, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.

    именно так.

    вероятность этого события очень низкая -- но всё же эта вероятность есть -- до тех пор пока состояние процесса демона НЕ сохраняется в его родительском процессе (и оно как раз не сохраняется в sysvinit . сохраняется лишь pid-номер внутри текстового файла).

     
     
  • 6.80, Led (ok), 22:25, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.
    > именно так.
    > вероятность этого события очень низкая -- но всё же эта вероятность есть
    > -- до тех пор пока состояние процесса демона НЕ сохраняется в
    > его родительском процессе (и оно как раз не сохраняется в sysvinit
    > . сохраняется лишь pid-номер внутри текстового файла).

    Врёшь, ламерок. service stop смотри не только на $PID, но и на /proc/$PID/{comm,stat}. Так что совпадение только по $PID - не прокатывает.

     
     
  • 7.81, Xasd (ok), 23:32, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > service stop смотрит не только на $PID, но и на /proc/$PID/{comm,stat}

    все говно-bash-скрипты проверил? :-)

    некоторые вообще по killall убивают (даже не глядя на pid).

    да, sysvinit провоцирует делать плохие решения.

     

  • 1.26, crypt (ok), 19:38, 18/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так вызов включили или только предложили включить?
     
     
  • 2.38, anonymous (??), 21:24, 18/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>Getrandom предоставит надёжную защиту от атак, основанных на исчерпании доступных файловых дескрипторов.
    > как все сложно с  ПО.

    Fixed.

     
     
  • 3.65, Аноним (-), 12:07, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Fixed.

    Админь метлу или ящики - там попроще.

     
  • 2.52, Аноним (-), 09:17, 19/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну merge window сейчас, вообще-то, закрыто.
     

  • 1.50, Аноним (50), 08:21, 19/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    [сарказм]Почему бы не выпустить ещё один форк?[/сарказм]
     
  • 1.54, Аноним (-), 11:34, 19/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > невозможно задействовать /dev/urandom, поэтому библиотеками активируется
    > запасной вариант, использующий менее надёжный PRNG.

    Это называется "горе от ума".

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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