И это всё МОЁ
21 августа вышла новая версия CRIU (Checkpoint and Restore In Userspace). Это проект по разработке инструментария для ОС GNU/Linux, который позволяет сохранить состояние процесса или группы процессов в файлы на диске и позднее восстановить его, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Один из основных сценариев использования CRIU — это живая миграция контейнеров между серверами, но им применение проекта не ограничивается.

Нововведения:

Поддержка архитектуры s390x.
Улучшения:

При падении восстановленных процессов записывается более подробный лог.
Слияние множества образов содержащих информацию о файлах в один большой files.img
Когда вспомогательная утилита не работает (ip, iptables, tar), ее имя выводится в лог.
Основные исправления:

Ошибка компиляции на новых glibc (ucontext_t)
Падение вспомогательных утилит может «заморозить» процесс восстановления.
Переменные в makefile не настраивались для сборки дистрибутива.
Наличие SIT (ipv6-to-v4 tunnel) на хосте блокирует дамп контейнеров.

»> Github проекта
github.com/xemul/criu

»> Подробности
criu.org/Download/criu/3.4

Источник:
www.linux.org.ru/news/opensource/13632960



00:13

CRIU 3.4

И это всё МОЁ

21 августа вышла новая версия CRIU (Checkpoint and Restore In Userspace). Это проект по разработке инструментария для ОС Linux, который позволяет сохранить состояние процесса или группы процессов в файлы на диске и позднее восстановить его, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Один из основных сценариев использования CRIU — это живая миграция контейнеров между серверами, но им применение проекта не ограничивается.

Нововведения:

  • Поддержка архитектуры s390x.

Улучшения:

  • При падении восстановленных процессов записывается более подробный лог.
  • Слияние множества образов содержащих информацию о файлах в один большой files.img
  • Когда вспомогательная утилита не работает (ip, iptables, tar), ее имя выводится в лог.

Основные исправления:

  • Ошибка компиляции на новых glibc (ucontext_t)
  • Падение вспомогательных утилит может «заморозить» процесс восстановления.
  • Переменные в makefile не настраивались для сборки дистрибутива.
  • Наличие SIT (ipv6-to-v4 tunnel) на хосте блокирует дамп контейнеров.

>>> Github проекта








 








И это всё МОЁ
Дополнительные исправления Vega/GFX9 опубликованы для драйвера Mesa RADV Vulkan.
ru.wikipedia.org/wiki/Mesa_3D
Похоже, что не пройдёт много времени, прежде чем David Airlie обеспечит полностью хорошую и исправную работу драйвера RADV Mesa Vulkan на новых видеокартах AMD Radeon RX Vega.

David был вынужден временно отключить поддержку Vega в драйвере RADV (Radeon Vulkan), так как поддержка не была готова к выходу финальной версии Mesa 17.2.0, но вскоре она может быть восстановлена для Mesa Git, а затем предоставлена для v17.2.1. В понедельник он опубликовал еще один набор исправлений, которые должны обеспечить исправную поддержку Vega/GFX9.




И это всё МОЁ
Лишь только стала забываться история с ответвлением и последующим воссоединением проектов Node.js и io.js, как наметился новый раскол в сообществе Node.js. В ходе конфликта группа энтузиастов основала очередной форк Node.js - Ayo. В качестве мотива создания форка упоминаются двойные стандарты в отношении принятого в сообществе Node.js кодекса поведения (Code of Conduct). В частности, утверждается, что Роду Вагу (Rod Vagg), одному из значительных участников сообщества, сходят с рук постоянные нарушения кодекса, которые не приводят к должному ответному воздействию.

В технический комитет Node.js, членом которого является Род, поступило несколько жалоб на недостойное поведение данного участника и превышение им полномочий модератора в ходе обсуждений на GitHub и в Twitter, что по мнению отправителей жалоб не соответствует принятому в сообществе кодексу поведения. Рассмотрев данные жалобы 60% (6 из 10 голосовавших) членов технического комитета Node.js не сочли нарушение поведения существенным и высказались против удаления Рода из состава комитета и против публикации призыва добровольно покинуть свой пост.

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

