Релиз системы виртуализации VirtualBox 6.1

После года разработки компания Oracle опубликовала релиз системы виртуализации VirtualBox 6.1. Готовые установочные пакеты доступны для Linux (Ubuntu, Fedora, openSUSE, Debian, SLES, RHEL в сборках для архитектуры AMD64), Solaris, macOS и Windows.

Основные изменения:

  • Добавлена поддержка аппаратных механизмов, предложенных в пятом поколении процессоров Intel Core i (Broadwell), для организации вложенного запуска виртуальных машин;
  • Удалён старый метод поддержки 3D-графики, основанный на драйвере VBoxVGA. Для 3D рекомендовано использовать новые драйверы VBoxSVGA и VMSVGA;
  • В драйверах VBoxSVGA и VMSVGA добавлена поддержка YUV2 и использующих данную цветовую модель форматов текстур, при использовании OpenGL на стороне хоста (в macOS и Linux), что позволяет при включении 3D обеспечить ускорение отображения видео за счёт выноса операций преобразования цветовых пространств на сторону GPU. Решены проблемы со сжатыми текстурами в OpenGL при использовании 3D режима в драйвере VMSVGA;
  • Добавлена программная экранная клавиатура с поддержкой мультимедийных клавиш, которую можно использовать как клавиатуру в гостевых ОС;
  • Добавлен модуль vboximg-mount с экспериментальной поддержкой прямого доступа к ФС NTFS, FAT и ext2/3/4 внутри дискового образа, реализованный на стороне гостевой системы и не требующий поддержки данной ФС на стороне хоста. Работа пока возможна в режиме только для чтения;
  • Добавлена экспериментальная поддержка virtio-scsi, как для жёстких дисков, так и для оптических накопителей, в том числе с возможностью загрузки с устройства на базе virtio-scsi;
  • Добавлена опция для экспорта виртуальных машин в облачные окружения, использующие механизм паравиртуализации;
  • Прекращена поддержка рекомпилятора, для запуска виртуальных машин теперь обязательно требуется поддержка аппаратной виртуализации в CPU;

  • В графическом интерфейсе улучшено создание образов виртуальных машин (VISO) и расширены возможности встроенного файлового менеджера;
  • В панель с информацией о виртуальной машине добавлен встроенный редактор атрибутов VM, позволяющий изменить некоторые настройки не открывая конфигуратор;
  • Повышено удобство настройки параметров хранилища для VM, предоставлены поддержка смены типа шины контроллера и возможность перемещения прикреплённых элементов между контроллерами при помощи интерфейса drag&drop;
  • Расширен и улучшен диалог с информацией о сеансе;
  • Оптимизирован диалог выбора носителя, который показывает как список известных образов, так и позволяет выбрать произвольный файл;
  • Проведена оптимизация интерфейса для настройки хранилищ и сетевой подсистемы;
  • В строку состояния добавлен индикатор нагрузки на CPU в виртуальной машине;
  • Оптимизирован код перебора носителей, который стал работать быстрее и меньше нагружать CPU в ситуациях наличия большого числа зарегистрированных носителей. В Virtual Media Manager возвращена функция добавления существующего или нового носителя;
  • В VirtualBox Manager улучшено отображение списка виртуальных машин, более заметно выделены группы виртуальных машин, улучшен поиск VM и обеспечено закрепление области инструментов для фиксации позиции при прокрутке списка VM;

  • Появилась поддержка импорта виртуальных машин из Oracle Cloud Infrastructure. Расширены функции экспорта виртуальных машин в Oracle Cloud Infrastructure, в том числе появилась возможность создания нескольких виртуальных машин без их повторной загрузки. Добавлена возможность привязки произвольных тегов к облачным образам;
  • В системе ввода добавлена поддержка горизонтальной прокрутки мышью, используя протокол IntelliMouse Explorer;
  • Runtime адаптирован для работы на хостах с большим числом CPU (не больше 1024);
  • Добавлена возможность смены работающего на стороне хоста звукового бэкенда при нахождении VM в сохранённом состоянии;
  • В VBoxManager добавлена поддержка перемещения нескольких исходных файлов/каталогов гостевой системы в целевой каталог;
  • Добавлена поддержка ядра Linux 5.4. При сборке ядра отключено формирование цифровых подписей для модулей (подписи могут быть добавлены пользователем после завершения сборки). Удалена функция проброса PCI-устройств в Linux, так как текущий код не доделан и не пригоден для применения;
  • Реализация EFI переведена на более новый код прошивки, добавлена поддержка NVRAM. Добавлена поддержка загрузки с APFS и возможность использования нестандартных путей к загрузочным устройствам с интерфейсами SATA и NVMe, созданным в macOS;
  • Добавлен новый тип сетевого адаптера PCnet-ISA (доступен пока только из CLI);
  • Улучшена реализация контроллера USB EHCI. Добавлена возможность фильтрации USB-устройств по порту подключения.

Источник: [ссылка]

Релиз Chrome 79

Компания Google представила релиз web-браузера Chrome 79. Одновременно доступен стабильный выпуск свободного проекта Chromium, выступающего основой Chrome. Браузер Chrome отличается использованием логотипов Google, наличием системы отправки уведомлений в случае краха, возможностью загрузки модуля Flash по запросу, модулями для воспроизведения защищённого видеоконтента (DRM), системой автоматической установки обновлений и передачей при поиске RLZ-параметров. Следующий выпуск Chrome 80 запланирован на 4 февраля.

