GNU/Linux

Доступен выпуск криптографической библиотеки Botan 2.12.0, применяемой в проекте NeoPG, форке GnuPG 2. Библиотека предоставляет большую коллекцию готовых примитивов, используемых в протоколе TLS, сертификатах X.509, шифрах AEAD, модулях TPM, PKCS#11, хэшировании паролей и постквантовой криптографии. Библиотека написана на языке C++11 и поставляется под лицензией BSD.

Среди изменений в новом выпуске:

Многие заголовочные файлы теперь помечены как только для внутреннего использования и приводят к выводу предупреждения при попытке использования в приложениях;

Добавлена поддержка использования оптимизаций NEON и AltiVec в обеспечивающей постоянное время выполнения реализации AES;

Повышена производительность реализаций RSA, GCM, OCB, XTS, CTR и ChaCha20Poly1305;

Добавлена поддержка генерации хэшей Argon2, размером больше 64 байт;

В DTLS проведена оптимизация операций разделения MTU и добавлена обработка обрывов соединений из-за проблем на стороне клиента с последующим пересоединением с того же номера порта;

Проведена оптимизация операций разделения MTU в

Добавлена поддержка индикации отката соединений TLS 1.3 до меньшей версии протокола;

Добавлена поддержка алгоритма создания цифровых подписей GOST 34.10-2012;

Увеличена производительность RDRAND на системах x86-64;

Добавлена поддержка аппаратного генератора псевдослучайных чисел, предоставляемого в процессорах POWER9, и увеличена производительность на системах POWER8 с инструкциями AES;

Добавлены новые утилиты "entropy", "base32_enc" и "base32_dec";

Обеспечена возможность использования модуля Python в Windows.

Представлен выпуск открытого сборочного инструментария Bazel 1.0, развиваемого инженерами из Google и используемого для сборки большинства внутренних проектов данной компании. Выпуск 1.0 ознаменовал переход к использованию семантического версионирования релизов и также примечателен внесением большого числа изменений, нарушающих обратную совместимость. Код проекта распространяется под лицензией Apache 2.0.

Bazel обеспечивает сборку проекта, запуская необходимые компиляторы и тесты. Сборочная система изначально спроектирована для оптимальной сборки проектов Google, в том числе сборки очень больших проектов и проектов, содержащих код на нескольких языках программирования, требующих расширенного тестирования и собираемых для нескольких платформ. Поддерживается сборка и тестирование кода на Java, C++, Objective-C, Python, Rust, Go и многих других языках, а также сборка мобильных приложений для Android и iOS. Поддерживается использование единых сборочных файлов для разных платформ и архитектур, например, один файл сборки без изменений может применяться как для серверной системы, так и для мобильного устройства.

Среди отличительных особенностей Bazel выделяются высокая скорость, надёжность и повторяемость процесса сборки. Для достижения высокой скорости сборки в Bazel активно применяются техники кэширования и распараллеливания процесса сборки. В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений (пересобираются только изменившиеся файлы) и распараллеливания процесса сборки. Инструментарий также гарантирует повторяемость сборки, т.е. результат сборки проекта на машине разработчика будет полностью совпадать со сборкой на сторонних системах, таких как серверы непрерывной интеграции.

В отличие от Make и Ninja в Bazel применяется более высокоуровневый подход к построению правил сборки, при котором вместо определения привязки команд к собираемым файлам производится применение более абстрактных готовых блоков, таких как "сборка исполняемого файла на языке С++", "сборка библиотеки на C++" или "запуск теста для C++", а также определение целевых и сборочных платформ. В текстовом файле BUILD компоненты проекта описываются как связка библиотек, исполняемых файлов и тестов, без детализации на уровне отдельных файлов и команд вызова компилятора. Дополнительная функциональность реализуется через механизм подключения расширений.

Разработчики анонимной сети Tor предупредили о проведении большой чистки узлов, на которых используется устаревшее программное обеспечение, поддержка которого прекращена. 8 октября заблокировано около 800 устаревших узлов, работающих в режиме релеев (всего в сети Tor более 6000 подобных узлов). Блокировка совершена через размещение на серверах директорий чёрного списка проблемных узлов. Исключение из сети необновлённых мостовых узлов (bridge) ожидается позднее.