Источник:
www.opennet.ru/opennews/art.shtml?num=47072
Представлен Ayo, очередной форк проекта Node.js



И это всё МОЁ
Разработчики Intel OpenGL/Vulkan присоединяются к # intel-3d.

Для тех, у кого проблемы с драйверами OpenGL «i965» или «ANV» в Mesa, разработчики драйверов с открытым исходным кодом Intel теперь установили IRC # intel-3d для обсуждения этих драйверов Intel Mesa 3D.
Для разработчиков и пользователей # intel-3d теперь доступен как общедоступный ресурс в сети FreeNode IRC. Этот новый IRC-канал Intel 3D дополняет существующий канал # intel-gfx для общих графических обсуждений Intel GNU/Linux и более широкого канала # dri-devel.

Подробная информация на Mesa-dev:
lists.freedesktop.org/archives/mesa-dev/2017-Au...
Intel OpenGL/Vulkan Developers Join #intel-3d - Phoronix



И это всё МОЁ
Добавлена микропрограмма для работы Radeon Vega для Linux Firmware Git.

Теперь стало немного легче добиться исправной работы графических карт AMD Radeon Vega, работающих на GNU/Linux со стеком драйверов с открытым исходным кодом, при использовании которого Radeon RX Vega пока не может выводить изображение на монитор при использовании основной текущей версии ядра Linux из-за отсутствия кода вывода изображения "DC", по крайней мере, до выхода Linux 4.15, но еще одна важная часть головоломки теперь является основной: требуются образы прошивки/микрокода для Vega ,

Вместо того, чтобы загружать образы прошивки AMDGPU Vega с личного сайта разработчика Alex Deucher, бинарные файлы теперь присутствуют в "дереве" linux-firmware.git. Эти файлы прошивки теперь будут подхвачены различными дистрибутивами GNU/Linux в следующий раз, когда они обновят свои пакеты.

Сегодня были добавлены файлы прошивки Vega 10 и еще одно исправление для двоичных файлов UVD/VCE:
git.kernel.org/pub/scm/linux/kernel/git/firmwar...
git.kernel.org/pub/scm/linux/kernel/git/firmwar...
Radeon Vega Firmware Binaries Added To Linux Firmware Git - Phoronix



И это всё МОЁ
Представлен выпуск системы мониторинга Zabbix 3.4. Вышедшая версия содержит новую систему дэшбордов, несет новые возможности по предварительной обработке поступающих данных, предлагает новые механизмы массового сбора метрик и многое другое. Код проекта распространяется под лицензией GPLv2.

Напомним, что Zabbix состоит из трёх базовых компонентов: сервера для координации выполнения проверок, формирования проверочных запросов и накопления статистики; агентов для осуществления проверок на стороне внешних хостов; фронтэнда для организации управления системой. Для снятия нагрузки с центрального сервера и формирования распределённой сети мониторинга может быть развёрнута серия прокси-серверов, агрегирующих данные о проверке группы хостов. Данные могут храниться в СУБД MySQL, PostgreSQL, DB2 и Oracle. Без агентов Zabbix-сервер может получать данные по таким протоколам как SNMP, IPMI, JMX, SSH/Telnet, ODBC, проводить тестирование доступности Web-приложений и систем виртуализации.

Основные улучшения:

Новая система дэшбордов. Пользователи могут самостоятельно создавать дэшборды, располагая на странице различные виджеты. Дэшборды могут быть личными или доступны другим пользователям.

Препроцессинг поступающих значений такими функциями как Trim, Regexp,XPath, JSON Path

Массовый сбор данных. Новый механизм зависимых метрик позволяет один раз получать сразу группу элементов в формате, в котором предоставляет само контролируемое приложение, будь то XML, JSON или другой, а затем, используя возможности препроцессинга, пересылать каждое значение в зависимые отдельные метрики.
Выполнение удаленных команд и скриптов через Zabbix-прокси
Поддержка пользовательских макросов в интервалах опроса или хранения. Вместе с поддержкой суффиксов времени вида 30s, 5m, 2h, 1d, 1d позволяет добиться гибкости управления временными интервалами