Основные изменения в Chrome 79:

  • Активирован компонент Password Checkup, предназначенный для анализа надёжности используемых пользователем паролей. При попытке входа на любой сайт Password Checkup выполняет проверку логина и пароля по базе скомпрометированных учётных записей с выводом предупреждения в случае выявления проблем (проверка осуществляется на основе хэш-префикса на стороне пользователя). Проверка осуществляется по базе, охватывающей более 4 миллиардов скомпрометированных аккаунтов, фигурировавших в утечках пользовательских баз. Предупреждение также выводится при попытке использования тривиальных паролей, таких как «abc123». Для управления включением Password Checkup в секции «Sync and Google Services» реализована специальная настройка.
  • Представлена новая технология выявления фишинга в режиме реального времени. Раньше проверка выполнялась через обращение к локально загружаемым чёрным спискам Safe Browsing, которые обновлялись примерно раз в 30 минут, чего оказалось недостаточно, например, в условиях частого переключения доменов злоумышленниками. Новый метод позволяет проверять URL на лету с предварительной проверкой по белым спискам, в которые включены хэши тысяч популярных сайтов, заслуживающих доверия. Если открываемый сайт отсутствует в белом списке, то браузер проверяет URL на сервере Google, передавая первые 32 бита хэша SHA-256 ссылки, из которой вырезаются возможные персональные данные. По оценке Google новый подход позволяет на 30% повысить эффективность вывода предупреждений для новых фишинг-сайтов.
  • Добавлена упреждающая защита от передачи учётных данных Google и любых паролей, сохранённых менеджере паролей, через фишинговые страницы. При попытке ввода сохранённого пароля на сайте, на котором этот пароль обычно не применяется, пользователю будет выводиться предупреждение о потенциально опасном действии.
  • Для соединений с использованием TLS 1.0 и 1.1 теперь показывается индикатор небезопасного соединения. Полностью поддержка TLS 1.0 и 1.1 будет отключена в Chrome 81, намеченном на 17 марта 2020 года.
  • Добавлена возможность заморозки неактивных вкладок, позволяющая автоматически выгрузить из памяти вкладки, которые находятся в фоновом состоянии более 5 минут и не выполняют имеющих значение действий. Решение о пригодности той или иной вкладки для заморозки принимаются на основе эвристики. Управление включением функции производится через флаг «chrome://flags/#proactive-tab-freeze».
  • Обеспечена блокировка смешанного контента на страницах, открытых по HTTPS, для того, чтобы гарантировать, что страницы, открытые по https:// содержат только ресурсы, загруженные по защищённому каналу связи. Несмотря на то, что наиболее опасные виды смешанного контента, такие как скрипты и iframe, уже блокируются по умолчанию, изображения, звуковые файлы и видео до сих пор могли быть загружены по http://. Ранее применявшийся индикатор смешанного контента для таких вставок признан неэффективным и вводящим пользователя в заблуждение, так как он не даёт однозначной оценки безопасности страницы. Например, через подмену изображений атакующий может подставить отслеживающие действия пользователя Cookie, попытаться эксплуатировать уязвимости в обработчиках изображений или совершить подлог, заменив представленную на изображении информацию. Для отключения блокировки смешанных компонентов добавлена специальная настройка, вызываемая через меню, выпадающее при клике на символ замка.
  • Добавлена экспериментальная возможность совместного доступа к содержимому буфера обмена между настольной и мобильной версиями Chrome. В связанных одной учётной записью экземплярах Chrome теперь можно получить доступ к содержимому буфера обмена другого устройства, в том числе возможен совместный доступ к буферу обмена между мобильной и настольной системой. Содержимое буфера обмена шифруется с применением сквозного (end-to-end) шифрования, не позволяющего получить доступ к тексту на серверах Google. Функция включается через опции chrome://flags#shared-clipboard-receiver, chrome://flags#shared-clipboard-ui и chrome://flags#sync-clipboard-service.
  • В адресной строке в определённые моменты (например, при сохранении пароля) при выключенной синхронизации профиля помимо аватара обеспечено отображение имени текущей учётной записи в Google, чтобы пользователь мог точно идентифицировать текущую активную учётную запись.
  • Для 1% пользователей активирована поддержка «DNS поверх HTTPS» (DoH, DNS over HTTPS). В эксперименте участвуют только пользователи, в системных настройках которых уже указаны DNS-провайдеры, поддерживающие DoH. Например, если у пользователя в системных настройках указан DNS 8.8.8.8, то в Chrome будет активирован DoH-сервис Google («https://dns.google.com/dns-query»), если DNS — 1.1.1.1, то DoH сервис Cloudflare («https://cloudflare-dns.com/dns-query») и т.п. Для управления включением DoH предусмотрена настройка «chrome://flags/#dns-over-https». Поддерживается три режима работы «secure», «automatic» и «off». В режиме «secure» хосты определяются только на основе ранее прокешированных безопасных значений (полученных через защищённое соединение) и запросов через DoH, откат на обычный DNS не применяется. В режиме «automatic» если DoH и защищённый кэш недоступны допускается получение данных из небезопасного кэша и обращение через традиционный DNS. В режиме «off» вначале проверяется общий кэш и если данных нет, запрос отправляется через системный DNS.
  • Добавлена экспериментальная поддержка кэширования отрисованного содержимого при смене страниц кнопками вперёд и назад, позволяющая существенно снизить задержки при подобном виде навигации за счёт полного кэширования всей страницы, не требующего повторной отрисовки и загрузки ресурсов. Оптимизация особенно заметна в версии для мобильных устройств, на которой прирост производительности при навигации достигает 19%. Режим включается при помощи опции «chrome://flags#back-forward-cache».
  • Удалена настройка «chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains», позволявшая вернуть показ протокола в адресной строке (теперь все ссылки всегда показываются без https:// и http://, а также без «www.»).
  • В сборках для Windows включена sandbox-изоляция сервиса воспроизведения звука. Для управления включением изоляции предложено свойство AudioSandboxEnabled.
  • В средства централизованного администрирования для предприятий реализована возможность определения правил, задающих размер памяти, который экземпляр браузера может потребить до того, как начнут выгружаться фоновые вкладки. Высвобождаемая после выгрузки вкладки память становится доступна для использования, а содержимое вкладки вновь загружается при переключении на неё.
  • В Linux задействован встроенный обработчик верификации сертификатов, который пришёл на смену ранее применяемой системы NSS. При этом встроенный обработчик продолжает использовать хранилище NSS при проверке, но предъявляет более жёсткие требования при обработке некорректно закодированных и обособленно заверенных сертификатов (все сертификаты обязательно должны заверяться удостоверяющим центром).
  • В версии для платформы Android добавлена возможность назначения адаптивных пиктограмм для устанавливаемых web-приложений, работающих в режиме Progressive Web Apps (PWA). Адаптивные пиктограммы могут подстраиваться под интерфейс, применяемый производителем устройства, например, быть круглыми, квадратными или со сглаженными углами.

  • Добавлен API WebXR Device, предоставляющий доступ к компонентам для создания виртуальной и дополненной реальности. API позволяет унифицировать работу с различными классами устройств, от стационарных шлемов виртуальной реальности, подобных Oculus Rift, HTC Vive и Windows Mixed Reality, до решений на базе мобильных устройств, таких как Google Daydream View и Samsung Gear VR. Из приложений, в которых может быть применим новый API упоминаются программы для просмотра видео в режиме 360°, системы визуализации трёхмерного пространства, создание виртуальных кинотеатров для презентации видео, проведение экспериментов по созданию 3D-интерфейсов магазинов и галерей;
  • В режиме Origin Trials (экспериментальные возможности, требующие отдельной активации) предложено несколько новых API. Origin Trial подразумевает возможность работы с указанным API из приложений, загруженных с localhost или 127.0.0.1, или после прохождения регистрации и получения специального токена, который действует ограниченное время для конкретного сайта.
    • Для всех элементов HTML предложен атрибут «rendersubtree», обеспечивающий фиксацию отображения DOM-элемента. При присвоении атрибуту значения «invisible» содержимое элемента не будет отрисовываться и проверяться, что позволяет оптимизировать рендеринг. При установке значения «activatable» браузер удалит невидимый атрибут, отрисует содержимое и сделает его видимым.
    • Добавлен вариант API Wake Lock на основе механизма Promise, предоставляющий более безопасный способ управления отключением автоблокировки экрана и перевода устройств в энергосберегающие режимы.
  • Реализована возможность применения атрибута autofocus для всех элементов HTML и SVG, на которые может быть быть установлен фокус ввода.
  • Для изображений и видео обеспечено вычисление коэффициента соотношения сторон на основе атрибутов Width или Height, что может использоваться для определения размера изображения при помощи CSS, на стадии когда изображение ещё не загружено (решает проблему с перестроением страницы после загрузки изображений).
  • Добавлено CSS-свойство font-optical-sizing, которое автоматически выставляет размер изменчивого шрифта (variable font) в оптических координатах «opsz«, если шрифт их поддерживает. Режим позволяет выбрать оптимальную форму глифа для указанного размера, например, использовать более контрастные глифы для заголовков.
  • Добавлено CSS-свойство list-style-type, позволяющее использовать любые символы вместо точек в списках, например, «-«, «+», «★» и «▸».
  • При невозможности выполнить Worklet.addModule() теперь возвращается объект с детальной информацией о характере ошибки, который позволяет более точно оценить причину ошибки (проблемы с сетевым соединением, некорректный синтаксис и т.п.).
  • Прекращена обработка элементов ‹script› при их перемещении между документами. При переносе между документами также отключено выполнение связанных со скриптом событий «error» и «load».

  • В JavaScript-движке V8 проведена оптимизация обработки изменения представления полей в объектах, в результате которой выполнение кода AngularJS в тестовом наборе Speedometer стало выполняться на 4% быстрее.
  • В V8 также проведена оптимизация обработки геттеров, определённых во встроенных API, таких как Node.nodeType и Node.nodeName, в условиях отсутствия обработчика IC (inline caching). Изменение примерно на 12% сократило затраты времени на IC runtime при выполнении тестов Backbone и jQuery из набора Speedometer.
  • Обеспечено кэширование результатов работы механизма OSR (called on-stack replacement), который осуществляет подстановку оптимизированного кода в процессе выполнения функции (позволяет начать использовать оптимизированный код для длительно выполняемых функций, не дожидаясь их повторного запуска). Кэширование OSR даёт возможность использовать результаты оптимизации и при повторном запуске функции, без необходимости прохождения повторной оптимизации. В некоторых тестах изменение позволило поднять пиковую производительность на 5–18%.
  • Изменения в инструментах для web-разработчиков:
      Появился отладочный режим для определения причин блокировки запроса или отдачи Cookie.
    • В блоке со списком Cookie добавлена возможность быстрого просмотра значения выбранной Cookie через клик на определённой строке.
    • Добавлена возможность симуляции разных настроек для media-запросов prefers-color-scheme и prefers-reduced-motion (например, для проверки поведения страницы при тёмной системной теме оформления или при отключенных анимированных эффектах).
    • Модернизировано оформление вкладки Coverage, позволяющей оценить используемый и не используемый код. Добавлена возможность фильтрации информации по её типу (JavaScript, CSS). Информация об использовании кода также добавлена при отображении исходного текста.
    • Добавлена возможность отладки причин запроса того или иного сетевого ресурса после записи сетевой активности (можно просмотреть трассировку вызова JavaScript-кода, приведшего к загрузке ресурса).
    • Добавлена настройка «Settings > Preferences > Sources > Default Indentation» для определения вида отступа (2/4/8 пробелов или табуляция) в коде, выводимом в панелях Console и Sources.

Кроме нововведений и исправления ошибок в новой версии устранена 51 уязвимость. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Две проблемы (CVE-2019-13725, обращение к уже освобождённой области памяти в коде для поддержки Bluetooth, и CVE-2019-13726, переполнение кучи в менеджере паролей) помечены как критические, т.е. позволяют обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения. Сразу две критические проблемы в рамках одного цикла разработки в Chrome выявлены впервые. Первая уязвимость была найдена исследователями из компании Tencent Keen Security Lab и продемонстрирована на соревновании Tianfu Cup, а вторую нашёл Сергей Глазунов из Google Project Zero.

В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google выплатила 37 премий на сумму 80000 долларов США (одна премия $20000, одна премия $10000, две премии $7500, четыре премии $5000, одна премия $3000, две премии $2000, две премии $1000 и восемь премий $500). Размер 15 вознаграждений пока не определён.

Источник: [ссылка]

Уязвимость в ld.so OpenBSD

Динамический загрузчик ld.so, входящий в состав OpenBSD, при определённых условиях может для SUID/SGID-приложения оставить переменную окружения LD_LIBRARY_PATH и таким образом позволить загрузить сторонний код в контексте процесса, выполняемого с повышенными привилегиями. Патчи с исправлением уязвимости доступны для релизов 6.5 и 6.6. Бинарные патчи (syspatch) для платформ amd64, i386 и arm64 уже запущены в производство и должны быть доступны для загрузки к моменту публикации данной новости.

Суть проблемы: в ходе работы ld.so сначала извлекает из окружения значение переменной LD_LIBRARY_PATH, с помощью функции _dl_split_path() превращает его в массив строк — путей к каталогам. Если позднее выясняется, что текущий процесс запущен SUID/SGID-приложением, то созданный массив и собственно переменная LD_LIBRARY_PATH очищаются. При этом, если в ходе работы _dl_split_path() столкнётся с нехваткой памяти (что трудно из-за наличия явного ограничения на размер переменных окружения в 256 кБайт, но теоретически возможно), то переменная _dl_libpath получит значение NULL и последующая проверка значения этой переменной заставит пропустить вызов _dl_unsetenv(«LD_LIBRARY_PATH»).

Уязвимость найдена специалистами Qualys, так же как и несколько ранее раскрытых проблем. Выявившие уязвимость исследователи безопасности отметили оперативность решения проблемы: патч был подготовлен и обновления выпущены в течение трёх часов после получения уведомления проектом OpenBSD.

Дополнение: Проблеме присвоен номер CVE-2019-19726. В списке рассылки oss-security сделан официальный анонс, включающий прототип эксплоита, работающий в OpenBSD 6.6, 6.5, 6.2 и 6.1 на архитектурах amd64 и i386 (эксплоит может быть адаптирован и для других архитектур). Проблема эксплуатируема в установке по умолчанию и позволяет непривилегированному локальному пользователю выполнить код с правами root через подстановку библиотеки при запуске suid-утилит chpass или passwd. Для создания необходимых для эксплуатации условий нехватки памяти используется установка ограничения RLIMIT_DATA через setrlimit.

Источник: [ссылка]

Plundervolt — новый метод атаки на процессоры Intel, затрагивающий технологию SGX

Компания Intel выпустила обновление микрокода, устраняющего уязвимость (CVE-2019-14607), позволяющую через манипуляции с механизмом динамического управления напряжением и частотой в CPU инициировать повреждение содержимого ячеек с данными, в том числе в областях, используемых при вычислениях в изолированных анклавах Intel SGX. Атака получила название Plundervolt и потенциально позволяет локальному пользователю добиться повышения своих привилегий в системе, вызвать отказ в обслуживании и получить доступ к закрытым данным.

Атака представляет опасность только в контексте манипуляций с вычислениями в анклавах SGX, так как для проведения требует наличия прав root в системе. В простейшем случае, атакующий может добиться внесения искажений в информацию, обрабатываемую в анклаве, но при более сложных сценариях не исключается возможность воссоздания хранимых в анклаве закрытых ключей, используемых для шифрования с использованием алгоритмов RSA-CRT и AES-NI. Техника также может применяться для генерации ошибок в изначально корректных алгоритмах для провоцирования возникновения уязвимостей при работе с памятью, например, для организации обращения к области за границей выделенного буфера. Прототип кода для совершения атаки опубликован на GitHub

Суть метода в создании условий для возникновения непредвиденных искажений данных при вычислениях в SGX, от которых не защищает применение шифрования и аутентификации памяти в анклаве. Для внесения искажений оказалось можно использовать штатные программные интерфейсы для управления частотой и напряжением, обычно применяемые для снижения энергопотребления во время простоя системы и активации максимальной производительности при выполнении интенсивных работ. Характеристики частоты и напряжения охватывают весь чип, в том числе влияют на выполнение вычислений в изолированном анклаве.

Изменяя напряжение можно добиться возникновения условий при которых заряда оказывается недостаточно для регенерации ячейки памяти внутри CPU и её значение меняется. Ключевым отличием от атаки RowHammer является то, что RowHammer позволяет изменить содержимое отдельных битов в памяти DRAM, путём цикличного чтения данных из соседних ячеек, в то время как Plundervolt позволяет добиться изменения битов внутри CPU, когда данные уже загружены из памяти для выполнения вычислений. Подобная особенность позволяет обойти применяемые в SGX механизмы контроля целостности и шифрования данных в памяти, так как значения в памяти остаются корректными, но могут исказиться при операциях с ними, до того как результат будет записан в память.

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

Проанализировав накопленные при разных сбоях пары значений корректного и искажённого шифротекстов, при помощи методов дифференциального анализа сбоев (DFA, Differential Fault Analysis) можно предугадать вероятные ключи, применяемые для симметричного шифрования AES, а затем проанализировав пересечения ключей в разных наборах определить искомый ключ.

Проблеме подвержены различные модели процессоров Intel, включая CPU Intel Core с 6 по 10 поколение, а также пятое и шестое поколения Xeon E3, первое и второе поколения Intel Xeon Scalable, Xeon D, Xeon W и Xeon E.

Напомним, что технология SGX (Software Guard Extensions) появилась в процессорах Intel Core шестого поколения (Skylake) и предлагает серию инструкций, позволяющих выделять приложениям пользовательского уровня закрытые области памяти — анклавы, содержимое которых не может быть прочитано и изменено даже ядром и кодом, выполняемым в режимах ring0, SMM и VMM. Передать управление коду в анклаве невозможно традиционными функциями перехода и манипуляциями с регистрами и стеком — для передачи управления в анклав применяется специально созданная новая инструкция, выполняющая проверку полномочий. При этом помещённый в анклав код может применять классические методы вызова для обращения к функциям внутри анклава и специальную инструкцию для вызова внешних функций. Для защиты от аппаратных атак, таких как подключение к модулю DRAM, применяется шифрование памяти анклава.

Источник: [ссылка]

Обновление Git с устранением 8 уязвимостей

Опубликованы корректирующие выпуски распределённой системы управления исходными текстами Git 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 и 2.14.62.24.1, в которых устранены уязвимости, позволяющие атакующему переписать произвольные пути в файловой системе, организовать удалённый запуск кода или перезаписать файлы в каталоге «.git/». Большинство проблем выявлены сотрудниками Microsoft Security Response Center, пять из восьми уязвимостей специфичны для платформы Windows.

  • CVE-2019-1348 — потоковая команда «feature export-marks=path»позволяет записать метки в произвольные каталоги, что может использоваться для перезаписи произвольных путей в ФС при выполнении операции «git fast-import» с непроверенными входными данными.
  • CVE-2019-1350 — некорректное экранирование аргументов командной строки могло привести к удалённому выполнению кода атакующего при рекурсивном клонировании с использованием URL ssh://. В частности, некорректно обрабатывалось экранирование аргументов, оканчивающихся на обратный слеш (например, «test «). В этом случае при обрамлении аргумента двойными кавычками, последняя кавычка оказывалась экранированной, что позволяло организовать подстановку своих опций в командной строке.
  • CVE-2019-1349 — при рекурсивном клонировании субмодулей («clone —recurse-submodules») в окружении Windows при определённых условиях можно было инициировать использование одного git-каталога дважды (.git, git~1, git~2 и git~N в NTFS распознаётся как один каталог, но эта ситуация проверялась только для git~1), что могло применяться для организации записи в каталог «.git». Для организации выполнения своего кода атакующий, например, может подставить свой скрипт через обработчик post-checkout в файле .git/config.
  • CVE-2019-1351 — обработчик буквенных имён дисков в путях Windows при трансляции путей типа «C:» был рассчитан только на замену однобуквенных латинских идентификаторов, но не учитывал возможность создания виртуальных дисков, назначаемых через «subst буква:путь». Такие пути обрабатывались не как абсолютные, а как относительные пути, что позволяло при клонировании вредоносного репозитория организовать запись в произвольный каталог за пределами рабочего дерева каталогов (например, при использовании цифр или unicode-символов в названии диска — «1:whatthehex.txt» или «ä:tschibät.sch»).
  • CVE-2019-1352 — при работе на платформе Windows применение альтернативных потоков данных в NTFS, создаваемых через добавление признака «:stream-name:stream-type» к имени файла, позволяло перезаписать файлы в каталоге «.git/» при клонировании вредоносного репозитория. Например, имя «.git::$INDEX_ALLOCATION» в NTFS обрабатывалось как корректная ссылка на каталог «.git».
  • CVE-2019-1353 — при использовании Git в окружении WSL (Windows Subsystem for Linux) при обращении к рабочему каталогу не применялась защита от манипуляции именами в NTFS (были возможны атаки через трансляцию имён FAT, например, к «.git» можно было обратиться через каталог «git~1»).
  • CVE-2019-1354возможность записи в каталог «.git/» на платформе Windows при клонировании вредоносных репозиториев, содержащих файлы с обратным слешем в имени (например, «ab»), который допустим в Unix/Linux, но воспринимается как часть пути в Windows.
  • CVE-2019-1387 — недостаточная проверка имён субмодулей могла использоваться для организации целевых атак, которые при рекурсивном клонировании потенциально могли привести к выполнению кода атакующего. Git не запрещал создавать каталог субмодуля в каталоге другого субмодуля, что в большинстве случаях лишь может привести к замешательству, но потенциально не исключает перезаписи содержимого другого модуля в процессе рекурсивного клонирования (например, каталоги субмодулей «hippo» и «hippo/hooks» размещаются как «.git/modules/hippo/» и «.git/modules/hippo/hooks/», а каталог hooks в hippo может отдельно использоваться для размещения запускаемых обработчиков.

Пользователям Windows рекомендуется срочно обновить версию Git, а до обновления воздержаться от клонирования непроверенных репозиториев. Если возможности срочно обновить версию Git пока нет, то для снижения риска атаки рекомендуется не запускать «git clone —recurse-submodules» и «git submodule update» с непроверенными репозиториями, не использовать «git fast-import» с непроверенными входными потоками и не клонировать репозитории в разделы на базе NTFS.

Для дополнительной защиты в новых выпусках также запрещено использование в .gitmodules конструкций в форме «submodule.{name}.update=!command». Для дистрибутивов проследить за выпуском обновлений пакетов можно на страницах Debian,Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD.

Источник: [ссылка]

Выпуск новой стабильной ветки Tor 0.4.2

Представлен выпуск инструментария Tor 0.4.2.5, используемого для организации работы анонимной сети Tor. Tor 0.4.2.5 признан первым стабильным выпуском ветки 0.4.2, которая развивалась последние четыре месяца. Одновременно предложены обновления для старых веток 0.4.1.7, 0.4.0.6 и 0.3.5.9. Ветка 0.4.2 будет сопровождаться в рамках штатного цикла сопровождения — выпуск обновлений будет прекращён через 9 месяцев или через 3 месяца после релиза ветки 0.4.3.x. Длительный цикл поддержки (LTS) обеспечен для ветки 0.3.5, обновления для которой будут выпускаться до 1 февраля 2022 года. Поддержка веток 0.4.0.x и 0.2.9.x будет прекращена в начале следующего года.

Основные новшества:

  • На серверах каталогов включена блокировка подключения узлов, на которых используются устаревшие выпуски Tor, поддержка которых прекращена (будут заблокированы все узлы, на которых не используются актуальные ветки 0.2.9, 0.3.5, 0.4.0, 0.4.1 и 0.4.2). Блокировка позволит по мере прекращения поддержки очередных веток автоматически исключать из сети узлы, вовремя не перешедшие на актуальное программное обеспечение.

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

  • Для скрытых сервисов предоставлены средства для защиты от DoS-атак. Точки выбора соединения (intro points) теперь могут ограничивать интенсивность запросов от клиента, используя параметры, отправленные скрытым сервисом в ячейке ESTABLISH_INTRO. Если новое расширение не используется скрытым сервисом, то точка выбора соединения будет руководствоваться параметрами достижения консенсуса.
  • В точках выбора соединения запрещено подключение клиентов прямого проброса (single-hop), которые использовались для работы сервиса Tor2web, поддержка которого давно прекращена. Блокировка позволит снизить нагрузку на сеть от клиентов-спамеров.
  • Для скрытых сервисов реализован общий набор токенов (generic token bucket), использующий единый счётчик, который может применяться для борьбы с DoS-атаками.
  • Режим «BEST» в команде ADD_ONION теперь по умолчанию применяет сервисы ED25519-V3 (v3) вместо RSA1024 (v2).
  • В код настройки добавлена возможность разделения данных конфигурации между несколькими объектами.
  • Проведена значительная чистка кода.

Источник: [ссылка]

Доступен браузер Firefox Preview 3.0 для Android

Компания Mozilla опубликовала третий значительный выпуск экспериментального браузера Firefox Preview, развиваемого под кодовым именем Fenix. В ближайшее время выпуск будет опубликован в каталоге Google Play (для работы необходим Android 5 или новее). Код доступен на GitHub. Первый стабильный выпуск ожидается в первой половине 2020 года. После стабилизации проекта и реализации всей задуманной функциональности браузер заменит собой редакцию Firefox для Android, выпуск новых релизов которой прекращён начиная с Firefox 69.

Firefox Preview использует движок GeckoView, построенный на базе технологий Firefox Quantum, и набор библиотек Mozilla Android Components, которые уже применяются для построения браузеров Firefox Focus и Firefox Lite. GeckoView является вариантом движка Gecko, оформленном в виде отдельной библиотеки, которую можно обновлять независимо, а Android Components включает библиотеки с типовыми компонентами, обеспечивающими работу вкладок, автодополнения ввода, поисковых подсказок и других возможностей браузера.

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

  • Добавлены расширенные средства для защиты от отслеживания перемещений, позволяющие по аналогией с настольной версией Firefox блокировать рекламу с кодом для отслеживания перемещений, счётчики web-аналитики, виджеты социальных сетей, скрытые методы идентификации пользователя и код для майнинга криптовалют. По умолчанию активен режим жёсткой блокировки (Strict). По оценке разработчиков включение блокировки приводит к ускорению загрузки страниц в среднем на 20%. При касании к пиктограмме с изображением щита отрывается окно с информацией о заблокированных элементах c возможностью детального просмотра списка блокировки для текущего сайта.
  • По умолчанию активирована опция для открытия внешних ссылок (переходы по ссылке из сторонних приложений) в приватном режиме.
  • Добавлена опция для автоматической очистки истории открытия страниц при выходе из браузера.
  • Добавлена возможность выбора типов информации, которая будет синхронизироваться между устройствами. Из информации для синхронизации пока предложены только закладки и история открытия страниц.
  • Добавлены настройки поведения автоматического и фонового воспроизведения видео и звука.
  • Реализован интерфейс для просмотра и управления загрузками. Состояние загрузки отображается через виджет в области уведомлений, через который также можно приостановить, продолжить или отменить загрузку. После завершения загрузки всплывает диалог, через который можно открыть загруженный файл.
  • Вместо панели Quick Action предложена новая реализация браузерного меню.
  • Добавлена возможность добавления новых движков для обращения к поисковым системам.
  • Предложена опция для перемещения навигационной панели в нижнюю часть экрана.
  • Добавлена настройка для установки глобального уровня масштабирования, применяемого для всех сайтов.

Основные особенности Firefox Preview:

  • Высокая производительность. Заявлено, что Firefox Preview до двух раз быстрее классического Firefox для Android, что достигается благодаря применению на этапе компиляции оптимизаций на основе результатов профилирования кода (PGO — Profile-guided optimization) и за счёт включения JIT-компилятора IonMonkey для 64-разрядных систем ARM. Кроме ARM сборки GeckoView также теперь формируются и для систем x86_64.
  • Включение по умолчанию защиты от отслеживания перемещений и различной паразитной активности.
  • Универсальное меню, через которое можно получить доступ к настройкам, библиотеке (избранные страницы, история, загрузки, недавно закрытые вкладки), выбору режима отображения сайта (показ десктоп-версии сайта), поиску текста на странице, переходу в приватный режим, открытию новой вкладки и навигации между страницами.
  • Многофункциональная адресная строка, в которой имеется универсальная кнопка для быстрого выполнения операций, таких как отправка ссылки на другое устройство и добавление сайта в список избранных страниц. При нажатии на адресной строке запускается полноэкранный режим подсказки, предлагающий релевантные варианты ввода на основе истории посещений и рекомендаций от поисковых систем.
  • Применение вместо вкладок концепции коллекций, позволяющих сохранять, группировать и обмениваться избранными сайтами. После закрытия браузера остающиеся открытыми вкладки автоматически группируются в коллекцию, которую затем можно просмотреть и восстановить.
  • На стартовой странице выводится адресная строка, совмещённая с функцией глобального поиска, и показывается список открытых вкладок или, если страницы не открыты, отображается список сеансов, в которых сгруппированы ранее открытые сайты в привязке к сеансам работы с браузером.
  • Присутствует функция отправки вкладки или коллекции на другое устройство.

Источник: [ссылка]

VPN WireGuard принят в ветку net-next и намечен для включения в ядро Linux 5.6

Дэвид Миллер (David S. Miller), отвечающий за сетевую подсистему ядра Linux, принял в состав ветки net-next патчи с реализацией VPN-интерфейса от проекта WireGuard. В начале следующего года изменения, накапливаемые в ветке net-next, лягут в основу выпуска ядра Linux 5.6.

Попытки продвижения кода WireGuard в основной состав ядра предпринимались последние несколько лет, но оставались без результата из-за привязки к собственным реализациям криптографических функций, которые применялись для повышения производительности. Вначале данные функции были предложены для ядра в качестве дополнительного низкоуровневого API Zinc, который со временем смог бы заменить штатный Crypto API.

После переговоров на конференции Kernel Recipes, создатели WireGuard в сентябре приняли компромиссное решение перевести свои патчи на использование имеющегося в ядре Crypto API, к которому у разработчиков WireGuard имеются претензии в области производительности и общей безопасности. API Zinc было решено продолжать развивать, но как отдельный проект.

В ноября разработчики ядра пошли на ответный компромисс и согласились перенести в основное ядро часть кода из Zinc. По сути некоторые компоненты Zinc будут перенесены в ядро, но не как отдельный API, а как часть подсистемы Crypto API. Например, в Crypto API уже включены подготовленные в WireGuard быстрые реализации алгоритмов ChaCha20 и Poly1305.

В связи с предстоящей поставкой WireGuard в основном составе ядра, основатель проекта объявил о реструктуризации репозитория. Для упрощения разработки на смену монолитному репозиторию «WireGuard.git», который был рассчитан на обособленное существование, придут три отдельных репозитория, лучше подходящие для организации работы с кодом в основном ядре:

  • wireguard-linux.git — полное дерево ядра с изменениями от проекта Wireguard, патчи из которого будут рецензироваться для включения в ядро и регулярно переноситься в ветки net/net-next.
  • wireguard-tools.git — репозиторий для запускаемых в пространстве пользователя утилит и скриптов, таких как wg и wg-quick. Репозиторий можно использовать для создания пакетов для дистрибутивами.
  • wireguard-linux-compat.git — репозиторий с вариантом модуля, поставляемым отдельной от ядра и включающим слой compat.h для обеспечения совместимости со старыми ядрами. Основная разработка будет вестись в репозитории wireguard-linux.git, но пока есть возможность и потребность у пользователей обособленный вариант патчей также будет поддерживаться в рабочем виде.

Напомним, что VPN WireGuard реализован на основе современных методов шифрования, обеспечивает очень высокую производительность, прост в использовании, лишён усложнений и хорошо зарекомендовал себя в ряде крупных внедрений, обрабатывающих большие объёмы трафика. Проект развивается с 2015 года, прошёл аудит и формальную верификацию применяемых методов шифрования. Поддержка WireGuard уже интегрирована в NetworkManager и systemd, а патчи для ядра входят в базовый состав дистрибутивов Debian Unstable, Mageia, Alpine, Arch, Gentoo, OpenWrt, NixOS, Subgraph и ALT.

В WireGuard применяется концепция маршрутизации по ключам шифрования, которая подразумевает привязку к каждому сетевому интерфейсу закрытого ключа и применение для связывания открытых ключей. Обмен открытыми ключами для установки соединения производится по аналогии с SSH. Для согласования ключей и соединения без запуска отдельного демона в пространстве пользователя применяется механизм Noise_IK из Noise Protocol Framework, похожий на поддержание authorized_keys в SSH. Передача данных осуществляется через инкапсуляцию в пакеты UDP. Поддерживается смена IP-адреса VPN-сервера (роуминг) без разрыва соединения и автоматической перенастройкой клиента.

Для шифрования используется потоковый шифр ChaCha20 и алгоритм аутентификации сообщений (MAC) Poly1305, разработанные Дэниелом Бернштейном (Daniel J. Bernstein), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 позиционируются как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. Для генерации совместного секретного ключа применяется протокол Диффи-Хеллмана на эллиптических кривых в реализации Curve25519, также предложенной Дэниелом Бернштейном. Для хэширования используются алгоритм BLAKE2s (RFC7693).

При тестировании производительности WireGuard продемонстрировал в 3.9 раза более высокую пропускную способность и в 3.8 раз более высокую отзывчивость, по сравнению с OpenVPN (256-bit AES c HMAC-SHA2-256). По сравнению с IPsec (256-bit ChaCha20+Poly1305 и AES-256-GCM-128) в WireGuard наблюдается небольшое опережение по производительности (13-18%) и снижение задержек (21-23%). Тесты выполнены при использовании развиваемых проектом быстрых реализаций алгоритмов шифрования — перевод на штатный Crypto API ядра возможно приведёт к ухудшению показателей.

Источник: [ссылка]

Новая версия почтового сервера Exim 4.93

После 10 месяцев разработки состоялся релиз почтового сервера Exim 4.93, в который внесены накопившиеся исправления и добавлены новые возможности. В соответствии с ноябрьским автоматизированным опросом около миллиона почтовых серверов, доля Exim составляет 56.90% (год назад 56.56%), Postfix используется на 34.98% (33.79%) почтовых серверов, Sendmail — 3.90% (5.59%), Microsoft Exchange — 0.51% (0.85%).

Основные изменения:

  • Поддержка внешних аутентификаторов (RFC 4422). При помощи команды «SASL EXTERNAL» клиент может информировать сервер об использовании для аутентификации учётных данных, переданных через внешние сервисы, такие как IP Security (RFC4301) и TLS;
  • Добавлена возможность использования формата JSON для lookup-проверок. Также добавлены варианты условных масок «forall» и «any», использующие JSON.
  • Добавлены переменные $tls_in_cipher_std и $tls_out_cipher_std, содержащие названия наборов шифров, соответствующие наименованию из RFC.
  • Добавлены новые флаги для управления отражением идентификатора сообщений в логе (задаются через настройку log_selector): «msg_id» (включён по умолчанию) с идентификатором сообщения и «msg_id_created» со сгенерированным для нового сообщения идентификатором.
  • В режим «verify=not_blind» добавлена поддержка опции «case_insensitive» для игнорирования регистра символов при проверке.
  • Добавлена экспериментальная опция EXPERIMENTAL_TLS_RESUME, обеспечивающая возможность возобновления ранее прерванного TLS-соединения.
  • Добавлена опция exim_version для переопределения строки с номером версии Exim, выводимой в различных местах и передаваемой через переменные $exim_version и $version_number.
  • Добавлены варианты оператора ${sha2_N:} для N=256, 384, 512.
  • Реализованы переменные «$r_…», устанавливаемые из опций маршрутизации и доступные для использования при принятии решений о маршрутизации и выборе транспорта.
  • В lookup-запросах SPF добавлены поддержка IPv6.
  • При выполнении проверок через DKIM добавлена возможность фильтрации по типам ключей и хэшей.
  • При использовании TLS 1.3 обеспечена поддержка расширения протокола OCSP (Online Certificate Status Protocol) для проверки статуса отзыва сертификата.
  • Добавлено событие «smtp:ehlo» для наблюдения за предоставленным удалённой стороной списком функциональных возможностей.
  • Добавлена опция командной строки для перемещения сообщений из одной именованной очереди в другую.
  • Добавлены переменные с версиями TLS для входящих и исходящих запросов — $tls_in_ver и $tls_out_ver.
  • При использовании OpenSSL добавлена функция записи файлов с ключами в формате NSS для декодирования перехваченных сетевых пакетов. Имя файла задаётся через переменную окружения SSLKEYLOGFILE. При сборке с GnuTLS аналогичная функциональность предоставляется средствами GnuTLS, но требует работы с правами root.

Источник: [ссылка]

Новая версия почтового сервера Exim 4.93

После 10 месяцев разработки состоялся релиз почтового сервера Exim 4.93, в который внесены накопившиеся исправления и добавлены новые возможности. В соответствии с ноябрьским автоматизированным опросом около миллиона почтовых серверов, доля Exim составляет 56.90% (год назад 56.56%), Postfix используется на 34.98% (33.79%) почтовых серверов, Sendmail — 3.90% (5.59%), Microsoft Exchange — 0.51% (0.85%).

Основные изменения:

  • Поддержка внешних аутентификаторов (RFC 4422). При помощи команды «SASL EXTERNAL» клиент может информировать сервер об использовании для аутентификации учётных данных, переданных через внешние сервисы, такие как IP Security (RFC4301) и TLS;
  • Добавлена возможность использования формата JSON для lookup-проверок. Также добавлены варианты условных масок «forall» и «any», использующие JSON.
  • Добавлены переменные $tls_in_cipher_std и $tls_out_cipher_std, содержащие названия наборов шифров, соответствующие наименованию из RFC.
  • Добавлены новые флаги для управления отражением идентификатора сообщений в логе (задаются через настройку log_selector): «msg_id» (включён по умолчанию) с идентификатором сообщения и «msg_id_created» со сгенерированным для нового сообщения идентификатором.
  • В режим «verify=not_blind» добавлена поддержка опции «case_insensitive» для игнорирования регистра символов при проверке.
  • Добавлена экспериментальная опция EXPERIMENTAL_TLS_RESUME, обеспечивающая возможность возобновления ранее прерванного TLS-соединения.
  • Добавлена опция exim_version для переопределения строки с номером версии Exim, выводимой в различных местах и передаваемой через переменные $exim_version и $version_number.
  • Добавлены варианты оператора ${sha2_N:} для N=256, 384, 512.
  • Реализованы переменные «$r_…», устанавливаемые из опций маршрутизации и доступные для использования при принятии решений о маршрутизации и выборе транспорта.
  • В lookup-запросах SPF добавлены поддержка IPv6.
  • При выполнении проверок через DKIM добавлена возможность фильтрации по типам ключей и хэшей.
  • При использовании TLS 1.3 обеспечена поддержка расширения протокола OCSP (Online Certificate Status Protocol) для проверки статуса отзыва сертификата.
  • Добавлено событие «smtp:ehlo» для наблюдения за предоставленным удалённой стороной списком функциональных возможностей.
  • Добавлена опция командной строки для перемещения сообщений из одной именованной очереди в другую.
  • Добавлены переменные с версиями TLS для входящих и исходящих запросов — $tls_in_ver и $tls_out_ver.
  • При использовании OpenSSL добавлена функция записи файлов с ключами в формате NSS для декодирования перехваченных сетевых пакетов. Имя файла задаётся через переменную окружения SSLKEYLOGFILE. При сборке с GnuTLS аналогичная функциональность предоставляется средствами GnuTLS, но требует работы с правами root.

Источник: [ссылка]

Компания Mozilla представила движок распознавания речи DeepSpeech 0.6

Представлен выпуск развиваемого компанией Mozilla движка распознавания речи DeepSpeech 0.6, который реализует одноимённую архитектуру распознавания речи, предложенную исследователями из компании Baidu. Реализация написана на языке Python с использованием платформы машинного обучения TensorFlow и распространяется под свободной лицензией MPL 2.0. Поддерживается работа в Linux, Android, macOS и Windows. Производительности достаточно для использования движка на платах LePotato, Raspberry Pi 3 и Raspberry Pi 4.

В наборе также предлагаются обученные модели, примеры звуковых файлов и инструментарий для распознавания из командной строки. Для встраивания функции распознавания речи в свои программы предложены готовые к применению модули для Python, NodeJS, C++ и .NET (сторонними разработчиками отдельно подготовлены модули для Rust и Go). Готовая модель поставляется только для английского языка, но для других языков по прилагаемой инструкции можно обучить систему самостоятельно, используя голосовые данные, собранные проектом Common Voice.

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

Обратной стороной подобного подхода является то, что для получения качественного распознавания и обучения нейронной сети движок DeepSpeech требует большого объёма разнородных данных, надиктованных в реальных условиях разными голосами и при наличии естественных шумов. Сбором подобных данных занимается созданный в Mozilla проект Common Voice, предоставляющий проверенный набор данных с 780 часами на английском языке, 325 на немецком, 173 на французском и 27 часами на русском.

Конечной целью проекта Common Voice является накопление 10 тысяч часов c записями различного произношения типовых фраз человеческой речи, что позволит достичь приемлемого уровня ошибок при распознавании. В текущем виде участниками проекта уже надиктовано в сумме 4.3 тысячи часов, из которых 3.5 тысячи прошли проверку. При обучении итоговой модели английского языка для DeepSpeech использовано 3816 часов речи, кроме Common Voice охватывающей данные от проектов LibriSpeech, Fisher и Switchboard, а также включающей около 1700 часов транскрибированных записей радиошоу.

При использовании предлагаемой для загрузки готовой модели английского языка уровень ошибок распознавания в DeepSpeech составляет 7.5% при оценке тестовым набором LibriSpeech. Для сравнения, уровень ошибок при распознавании человеком оценивается в 5.83%.

DeepSpeech состоит из двух подсистем — акустической модели и декодировщика. Акустическая модель использует методы глубинного машинного обучения для вычисления вероятности наличия определённых символов в подаваемом на вход звуке. Декодировщик применяет алгоритм лучевого поиска для преобразования данных о вероятности символов в текстовое представление.

Основные новшества DeepSpeech 0.6 (ветка 0.6 не совместима с прошлыми выпусками и требует обновления кода и моделей):

  • Предложен новый потоковый декодировщик, обеспечивающий более высокую отзывчивость и не зависящий от размера обрабатываемых звуковых данных. В итоге, в новой версии DeepSpeech удалось снизить задержку на распознавание до 260 мс, что на 73% быстрее, чем раньше, и позволяет применять DeepSpeech в решениях для распознавания речи на лету.
  • Внесены изменения в API и проведена работа по унификации имён функций. Добавлены функции для получения дополнительных метаданных о синхронизации, позволяющие не просто получать на выходе текстовое представление, но и отслеживать привязку отдельных символов и предложений к позиции в звуковом потоке.
  • В инструментарий для обучения модули добавлена поддержка использования библиотеки CuDNN для оптимизации работы с рекуррентными нейронными сетями (RNN), что позволило добиться существенного (примерно в два раза) увеличения производительности обучения модели, но потребовало внесения в код изменений, нарушающих совместимость с моделями, подготовленными ранее.
  • Минимальные требования к версии TensorFlow подняты с 1.13.1 до 1.14.0. Добавлена поддержка легковесной редакции TensorFlow Lite, при использовании которой размер пакета DeepSpeech уменьшен с 98 MB до 3.7 MB. Для использования на встраиваемых и мобильных устойствах с 188 MB до 47 MB также сокращён размер упакованного файла с моделью (для сжатия использован метод квантования после завершения обучения модели).
  • Языковая модель переведена на другой формат структур данных, позволяющий выполнять маппинг файлов в память при загрузке. Поддержка старого формата прекращена.
  • Изменён режим загрузки файла с языковой моделью, что позволило снизить потребление памяти и уменьшить задержки при обработке первого запроса после создания модели. В процессе работы DeepSpeech теперь потребляет в 22 раза меньше памяти и запускается в 500 раз быстрее.
  • Проведена фильтрация редких слов в языковой модели. Общее число слов сокращено до 500 тысяч самых популярных слов, встречающихся в тексте, использованном при тренировке модели. Проведённая чистка позволила снизить размер языковой модели с 1800МБ до 900МБ, практически не повлияв на показатели уровня ошибок распознавания.
  • Добавлена поддержка различных техник коррекции звуковых данных, используемых при обучении.
  • Добавлена библиотека с биндингами для интеграции с приложениями на базе платформы .NET.
  • Переработана документация, которая теперь собрана на отдельном сайте deepspeech.readthedocs.io.

Источник: [ссылка]

Началось общее голосование о системах инициализации в Debian

Проект Debian объявил о начале общего голосования (GR, general resolution) разработчиков проекта по вопросу поддержки нескольких систем инициализации, которое определит дальнейшую политику проекта в отношении привязки к systemd, поддержки альтернативных систем инициализации и взаимодействия с производными дистрибутивами, не использующими systemd. Голосование продлится до 27 декабря включительно, итоги будут подведены 28 декабря.

Напомним, что в 2014 году технический комитет утвердил переход дистрибутива по умолчанию на systemd, но не выработал решения по отношению к поддержке нескольких систем инициализации (при голосование победил пункт, указывающий на неготовность комитета вынести решение по данному вопросу). Лидер комитета порекомендовал сопровождающим пакеты сохранить поддержку sysvinit в качестве альтернативной системы инициализации, но указал, что не может навязывать свою точку зрения и в каждом случае решение следует принимать самостоятельно.

После этого некоторыми разработчиками была предпринята попытка проведения общего голосования, но предварительное голосование показало отсутствие необходимости принятия решения по вопросу использования нескольких систем инициализации. Несколько месяцев назад, после проблем с включением пакета elogind (необходим для работы GNOME без systemd) в ветку testing из-за конфликта с libsystemd, вопрос был повторно поднят лидером проекта Debian, так как разработчики не смогли договориться, а их общение переросло в противостояние и зашло в тупик.

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

Предложенные варианты:

  1. Основное внимание фокусируется на systemd. Предоставление поддержки альтернативных систем инициализации не является приоритетом, но сопровождающие вправе опционально включать в пакеты init-скрипты для таких систем.
  2. Поддержка разнообразных систем инициализации и возможность загрузки Debian с системами инициализации, отличными от systemd. Для запуска сервисов пакеты обязательно должны включать init-скрипты, поставка только unit-файлов systemd без sysv init-скриптов недопустима.
  3. Предпочитаемым остаётся systemd, но оставляется возможность сопровождения и альтернативных систем инициализации. Технологии, такие как elogind, позволяющие в альтернативных окружениях запускать приложения, привязанные к systemd, рассматриваются как важные. В пакеты допускается включение init-файлов для альтернативных систем.
  4. Поддержка систем, не использующих systemd, но без внесения изменений, мешающих развитию. Разработчики соглашаются поддерживать несколько систем инициализации в обозримом будущем, но также считают необходимым работать над улучшением поддержки systemd. Разработкой и сопровождением специфичных решений следует заниматься заинтересованным в таких решениях сообществам, но другие мэйнтейнеры должны активно помогать и способствовать решению проблем, когда в этом возникает необходимость. В идеале пакеты должны функционировать при использовании любой системы инициализации, для чего можно поставлять традиционные init-скрипты или использовать иные механизмы, позволяющие работать без systemd. Невозможность работы без systemd рассматривается как ошибка, но не как ошибка блокирующая релиз, за исключением случаев, когда имеется готовое решение для работы без systemd, но его отказываются сохранять (например, когда проблема вызвана удалением ранее поставлявшегося init-скрипта).
  5. Поддержка переносимости, без внесения изменений, мешающих развитию. Debian продолжает рассматриваться как связующее звено для интеграции различного ПО, предоставляющего эквивалентную или похожую функциональность. Переносимость между аппаратными платформами и программными стеками относится к важным задачам, а интеграция альтернативных технологий приветствуется, даже если мировоззрение их создателей расходятся с общим мнением. Позиция в отношении systemd и других систем инициализации полностью совпадает с 4 пунктом.
  6. Перевод поддержки нескольких систем инициализации в разряд обязательных. Предоставление возможности запуска Debian с системами инициализации, отличными от systemd, продолжает иметь значение для проекта. Каждый пакет обязан работать с обработчиками pid1, отличными от systemd, за исключением случаев, когда входящее в пакет ПО изначально предназначено для работы только с systemd и отсутствует поддержка запуска без systemd (отсутствие init-скриптов не считается предназначением только для работы с systemd).
  7. Поддержка переносимости и нескольких реализаций. Общие принципы полностью совпадают с пунктом 5, но в отношении systemd и систем инициализации не предъявляется конкретных требований, а также не накладываются какие-либо обязательства на разработчиков. Разработчикам предлагается учитывать интересы друг друга, идти на компромиссы и находить общие решения, удовлетворительные для различных сторон.
  8. Продолжение обсуждения. Пункт может использоваться для снижения рейтинга неприемлемых вариантов.

Источник: [ссылка]