В следующем стабильном выпуске Tor, который намечен на ноябрь, появится опция, по умолчанию отвергающая соединения с узлами на которых применяются выпуски Tor, время сопровождения которых истекло. Подобное изменение позволит в дальнейшем по мере прекращения поддержки очередных веток автоматически исключать из сети узлы, вовремя не перешедшие на актуальное программное обеспечение. Например, в настоящее время в сети Tor ещё встречаются даже узлы с Tor 0.2.4.x, который был выпущен в 2013 году, несмотря на то, что до сих пор продолжается поддержка LTS-ветки 0.2.9.

Операторы устаревших систем были уведомлены о планируемой блокировке в сентябре через списки рассылки и отправку индивидуальных предупреждений по указанным в поле ContactInfo контактным адресам. После предупреждения число необновлённых узлов снизилось с 1276 до примерно 800. По предварительной оценке в настоящее время через устаревшие узлы проходит около 12% трафика, большая часть которого связана с транзитной передачей - доля трафика необновлённых выходных узлов составляет всего 1.68% (62 узла). Прогнозируется, что вывод из сети необновлённых узлов незначительно повлияет на размер сети и приведёт к небольшому проседанию показателей на графиках, отражающих состояние анонимной сети.

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

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

В опубликованных в открытом доступе дампах исторических срезов с кодом BSD 3 в том числе присутствует и файл /etc/passwd с хэшами паролей основателей Unix. Так как пароли хэшированы методом DES, который для современной вычислительной техники не представляет проблем с подбором, энтузиасты попытались восстановить пароли, используемые основателями Unix.

Пароли почти всех основателей Unix были подобраны почти сразу. Например, пароль Брайна Кернигана представлял собой легко набираемую комбинацию "/.,/.,,", пароль Денниса Ритчи был "dmac", Кирка МакКузика - "foobar", а Стивена Борна - "bourne".

Исключение составил пароль Кена Томпсона. В 2014 году после нескольких дней вычислений пароль остался не подобранным. Несколько дней назад была предпринята ещё одна попытка и после более 4 дней подбора с использованием hashcat на системе с видеокартой AMD Radeon Vega64 пароль удалось определить (производительность подбора составила 930 миллионов хэшей в секунду). Пароль оказался "p/q2-q4!". Любители шахмат определили, что это начало ряда шахматных дебютов в описательной нотации. Кен Томпсон подтвердил данное предположение.

После опубликованного Фондом свободного ПО призыва пересмотреть взаимодействие с проектом GNU, Ричард Столлман объявил, что как действующий руководитель проекта GNU займётся вопросами выстраивания отношений с Фондом СПО (основная проблема в том, что все разработчики GNU подписывают соглашение о передаче имущественных прав на код Фонду СПО и ему юридически принадлежит весь код GNU). 18 мэйнтейнеров и разработчиков различных проектов GNU отреагировали совместным заявлением, в котором указали, что Ричард Столлман один не может представлять весь проект GNU, и что мэйнтейнерам пора выработать коллективное решение по новому устройству проекта.

Подписавшие заявление признают вклад Столлмана в становление движения свободного ПО, но также отмечают и то, что поведение Столлмана многие годы подрывает одну из основных идей проекта GNU - свободное ПО для всех пользователей компьютеров, поскольку, по мнению подписавших обращение, проект не может исполнять свою миссию, если поведение лидера отталкивает бо́льшую часть тех, кого пытается охватить (reach out to) проект. Проект GNU, который хотят построить подписавшие обращение, это "проект, которому каждый может доверить защиту своей свободы".

Под письмом подписались следующие мэйнтейнеры и разработчики:

Tom Tromey (GCC, GDB, автор GNU Automake)

Werner Koch (автор и мэйнтейнер GnuPG)

Carlos O'Donell (мэйнтейнер GNU libc)

Mark Wielaard (мэйнтейнер GNU Classрath)

John Wiegley (мэйнтейнер GNU Emacs)

Jeff Law (мэйнтейнер GCC, Binutils)