Коллекция шаблонов сетевых устройств для таких вендоров как Alcatel, Brocade, Cisco, D-Link, HP, Huawei, Intel, Juniper, Mellanox, Mikrotik, Netgear и Ubiquiti
Настраиваемые JMX endpoint;

Низкоуровневое обнаружение (LLD) для JMX вида jmx.discovery[discovery mode,object name]
Более эффективная синхронизация конфигурационного кэша.
Реализован функционал полного клонирования карт и комплексных экранов
Прекращена поддержка Internet Explorer 9 и 10. А также SQLite для сервера( поддерживается на Zabbix proxy)
Возможность получать уведомления о подтверждении аварий

Реализована параллельная отсылка оповещений

Возврат сообщения об ошибке при выполнении скриптов и отправке уведомлений

Оптимизирована работа сбора данных по IPMI
Добавлена поддержка {HOST.*} макросов в тэгах событий
Реализована новая агентская проверка vfs.dir.size для контроля размера директории

Источник:
www.opennet.ru/opennews/art.shtml?num=47070
Выпуск системы мониторинга Zabbix 3.4



И это всё МОЁ
Доступна версия Wine Staging 2.15.

Wine - это не эмулятор, а свободная реализация WinAPI, Wine ползволяет без установки MS Windows запускать на GNU/Linux и других о.с. игры/приложения, созданные эксклюзивно только для MS Windows.

Что нового в этой версии:

Поддержка смешения двойного источника и произвольных viewports в d3d11.
Исправление ошибок JPEG-декодера и поддержка преобразования изображений CMYK в windowscodecs.
Поддержка шифрования AES 192/256 бит и импорт/экспорт ключей в bcrypt.
Различные небольшие улучшения и исправления ошибок.
www.wine-staging.com/news/2017-08-23-release-2....

Кроме того, пользователи Wine Staging также получат выгоду от следующих изменений, добавленных в разрабатываемую, "ванильную" ветку Wine:

Добавлена поддержка шифрования AES;
Улучшена поддержка кривых Безье в Direct2D;
Улучшены средства chunked-передачи в WinInet;
С момента выпуска версии 2.14 было закрыто 9 отчётов об ошибках.
Все прочие подробности по ссылке:
www.winehq.org/announce/2.15

Wine Staging является вечно тестовой версией Wine для экспериментов. В него быстрее всего попадают самые передовые нововведения Wine для тестирования их, и зачастую быстрее, чем в обычной версии Wine дополнительно исправляются некоторые баги. После окончания тестирования эти изменения со временем могут перейти в обычную версию Wine. Но, не всегда, и не все нововведения переносятся из Wine Staging в обычную версию Wine. Зачастую в патчи, которые по каким-либо причинам не хотят принимать в основную ветвь Wine, так и остаются эксклюзивно только в Wine Staging. Поэтому, на практике это означает, что Wine Staging уже позволяет запускать то, что на данный момент ещё пока что не умеет обычный Wine. Примером такого может послужить тот факт, что только на Wine Staging работают такие знаменитые игры ААА-класса, как Witcher 3, Assassin's Creed 4, GTA5, Fallout 4 и многих других, при том, что они вовсе не запускаются при использовании основной, "обычной" версии Wine. Кроме того, Wine Staging даёт возможность включить в настройках (winecfg) экспериментальную функцию "CSMT", дающую, по сравнению с обычным Wine, прирост FPS в играх на около 40-50%! Включение CSMT ещё и помогает избавиться от искажений графики в некоторых играх. Но, учтите, что обилие экспериментальных патчей иногда (весьма редко) может привести к полной или частичной неработоспособности программ, запускаемых через Wine Staging или другим, более мелким ошибкам. Но, также зачастую может и исправить в лучшую сторону многие вещи, всё ещё не исправленные в обычной, "ванильной" версии Wine.

