В опубликованном на прошлой неделе выпуске криптографической библиотеки Libgcrypt 1.9.0, которая используется в GnuPG, выявлена легко эксплуатируемая критическая уязвимость, позволяющая добиться переполнения буфера при попытке расшифровки специально оформленных данных, на стадии до верификации или проверки цифровой подписи. Уязвимость затрагивает GnuPG и другие приложения, использующие уязвимую версию Libgcrypt...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54489
> из-за некорректного определения размера буфера для расшифруемого блокатипикал си
Не трожь наш язык от бога. Ничего лучше него придумать невозможно, Си - совершенство эволюции. Всё, что хоть немного лучше - это для проклятых хипстеров которые ниасилили святое.
Эволюция свернула не туда...
Кто ж виноват что хипстеры не системщики а вебмакаки? Вот и пользуемся тулсами от Древних, они в отличие от вебмакак знали что и зачем делают а не просто хайповали.
Богов, кстати, было 2.
Bug-ов?
Кто из-них бог?1. Ритчи создал язык Си.
2. Томпсон создал UNIX, а также язык Би - непосредственный предшественник Си.
3. Керниган помог написать книжку: "The C Programming language".
Поправка принимается, нехай будет трое.А так - по сравнению с смузихлебами, любой их програмеров той эпохи - godlike. Он комп с нуля заводить умеет, в отличие от ламо с питонохрустом.
есть ещё Go, непосредственный приемник Limbo.
есть ещё D, каким и должен был быть C++
ну и rust - с боку припёку язык для контроллеров.
дурачок, си это инструмент, а не религия
На месте надо писать, не будет таких косяков
Не пишите программы - и в них не будет багов, проверенный способ! :)
Типикал опенсорс. Зоркий глаз только через два года заметил, что у сарая нет стены.
> Fedora 34 (Rawhide) и Gentoo.Походу таки не 2 года и прилетело только тестовым манекенам, которые для этого как раз и существуют.
> глаз только через два года заметилТвой глаз скорее всего заметил это:
> В опубликованном на прошлой неделе выпуске
Но мозг ничего не понял, так как он спит, а копчик, который за него, незаметно дал команду поскорей выплюнуть желчный вы$ер про "опенсорс,гну,яп,гпл,линукс,бсд,что-угодно...", сформированный по одному единственному шаблону-на-все-случаи, после чего почувствовать себя значимым и испытать довольство собой, временно заглушив смутный глубинный страх рождённый интуитивным осознанием своего бессмысленного и бесполезного существованиея.
При чем тут си, если макаки кривоукие писать не умеют, я вот недавно на нем хелло ворлд писал и никаких проблем
Хаха, начинается)) "Это неправильные программисты, они пишут неправильный код", "а вот правильные программисты"...
Если этот программер таки криворукая макака, то какого вы разрешаете ему контрибьютить в криптолибу? Как это изменение прошло код-ревью (он же был, я надеюсь) - ошибку не заметили ревьюверы и возможно мейнтейнер проекта.
Т.о. тут не одна макака криворукая, а целая куча.
Либа опенсорсная, перепишите по своему. Другой вопрос, что дистрибутивов, которые легко отнесутся к тому, что вы просто взяли и впихнули пакет не от DJ Ментейнера (даже если все зависимости будут соблюдены), по пальцам пересчитать можно.А так да, криворукая макака тут ещё и сам юзер по сути, который знает, что имеет дело с сборкой от васяна (по факту же), но слепо верит ему настолько же, как и хоть и индусу, но на зп.
>типикал сиНадо было на Javascript писать.
Даже растофанатики выяснили что дело не в языке, после текущего редокса, а дело в руках программиста. И никто не говорил что эта уязвимость в библиотеке появилась случайно, «программист» мог специально добавить недокументированное поведение.
И только дырописатели на сишке не видят разницы в утечке памяти и выходе за границы буфера.
> И только дырописатели на сишкехелловротписатели на сишке это, потому что на полном серьезе приравнивают "утечку" (в кавычках) в _ядерном менеджере памяти_ к утечке в юзерспейсе.
> Даже растофанатики выяснили что дело не в языке, после текущего редоксаЛол. Ну ничего, сейчас они начнут дагадываться зачем у нас valgrind, kasan, статический анализ, фаззинг и прочие странные вещи про которые они вопили "этанинужна!!!111 хатим просто прогать и не думать!!!111"
>> Даже растофанатики выяснили что дело не в языке, после текущего редокса
> Лол. Ну ничего, сейчас они начнут дагадываться зачем у нас valgrind,То ли дело местные Эксперды - умеют ловить "утечки памяти" в ядерном менеджере памяти валгриндом, ога.
> статический анализ,Учитывая, что он в ржавчине из коробки в разы мощнее - Эксперд и тут слышал звон.
>> статический анализ,
> Учитывая, что он в ржавчине из коробки в разы мощнееКто "он" и мощнее чем что? Что с чем ты сравниваешь?
>>> статический анализ,
>> Учитывая, что он в ржавчине из коробки в разы мощнее
> Кто "он" и мощнее чем что? Что с чем ты сравниваешь?Анализ, очевидно. Эксперд выше ляпнул "начнут дагадываться зачем у нас ... статический анализ ... и прочие странные вещи про которые они вопили "этанинужна!!!111 хатим просто прогать и не думать!!!111"
Видимо посчитав, что продвинутая система типов, ownership и borrow checker работает не иначе как через либастрал.
> из-за некорректного определения размера буфера для расшифруемого блока
> типикал сиTypical lasy stupid. Т.к. вот оно:
> ... присутствовало допущение, что ...А допущениев в реале-то нельзя делать вообще. Вот тогда работает лучше и на сИшечге и на бАшеке - на всём.
Вот когда в ядре RUST посыпяться идентичные ошибки - вот тогда и смешно будет.
Кстати, появилась альтернатива секвое для использования в качестве либы - https://github.com/rpgp/rpgp
> Rust 99.0%Очень хорошо!
Как всегда, нужный 1% кода, который всё делает - на Си, и 99% - обвязка на расте.
> Как всегда, нужный 1% кода, который всё делает - на Си, и 99% - обвязка на расте.Кинуть ссылку на этот сишный код тебя не затруднит? Или как всегда, сморозил глупость с умным видом?
Language Files Lines Code Comments Blanks
===============================================================================
JSON 48 364 364 0 0
TOML 3 115 100 0 15
Shell 3 114 78 15 21
Scheme 1 66 28 30 8
YAML 1 34 26 2 6
Plain Text 22 75 0 75 0
-------------------------------------------------------------------------------
Rust 92 16057 13278 574 2205
|- Markdown 69 791 160 569 62
(Total) 16848 13438 1143 2267
-------------------------------------------------------------------------------
Markdown 6 328 0 240 88
|- Rust 1 2 2 0 0
(Total) 330 2 240 88
===============================================================================
Total 176 17153 13874 936 2343
Когда уже твой раст без питона и "дырявой сишки" можна будет собрать: https://www.opennet.ru/openforum/vsluhforumID3/123086.html#386
когда уже дырявую сишку можно будет собрать без баша, перла, питона?
В каком месте мой makefile требует баш, перл и питон?
> В каком месте мой makefile требует баш, перл и питон?https://gcc.gnu.org/install/prerequisites.html
> Perl version between 5.6.1 and 5.6.24
Да, это разумеется проблема и когда-то сделать полный бустрап. Просто еще не успели переписать все что сишники наговнокодили за почти 50 лет его существования. А питон - чего его выкидывать? Вполне безопасный язык, медленный правда, но для скриптов скорость и не нужна.
И еще 50 лет переписывать будут. А там либо шах, либо ишак.
> все что сишники наговнокодили за почти 50 лет его существованияНу ты же этим, я надеюсь, не пользуешься? В смысле, ты же не жрёшь то, что обсираешь и не обсираешь то что жрёшь? ... но как-то же ты сумел сюда об этом написать, хм-м-м...
Факт что ты ездишь по плохим дорогам лишает тебя права критиковать плохие дороги? Ты ешь в офисной столовке - поэтому не имеешь права жаловаться на пересоленый суп? Или ты сам пойдешь и сваришь его?
Логика просто шикарная.
Я на эти дороги плачу деньги (и уже не один десяток лет). Поэтому когда я их критикую, я в роли заказчика, которого на@#$ли исполнители - деньги взяли, а работу сделали плохо.С офисной столовкой случай совсем другой - если суп пересолен, то я именно это критикую и могу продолжать там питаться - это нормальная критика. Но если я кругом кричу что "они криворукие уроды и готовят сплошное говно" (это уже не критика, кстати) и продолжаю ходить туда есть, то это уже я двуличная скотина.
Вот такая вот "тонкая" грань.Если я говорю про столовку "там одно говно", то я хожу в другую. А если нет желания и/или возможности ходить в другую, то и нечего бросаться громкими словами. Вот такая логика.
Чтобы расставить: пренебрежительное "наговнокодили", причем сказанное огульно, про всё сразу - это ни разу не критика, это аналог воплей "в этой столовке сплошное говно". В этом случае - либо не пользуйся, либо извинись и заткнись.
Тысячи глаз. У меня то как раз 1.9.0. Я так понимаю всякие nettle более низкоуровневые, а сабж практически нигде за пределами gnupg не используется? Если это так, то всё же есть логика в том чтобы избегать подобных обскурных высокоуровневых прослоек.
Из заметных пользователей kwallet и pidgin-otr, И libktorrent внезапно.
> и вызвана изменением в новой реализации хэш-функций, внесённым около двух лет назадРаботает - не трогай!
«Не сломалось - не чини» - известный девиз говнокодеров. Поскольку у них всё на соплях, малейшее движение рушит всю систему. Поэтому да. Ценный совет.
Не обязательно, просто новый непроверенный код будет с багами. А старый ломается в основном потому, что это теперь другой разработчик, который может быть в курсе некоторых аспектов. Или он в силу разных обстоятельств не может обеспечить тех уровня качества и рецензированности, что и прошлый разработчик.
> просто новый непроверенный код будет с багамиС одной стороны - да. Это неизбежно.
С другой стороны, из этого следует, что программы писать вообще нельзя - ведь они неизбежно будут с багами. А если даже ты собрался с духом и что-то написал, то ни в коем случае нельзя делать новые фичи или чинить баги. Ведь починка бага - это тоже новый код. Что, разумеется, абсурд.
На самом деле понятно, что программы писать надо, и улучшать их тоже надо, иначе нахер они кому нужны будут - несуществующие или без фич?
Другое дело, что есть техники по минимизации количества багов. Отчасти это зависит от языка (Си - плохой вариант), отчасти от уровня квалификации программиста - насколько он хорошо знает и понимает software engineering? Умеет ли правильно писать тесты? Пишет ли их? Понимает ли он, что алгоритмы в коде и состояния программы должны быть максимально простыми и следовательно предсказуемыми?
А самое главное, умеет ли он писать код так, что бы другой разработчик случайно что-нибудь не поломал? Это уже в основном зависит от фич языка. Через язык ты должен иметь возможность выразить все необходимые инварианты, что бы компилятор если что не пропустил их нарушения. Для этого нужна сильная система типов (поэтому Си, как и Го - в пролёте). Ну и разумеется умение этого первого программиста этой системой пользоваться в нужном направлении.
У си довольно приличная система типов - вот что-что а на типы он вонять умеет неплохо. Сидиотничать можно, конечно, но все же.
Вы неочень понимаете о чём речь идёт.
В С с некоторой точки зрения вообще типов нет.Что-то конечно похожее есть, но, войд указатель это всё стирает как та чёрная дыра.
Скорее их нет чем они есть в общем.
Я то как раз очень хорошо понимаю что в сишке с типами. И знаю что если я дам ему что-то левое, вонять будет. А void* примерно как unsafe в расте. То-есть поюзать на свою задницу можно, но корректность того что за этим следует на совести програмера.И да, без таких вещей яп просто не будет пригоден для системного программирования. И там вообще так по жизни довольно много небезопасных вещей. Так вон даже GOпники с фуксией вроде задолбались, что-то дрова и системные компоненты на го им не нравится :). Наверное, секрет в том что тявкать из кустов одно, а програмить это - другое.
> А void* примерно как unsafe в расте.Нет. unsafe в расте позволяет лишь две особые вещи: вызов unsafe функции и разадресацию raw-указателя. Собственно для этого и используется. void* же в C используется для полиморфизма, потому что система типов иначе не умеет. То есть вещи, которые вообще-то не являются небезопасными делаются программистом небезопасными, потому что иначе никак.
Например, в libc есть функция qsort:
void qsort(void *base, size_t nmemb, size_t size,
int (*compar)(const void *, const void *));Программист вызывающий функцию должен сам всё чётко проверить, чтобы если base имеет тип T*, то compar был бы типа int (*)(const T*, const T*). Он должен проверить, чтобы nmemb был бы равен количеству элементов в массиве. Чтобы size был бы равен sizeof(T). Эти проверки вполне возможно выполнить, но когда эти проверки надо выполнять на каждом шагу, то некоторые неизбежно выполняются ошибочно. Или они станут ошибочными после каких-то изменений.
Хотя параметрическая типизация легко спасает от этого, в гипотетическом C с темплитами это могло бы выглядеть так:
template<T> void qsort(T* base, size_t nmemb, int (*compar)(T*, T*));
Видишь? Теперь единственный способ ошибиться -- это передать кривой nmemb. Накосячить с типами невозможно, потому что когда ты присунешь в вызов функции указатели на массив и на функцию, компилятор проверит, чтобы их типы соотносились бы определённым образом. А если ещё добавить идею слайса (нисколько не динамического массива, но "знающего" свой размер), как структурки вида {T* base; size_t nmemb}, и заменить ими C'шные массивы, то тогда ещё проще, и компилятор выполнит все проверки:
template<T> void qsort(T base[], int (*compar)(T*, T*));
И теперь уже совершить ошибку невозможно. Ошибка может быть зарыта в qsort, который может, например, выходить за границы переданного слайса, но это вряд ли. И надо будет исхитряться, чтобы такой qsort заставить сделать что-нибудь плохое: надо как-то создать кривой слайс base, но если создание слайсов и подслайсов выполняется операциями известными компилятору, который может проверить во время компиляции, что подслайс целиком содержится в слайсе, то придётся реально исхитрятся чтобы создать кривой слайс. Это легко сделать злоумышленно, но случайно скорее всего не выйдет.
И, заметь, это даже без деления кода на safe/unsafe, просто изменена система типов: в неё добавлены параметризованные типы и слайсы. void* в C нужен как костыль для полурабочей системы типов, потому как без него она не юзабельна.
>и компилятор выполнит все проверкиРазработчики компиляторов Си бросили все силы на то чтобы сделать этот "портируемый" язык портируемым. И получается всё еще плохо. Какие там проверки.
> Я то как раз очень хорошо понимаю что в сишке с типами.Без толики упрёка, я боюсь, что вы в принципе очень плохо понимаете что такое типы, и почему их в Си нет. Я вот сам не очень понимаю, потому что тема сложная, но понимаю настолько чтобы знать, что их в Си нет.
>И да, без таких вещей яп просто не будет пригоден для системного программирования.
Вы правы отчасти.
Системное программирование такой-же маркетинговый булщит как скорость и портируемость Си.
Си даёт вам прямой доступ к части функционала ЦП(который изначально под выполнение Си кода заточен).Проблема однако в том, что, при попытке написать корректно работающее безопасное(в широко смысле) ПО вы используя этот прямой доступ неизбежно переизобретете велосипед(менеджер памяти набор методик специальные макросы и прочее прочее вплоть до ручного добавления проверки переполнения буфера на протяжении 30 лет "развития" вашего ПО) который миллион раз уже изобрели (причем 20 лет назад) и который изобретать еще раз нет никакой абсолютно необходимости.
Кстати, а эти либы сишные вроде либжкрипта и опенссл вообще юнит тестами покрывают?
Удивительно, но тесты есть.
https://github.com/gpg/libgcrypt/tree/master/tests
https://github.com/openssl/openssl/tree/master/test
Покрытие правда неизвестно, кто хочет может поискать.Но такой баг тестами покрыть сложно - там нужны особые входные данные. Возможно бы помог fuzz testing, но это уже хипстота и смузихлебство, настоящий сишник на такое не пойдет.
Вот те раз, syzkaller то оказывается - хипстота?!
>Для этого нужна сильная система типов (поэтому Си, как и Го - в пролёте).Не могли бы пояснить, почему в Go слабая система типов?
P.S. Только щас понял, что возможно имеет место конфуз - под сильной я имею ввиду "фичастую", а не в смысле strongly / weakly typed. :)>>Для этого нужна сильная система типов (поэтому Си, как и Го - в пролёте).
> Не могли бы пояснить, почему в Go слабая система типов?- Нет дженериков. Причём сам создатель языка (Роб Пайк) сказал, что в Гугле работают тупые мартышки которые не могут осилить сложные концепции, поэтому язык Го - мега-тупой, то есть дженериков там нет не потому, что они не нужны, а что бы у сотрудников Гугла голова случайно не заболела
- Нет dependent types - а они есть даже у прости господи фронтэндщиков (TypeScript)
- Нет sum types / tagged unions
- Даже явного указания на реализацию какого-то интерфейса нет - там тупо duck typing. Программирование через "а вдруг мне повезёт и у этого типа будут функции совпавшие по сигнатурам с сигнатурами вон того типа" - это дорога в непредсказуемые баги
Может ещё чего-то нет - можно погуглить про критику Го и почитать про то, почему это язык застрявший своими концепциями в 1960-ых.
Пример языков с сильными системами типов - Scala, Haskell, TypeScript. Это не значит, что они во всём хороши - просто как пример, можно посмотреть им в доку и почитать какие фичи даёт язык, с примерами как это применять и тд. На типах TypeScript например написали исполнитель SQL-запросов на стадии компиляции просто как демонстрацию крутизны компилятора.
> (Роб Пайк) сказал, что в Гугле работают тупые мартышки которые не могут осилить сложные концепцииГугол ПИТОН у себя этим заменял!!! Что вы от питонистов хотели? Low entry barrier же.
> «Не сломалось - не чини» - известный девиз говнокодеров.Дебианщики как-то раз починили не сломаное. Нет, буфера не переполнялись, но вообще все возможные варианты ключей которые их openssl мог генерить описывались примерно 6Мб блеклистом. Как вы понимаете - это ультра-мега-критикал, когда 6-метровый список содержит ВСЕ ключи ВСЕХ дебианов и прочих убунт на планете. Просто потому что хакеры его быстро сгенерили и пошли получать рут по ssh на вообще всех машинах которые найдут.
> выявлена легко эксплуатируемая критическая уязвимость, позволяющая добиться переполнения буфераВ голосину)
Ахахахаха. Критическая уязвимость от переполнения буфера в либе используемой в ГНУтой утилите для шифрования и подписи данных.
Oh, wait. You're serious. Let me laugh even harder.А по факту... Даже слов нет. Там еще срач не затих про уязвимость sudo, так тут еще подбросили на вентилятор. И всего два года назад добавили, прям свежак.
> sudo
> вентилятор
Он кстати единовременно с судо обновился, наверно такая же хрень.
Хрень, но вообще совсем другая. Он что-то не так делал с PATH, не очищал его чтоли. Это само по себе к выполнению кода не ведет, но авторы предпочли перестраховаться и получили CVE потому что видимо это позволяет довольно нестандартно одурачивать другие программы или юзера методом не соответствующим докам.Вот это я понимаю, культурный подход к секурити.
Спасибо, дорогой, за информацию! Fixed!opendoas-6.8.1-2
>Да сделайте уже лучше-то! А то такой талант на опеннетах пропадает.
pacman -Ss libgcrypt
core/libgcrypt 1.9.1-1 [установлен]
Держу в курсе!
А в Манжаре до сих пор даже в тестовой ветке:core/libgcrypt 1.8.7-1 [installed]
Молодцы что не гонят коней)
а мне говорили, что в арче новые версии появляются за два дня до их релиза, обманули?
Манжара это не Арч
+ , печальная история на самом деле. Надо начинать пилить своё LFS с пакманом и доасами
фрактал кукумбер
В промышленных дистрибутивах дырка не появилась, вот и славно.
Какие популярные приложения пострадали?
> Какие популярные приложения пострадали?Freaktail Firmware v0.01
Fedora 34 и Gentoo, правда они не очень популярные.
>позволяющая добиться переполнения буфераРаст
Где ж вы с фракталом были? Покажите нам как крипту кодить. А мы посмотрим сколько CVE навешаете в крипто вы...
Далек например гляньте.
Айсис Агора Лавкрафт на ютубе рассказывает.
а кроме как "на ютубе рассказывает" - есть применения?
Может на тиктоке еще глянуть? Странные какие-то места чтобы крипто затариться.
> Может на тиктоке еще глянуть? Странные какие-то места чтобы крипто затариться.А какие не странные? Чем по вашему ютуб странный для обсуждения криптографии?
На нем и профессора выступают на эту тематику.
Ну вот ещё выше было https://github.com/rpgp/rpgpИ раз уж о крипте речь зашла, то её реализация это сложный процесс в котором легко себе заднюю часть отстрелить гранатомётом.
Последнее что в этом процессе нужно это возможность ещё и в ногу себе стрелять.
> это сложный процесс ... легко себе заднюю часть отстрелить гранатомётомт.е. раст тут никак не поможет.
Чуть-чуть поможет, но переписывание может не стоить того
Чуть-чуть поможет. И сколько-то помешает. При том в отличие от сей это вы как раз и протестируете на себе. И если там потом окажутся какие-нибудь ключи предсказуемые или тупняк в экспоненте, починеный вон теми олдскульщиками 15 лет назад - кто ж из хипсторов на чужих ошибках то учится? Это неспортивно.
Звучит как-то так:
"Есть средство, позволяющее избежать хорошей части ошибок работы с памятью, но мы им пользоваться не будем, все равно где-нибудь еще ошибемся"Сгорел сарай - гори и хата. И это при второй на этой неделе ошибке из-за битья памяти
На нём разве можно что-то написать работающее? Даже Мозила уже отказалась и выгнала растаманов.
>На нём разве можно что-то написать работающее?На нём можна отлично посылать ненависников на /dev/null
Нет софт, нет узявимостей. Язык на 100% безопасен.
Раст не спасает от говнокода. Даже безголовый фрактал в этом месте напишет unsafe и выйдет за все мыслимые границы.
Жаль что не на стадии проверки подписи - опять всякие говнодистры, не использующие TLS для доставки пакетов, и их пользователей поимели бы.
Поиметь реально только федору и генту. Зачем вам эти багодромы? У вас бэкдор через неделю сдохнет в жестоких глюках %)
> Критическая уязвимость в Libgcrypt ... затрагивающая systemdКритическая уязвимость в Libgcrypt ... затрагивающая другую критическую уязвимость.
>> Критическая уязвимость в Libgcrypt ... затрагивающая systemd
> Критическая уязвимость в Libgcrypt ... затрагивающая другую критическую уязвимость.Критические уязвимости — обьеденяйтесь!
Минус на минус даёт плюс
Смотря что перемножать... (-i)*(-i) = -1
Одна уязвимость создана чтобы следить за другой.
> эксплуатируемая критическая уязвимость, позволяющая добиться переполнения буфера при попытке расшифровки специально оформленных данных, на стадии до верификации или проверки цифровой подписи.Заказ товмайора, а то зашифровались все, почитать нечего, скушно..
> уже успели включить в состав репозиториев Fedora 34 (Rawhide) и Gentoohttps://packages.gentoo.org/packages/dev-libs/libgcrypt
Стабильна версия в Gentoo: libgcrypt-1.8.6 уязвимости не подвержена.
Этот баг очень хороший аргумент за использование стабильной ветки Gentoo, а не тестовой.
Было когда-то предложение разделить стабильную ветвь Gentoo на две: стабилизированная и верифицированная ветвь и сегодняшняя стабильная. Наверно надо было, а сегодня есть желающие тянуть?
Да они называются Ubuntu LTS и CentOS 7
Debian еще есть, 10-й. Из него меньше подарков выковыривать чем из убунт
опять это пресловутое переполнение буфера...
когда уже программы начнут писать программисты, а не дворники?
Когда ты уже начнешь думать головой и перестанешь верить заголовкам. Это фича для кого надо, а не случайно ошибка разработчика.
шапочка из фольги не жмет голову?
В челябинске фольга настолько сурова что жмет голову.
Там проблема не в переполнении буфера, а ...> Изменение сводилось к оптимизации, заменяющей рекурсивный вызов функции на использование buf_cpy для копирования буферов. Оптимизация была добавлена для обеспечения постоянного времени выполнения операций с блоками, из-за опасения подверженности кода атакам, анализирующим зависимость скорости выполнения операций от обрабатываемых данных (timing attacks).
... а в мании прослушки.
> Изменение сводилось к оптимизации, заменяющей рекурсивный вызов функции на использование buf_cpy для копирования буферов. Оптимизация была добавлена для обеспечения постоянного времени выполнения операций с блоками, из-за опасения подверженности кода атакам, анализирующим зависимость скорости выполнения операций от обрабатываемых данных (timing attacks).Напомните, библиотека рассчитана на суперзащищенный ящик стоящий посреди поля, или на обычный десктоп, который находится за такой кучей "временнЫх" помех, что подобная оптимизация — следствие повальной истерии и паранои?
Когда не было яойфонов и суперзащит - люди летали на Луну...
Что системда шифрует? Че за бред вообще? Система инициализации и крипта? Теперь я видел все...
системда - это зародыш винды в линухе.
Винда лучше