Ian Lance Taylor (один из старейших разработчиков GCC и GNU Binutils, автор Taylor UUCP и Gold linker)

Ludovic Courtès (автор GNU Guix, GNU Guile)

Ricardo Wurmus (один из мэйнтейнеров GNU Guix, GNU GWL)

Matt Lee (основатель GNU Social и GNU FM)

Andreas Enge (основной разработчик GNU MPC)

Samuel Thibault (коммитер GNU Hurd, GNU libc)

Andy Wingo (мэйнтейнер GNU Guile)

Jordi Gutiérrez Hermoso (разработчик GNU Octave)

Daiki Ueno (мэйнтейнер GNU gettext, GNU libiconv, GNU libunistring)

Christopher Lemmer Webber (автор GNU MediaGoblin)

Jan Nieuwenhuizen (GNU Mes, GNU LilyPond)

Han-Wen Nienhuys (GNU LilyPond)

Дополнение: К заявлению присоединилось ещё 5 участников:

Joshua Gay (спикер GNU и Free Software)

Ian Jackson (GNU adns, GNU userv)

Tobias Geerinckx-Rice (GNU Guix)

Andrej Shadura (GNU indent)

Zack Weinberg (разработчик GCC, GNU libc, GNU Binutils})

После года разработки опубликован релиз проекта VeraCrypt 1.24, развивающего форк системы шифрования дисковых разделов TrueCrypt, прекратившей своё существование. VeraCrypt примечателен заменой используемого в TrueCrypt алгоритма RIPEMD-160 на SHA-512 и SHA-256, увеличением числа итераций хэширования, упрощением процесса сборки для Linux и macOS, устранением проблем, выявленных в процессе аудита исходных текстов TrueCrypt. При этом, VeraCrypt предоставляет режим совместимости с разделами TrueCrypt и содержит средства для преобразования TrueCrypt-разделов в формат VeraCrypt. Разработанный проектом VeraCrypt код распространяется под лицензией Apache 2.0, а заимствования из TrueCrypt продолжают поставляться под лицензией TrueCrypt License 3.0.

В новом выпуске:

Для не системных разделов максимальная длина паролей увеличена до 128 символов в кодировке UTF-8. Для обеспечения совместимости со старыми системами добавлена опция для ограничения максимального размера пароля 64 символами;

В качестве альтернативы инструкции CPU RDRAND добавлена поддержка библиотеки Jitterentropy, использующей для аппаратной генерации псевдослучайных чисел джиттер (jitter), основанный на учёте отклонения времени повторного исполнения определённого набора инструкций на CPU (CPU execution time jitter), которое зависит от множества внутренних факторов и непредсказуемо без физического контроля над CPU;

Проведена оптимизация производительности режима XTS на 64-разрядных системах с поддержкой инструкций SSE2. Оптимизации в среднем позволили поднять производительность на 10%;

Добавлен код для определения наличия в CPU поддержки инструкций RDRAND/RDSEED и процессоров Hygon. Решены проблемы с определением поддержки AVX2/BMI2;

Для Linux в CLI добавлена опция "--import-token-keyfiles", совместимая с неинтерактивным режимом;

Для Linux и macOS добавлена проверка наличия свободного места в ФС для размещения создаваемого файлового контейнера. Для отключения проверки предусмотрен флаг "--no-size-check";

Для Windows реализован режим хранения ключей и паролей в памяти в зашифрованном виде, используя шифр ChaCha12, хэш t1ha и CSPRNG на основе ChaCha20. По умолчанию данный режим отключён, так как приводит к увеличению накладных расходов приблизительно на 10% и не позволяет переводить систему в спящий режим. Для Windows также добавлена защита от некоторых атак по извлечению данных из памяти, основанная на реализованном в KeePassXC методе ограничения доступа к памяти пользователей, не имеющих полномочий администратора. Добавлена очистка ключей перед завершением работы, перед перезагрузкой или (опционально) при подключении нового устройства. Внесены улучшения в загрузчик UEFI. Добавлена поддержка использования инструкций CPU RDRAND и RDSEED как дополнительного источника энтропии. Добавлен режим монтирования без присвоения разделу буквы.