Для установки Wine Staging в Arch Linux или основанных на нём дистрибутивах GNU/Linux достаточно просто выполнить:
$ sudo pacman -Syu wine-staging wine-mono wine_gecko
$ pacman -Qi wine-staging покажет, каких ещё не хватает дополнительных зависимостей, которые следует установить.
Для других дистрибутивов инструкция по ссылке:
www.wine-staging.com/installation.html

Wine Staging



И это всё МОЁ
В рамках проекта D-Bus Broker развивается новая реализация шины D-Bus.

Дэвид Герман (David Herrmann), в своё время разработавший шину обмена сообщениями Bus1 для ядра Linux, представил новый проект D-Bus Broker, в рамках которого предпринята попытка переосмысления D-Bus и создания новой реализации, устраняющей недостатки штатного демона D-Bus. Код проекта написан на языке Си и распространяется под лицензией Apache 2.0.

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

В отличие от Bus1 проект D-Bus Broker реализован целиком в пространстве пользователя, остаётся полностью совместим с эталонной реализацией D-Bus и может быть использован для прозрачной замены dbus-daemon. При этом новая реализация спроектирована с оглядкой на поддержку востребованной на практике функциональности и уделяет главное внимание работе по увеличению производительности и повышению надёжности. В D-Bus Broker также принципиально не реализованы функции, помеченные как устаревшие, и расширенные возможности, не отражённые в спецификации D-Bus.

Ключевые архитектурные изменения в D-Bus Broker:

Уход от идеи глобальной совместной шины (Shared Medium), к которой соединяются все обработчики сообщений и через которую осуществляется отправка сообщений. Вместо общей шины предложена концепция отдельных пиров, не имеющих глобального состояния. Когда какой-то пир отправляет сообщения, эта операция рассматривается как транзакция между отправителем и одной или несколькими точками назначения.
Отказ от использования дополнительных IPC-механизмов, так как D-Bus сам по себе является IPC и создание надстроек IPC над IPC приводит к появлению взаимных блокировок. Иными словами D-Bus Broker является самодостаточным процессом, который позволяет оперировать только локальными данными и не привязан к внешним обработчикам, таким как чтение файлов и обращение к NSS.
Учёт ресурсов в привязке к пользователям. Каждый ресурс и переданный в шину объект привязан к конкретному пользователю. Таким образом, существенно упрощается реализации ограничений и лимиты больше не привязываются к пиру (ограничения теперь зависят от активности каждого пользователя, а не от общей нагрузки на обработчик).
Воплощение принципа, что сообщение никогда не может быть потеряно без обработки ошибки. В случае возникновения проблем недопускается возникновения неопределённых ситуаций, каждая ошибка доставки должна быть выявлена и обработана, а в случае невозможности обработки ошибки процесс должен завершить свою работу, а не просто игнорировать возникшие проблемы.
Что касается высокой производительности D-Bus Broker, то её ценой является привязка к современным окружениям Linux - для своей работы проект требует наличия ядра Linux 4.10 и glibc 2.16, и принципиально не может быть использован в старых дистрибутивах Linux или в других ОС. Предоставляются опциональные компоненты для интеграции с systemd и SELinux. Обеспечивается работа только локального IPC без поддержки сетевого взаимодействия (при необходимости проброса на другой хост предлагается пробрасывать локальный сокет через SSH).

www.opennet.ru/opennews/art.shtml?num=47071



И это всё МОЁ
Лишь только стала забываться история с ответвлением и последующим воссоединением проектов Node.js и io.js, как наметился новый раскол в сообществе Node.js. В ходе конфликта группа энтузиастов основала форк Node.js - Ayo. Основным мотивом создания форка упоминается двойные стандарты в отношении принятого в сообществе Node.js кодекса поведения (Code of Conduct). В частности, утверждается, что одному из значительных участников сообщества (Rod Vagg) сходят с рук постоянные нарушения кодекса, которые не приводят к должному ответному воздействию.



И это всё МОЁ
Мне стало любопытно узнать, когда же заканчивается поддержка устаревших видеокарт Nvidia для GNU/Linux. И тогда я стал искать ответ в duckduckgo.com/
Нашёл новостную статью 2014 года. И так, вот отрывок из той статьи:

"За поддержку устаревших видеокарт отвечает ветка Legacy, включающая в себя серии драйверов 340.*, 304.*, 71.86.*, 96.43.* и 173.14.*. В заявлении на официальном сайте NVIDIA о сроках поддержки драйверов данной ветки говорится следующее:

«Серия драйверов 340.* является последней серией с поддержкой чипсетов G8x, G9x, GT2xx и чипсетов для материнских плат на их основе. Поддержка новых версий ядра Linux и X-сервера, а также исправления критических ошибок будут включены в последующие релизы серии 340.* до конца 2019 года. Серия драйверов 304.* является последней серией с поддержкой чипсетов NV4x, G7x и чипсетов для материнских плат на их основе. Поддержка новых версий ядра Linux и X-сервера, а также исправления критических ошибок будут включены в последующие релизы серии 304.* до конца 2017 года."

Так что, если у вас видеокарта Nvidia старее, чем серия 400, то пришло время задуматься о покупке новой видеокарты.
NVIDIA раскрыла планы о сроках поддержки устаревших видеокарт в драйверах для Linux



И это всё МОЁ
Дэвид Герман (David Herrmann), в своё время разработавший шину обмена сообщениями Bus1 для ядра Linux, представил новый проект D-Bus Broker, в рамках которого предпринята попытка переосмысления D-Bus и создания новой реализации, устраняющей недостатки штатного демона D-Bus. Код проекта написан на языке Си и распространяется под лицензией Apache 2.0.



И это всё МОЁ

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


Запись Как узнать версию Linux впервые появилась Losst.






@темы: Инструкции

И это всё МОЁ
Mesa-драйвер RadeonSI получил повышение производительности для игры Dawn of War III.

Samuel Pitoiset, работающий в Valve, приступил к своей новейшей работе над Mesa Git, чтобы улучшить драйвер RadeonSI Gallium3D с открытым исходным кодом.
С изменениями, которые сделал Samuel для использование индексов слотов для bindless handles, вместо адресов vRAM, он сказал, что это должно улучшить производительность Dawn of War 3 на GNU/Linux примерно на 7%. Это изменение добавлено в Mesa Git для включения его в выпуск Mesa 17.3 в ноябре 2017.




И это всё МОЁ
Поддержка FP64 для драйвера Mesa R600g Gallium3D.

В то время как серия Radeon HD 5000/6000 рекламировалась как поддерживающая OpenGL 4.4, который для этих моделей на данный момент поддерживается только устаревшим проприетарным драйвером AMD Catalyst/Radeon Software, драйвер Mesa R600g заявляет лишь только о поддержке OpenGL 3.3 (за исключением серии HD 5800/6900) из-за отсутствия поддержки FP64. Но, теперь делаются шаги для добавления этой эмулированной поддержки FP64 для драйвера Mesa R600g.

www.phoronix.com/scan.php?page=news_item&px=FP6...
Elie Tournier - разработчик, который ранее работал над программной реализацией FP64 для Mesa с использованием чистого GLSL. Tournier теперь работает в Collabora, где среди поставленных перед ним задач есть добавление поддержки FP64, которая может использоваться драйвером Mesa R600 Gallium3D. Если R600g получит FP64, эти видеокарты могут теперь получить полную поддержку OpenGL 4.1, аналогично серии HD 5800/6900 из-за того, что они действительно аппаратно имеют настоящую, а не только программную поддержку FP64.

Пока эти патчи еще не готовы к объединению с Mesa, Elie Tournier сегодня разослал исправления для разработки программной поддержки FP64 в R600g. Есть некоторые проблемы с поддержкой плавающей запятой с двойной точностью и некоторыми операциями, приводящими к сбою системы, среди других ранних недостатков, но добавление этой поддержки продвигается.

На данный момент существует 47 патчей для добавления этой программной поддержки FP64, которая составляет более двадцати двух тысяч строк кода, большинство из которых содержится в коде компилятора Mesa GLSL. Поскольку он находится в общем коде, эта поддержка FP64 все еще может использоваться другими драйверами/аппаратными средствами, не имеющими встроенной аппаратной поддержки FP64.

Для получения Mesa-драйвером R600g полной поддержки OpenGL 4.2 не хватает OpenGL-расширений shader_atomic_counters и shader_image_load_store, в то время как есть гораздо больше расширений, отсутствие которых все еще блокируют появление в драйвере R600g полной поддержки OpenGL 4.3+.

Те, кто хочет посмотреть на эту новейшую работу, могут найти эти патчи через Mesa-dev:
lists.freedesktop.org/archives/mesa-dev/2017-Au...
FP64 Support Revised For R600g Gallium3D Driver - Phoronix



И это всё МОЁ
Проект "Inputfd" все еще работает над созданием реализации прямого доступа к устройствам ввода при использовании Wayland вместо Xorg-server.

Прошло несколько месяцев с тех пор, как я слышал что-нибудь новое о проекте "inputfd", расширении протокола Wayland для обеспечения прямого доступа устройствами ввода. Кроме других преимущества, это расширение протокола позволит обеспечить более лучшую работу различных игровых устройств ввода при использовании Wayland вместо Xorg-server.
www.phoronix.com/scan.php?page=news_item&px=Inp...

www.phoronix.com/scan.php?page=news_item&px=Inp...
Предлагаемое расширение протокола ввода-вывода позволяет осуществлять прямой доступ к устройствам ввода с помощью компоновщика Wayland (Wayland compositor), передавая файловый дескриптор устройства запрашиваемому клиенту. Это позволит избежать необходимости использовать libinput, требующего поддержки всех этих типов устройств ввода/периферийных устройств, особенно для всех различных игровых контроллеров. Когда компоновщик Wayland обрабатывает/захватывает FD устройство и передаёт, клиенту не нужны специальные привилегии. Джойстики/геймпады, 3D-мыши, устройства ввода VR итд являются одними из возможных устройств для использования inputfd.

Сегодня утром Питер Хаттер отправил разработчикам Wayland Protocols свою третью версию этого предлагаемого протокола. Разработчики, желающие узнать больше, могут увидеть предлагаемый протокол Wayland через wayland-devel:
lists.freedesktop.org/archives/wayland-devel/20...


Inputfd Still Being Worked On For Direct Input Access Under Wayland - Phoronix



И это всё МОЁ
Релиз библиотеки GnuTLS 3.6.0.

Представлен значительный выпуск GnuTLS 3.6.0, свободной библиотеки с реализацией протоколов SSL, TLS и DTLS, алгоритмов шифрования (включая AES и Camellia) и функций для работы с различными типами сертификатов и ключей. Ветка 3.6.x подготовлена после шестнадцати месяцев разработки в Git-репозитории и помечена как stable-next, что сигнализирует о достижении качества стабильной ветки, но пока неготовности заменить текущую стабильную ветку 3.5.x, поддержка которой будет продолжена.

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

Генератор псевдослучайных чисел избавлен от глобальной блокировки, мешающей эффективному применению в многопоточных приложениях (производительность теперь масштабируется от числа CPU).
Генератор псевдослучайных чисел переведён на использование потокового шифра CHACHA, который по сравнению с ранее применявшимся алгоритмом Salsa20 позволяет сократить размер загружаемого в память кода и унифицировать применение основных методов шифрования (CHACHA также используется в TLS и других примитивах GnuTLS). Изменение не касается альтернативного генератора псевдослучайных чисел AES-DRBG, который применяется в режиме FIPS140-2;
Добавлена поддержка ключей RSA-PSS, а также создания и верификации цифровых подписей RSA-PSS для сертификатов и согласования соединения в TLS 1.2;
В сертификатах (PKCS#8, PKCS#7, PKIX) и TLS-ключах появилась возможность использования цифровой подписи с открытым ключом Ed25519, разработанной Дэниэлом Бернштейном и отличающейся очень высокой скоростью верификации и создания подписей при более высоким уровнем безопасности, чем ECDSA и DSA. Ed25519 не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через определение скорости работы кэша (cache-timing attacks) и атакам по сторонним каналам (side-channel attacks);
В TLS по умолчанию активирован обмен ключами на основе алгоритма X25519 (RFC 7748);
Добавлена поддержка протокола согласования групп (GROUP-ALL, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE8192) на основе эллиптических кривых ECDH (Elliptic Curve Diffie-Hellmann), позволяющего повысить минимизировать ошибки из-за применения не безопсных значений параметров DH (параметры теперь не обязательно жестко определять на сервере);
Реализованы дополнительные проверки корректности оформления сертификатов при их импорте. Например, теперь не принимаются сертификаты с дробными значениями секунд в полях со временем, сертификаты X.509v1 с уникальным набором идентификаторов, не соответствующих RFC5280, и сертификаты с некорректным номером версии;
Добавлена функция gnutls_x509_crt_set_flags() для выставления произвольных флагов в структуре crt. В текущем выпуске поддерживается только флаг GNUTLS_X509_CRT_FLAG_IGNORE_SANITY для отключения проверок корректности сертификата при импорте;
Запрещена обработка сертификатов PKIX с неизвестными критическими расширениями, при попытке использования подобных сертификатов будет выводиться ошибка GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS. Для отключения данного поведения следует указать флаг GNUTLS_VERIFY_IGNORE_UNKNOWN_CRIT_EXTENSIONS при вызове функций верификации;
Запрещена генерация сертификатов с некорректным номером версии или серийным номером, заданными через вызовы gnutls_x509_crt_set_version() и gnutls_x509_crt_set_serial();
Обеспечена блокировка выполнения функций gnutls_record_send() и gnutls_record_recv() на стадиях до завершения согласования соединения;
Добавлена поддержка файлов PKCS#12 хэшем пароля без соли, а также файлов PKCS#12 с хэшами SHA384 и SHA512 в качестве MAC;
Из списка предлагаемых по умолчанию шифров исключен 3DES-CBC, для его применения следует явно указать "NORMAL:+3DES-CBC";
Хэш SHA1 помечен как небезопасный для цифровых подписей, процесс верификации сертификатов с SHA1 теперь завершается неудачей, если GnuTLS не собран с опцией "--enable-sha1-support" или в настройках явно не разрешено использование небезопасных алгоритмов;
Алгоритм RIPEMD160 помечен небезопасный для цифровых подписей;
По умолчанию на стадии согласования соединения TLS отключена поддержка эллиптических кривых SECP192R1 и SECP224R1, вместо которых рекомендуется использовать x25519 и которые объявлены устаревшими в спецификации TLS 1.3;
Удалена поддержка DEFLATE и других методов сжатия;
Удалена поддержка аутентификации OpenPGP, а вместо связанных с openpgp функций поставлены заглушки;
Удалена поддержка библиотеки libidn (IDNA2003). Допускается сборка gnutls только с libidn2 (IDNA2008);
Расширены возможности утилиты certtool: добавлена поддержка указания URL PKCS#11 в качестве аргумента опции '--load-ca-certificate', опция '--load-crl' теперь может применяться для генерации файлов PKCS#12, добавлена возможность генерации и обработки ключей и сертификатов на базе RSA-PSS и Ed25519. Объявлено устаревшим использование параметров "--rsa", "--dsa" и "--ecdsa" совмесно с опцией "--generate-privkey" (следует использовать "--key-type");
В утилите p11tool опции "--generate-rsa", "--generate-ecc" и "--generate-dsa" заменены на универсальную опцию "--generate-privkey";
В psktool по умолчанию обеспечена генерация 256-разрядных ключей ;
В gnutls-server размер буфера запросов увеличен до 16 Кб и добавлены опции "--alpn" и "--alpn-fatal" для тестирования согласования соединений ALPN;
В набор тестов, применяемых в системе непрерывной интеграции, включен пакет tlsfuzzer, который позволит оперативно выявлять отклонения в поведении реализации TLS между релизами;
Добавлены новые элементы API:
gnutls_encode_rs_value
gnutls_decode_rs_value
gnutls_base64_encode2
gnutls_base64_decode2
gnutls_x509_crt_set_flags
gnutls_x509_crt_check_ip
gnutls_x509_ext_import_inhibit_anypolicy
gnutls_x509_ext_export_inhibit_anypolicy
gnutls_x509_crt_get_inhibit_anypolicy
gnutls_x509_crt_set_inhibit_anypolicy
gnutls_pubkey_export_rsa_raw2
gnutls_pubkey_export_dsa_raw2
gnutls_pubkey_export_ecc_raw2
gnutls_privkey_export_rsa_raw2
gnutls_privkey_export_dsa_raw2
gnutls_privkey_export_ecc_raw2
gnutls_x509_spki_init
gnutls_x509_spki_deinit
gnutls_x509_spki_get_pk_algorithm
gnutls_x509_spki_set_pk_algorithm
gnutls_x509_spki_get_digest_algorithm
gnutls_x509_spki_set_digest_algorithm
gnutls_x509_spki_get_salt_size
gnutls_x509_spki_set_salt_size
gnutls_x509_crt_set_spki
gnutls_x509_crt_get_spki
gnutls_x509_privkey_get_spki
gnutls_x509_privkey_set_spki
gnutls_x509_crq_get_spki
gnutls_x509_crq_set_spki
gnutls_pubkey_set_spki
gnutls_pubkey_get_spki
gnutls_privkey_set_spki
gnutls_privkey_get_spki
gnutls_privkey_import_ext4
GNUTLS_EXPORT_FLAG_NO_LZ
GNUTLS_DT_IP_ADDRESS
GNUTLS_X509_CRT_FLAG_IGNORE_SANITY
GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS
GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1
GNUTLS_VERIFY_DO_NOT_ALLOW_IP_MATCHES
GNUTLS_VERIFY_IGNORE_UNKNOWN_CRIT_EXTENSIONS
GNUTLS_SFLAGS_RFC7919

www.opennet.ru/opennews/art.shtml?num=47067





И это всё МОЁ

Разработчики браузера Firefox выразили желание собирать больше статистики о том, каким образом пользователи используют их продукт. Они утверждают, что это поможет им лучше оптимизировать свой код.

Такая статистика уже может собираться, но в добровольном порядке и требует от пользователя явного разрешения (т. н. opt in). Очевидно, что объём данных, полученный таким образом, недостаточен для полезной статистики. Включить же сбор данных по умолчанию (и с возможностью отключения пользователем) на данном этапе невозможно по соображениям приватности.

В качестве решения этой проблемы предлагается использовать механизм Differential privacy, который предположительно крайне затруднит проведение соответствий между данными и пользователем.

Mozilla хочет задействовать Google-проект RAPPOR, который является самой известной реализацией Differential privacy, и сообщает, что начальные эксперименты с этой технологией выглядят многообещающе.

Эксперимент начнётся в середине сентября в режиме opt out (с возможностью отключения), и его задачей будет анализ работоспособности подхода. В качестве тестовых, ранее не собиравшихся, данных будет анализироваться востребованность «home page».








 ,








И это всё МОЁ
Обзор графического редактора Krita разработчиком. Конференция OSEDUCONF-2014.

Я понял, что многие, к сожалению, не знают о существовании свободного графического редактора Krita с открытым исходным кодом. Один из разработчиков, [id204680363|Дмитрий Казаков] на конференции OSEDUCONF-2014 рассказывает о Krita, и о некоторых интересных особенностях.
Свежее я, к сожалению, не нашёл



И это всё МОЁ


опенкоробка на gentoo










Привет, ЛОР.

Решил пересесть с i3 на Openbox, в связи с покупкой новой мышки и желанием юзать ее не переставая.

  • urxvt. ШГ - terminus
  • Sublime с проектом, который был изначально начат для изучения работы с гитом в команде, но люди так и не смогли заставить себя написать хоть строчку кода. шг - Hack
  • Обоина
  • Панель - tint2. шг - artwiz lemon. Иконки в лаунчере стащил с flaticon

















>>> Просмотр
(1920x1080,
2157 Kb
)










 ,