Nokia представила сетевую операционную систему SR Linux для маршрутизаторов

Компания Nokia представила новую сетевую операционную систему Service Router Linux (SR Linux), ориентированную на использование в сетевой инфраструктуре центров обработки данных и облачных окружений. SR Linux рассматривается как ключевой компонент решений Nokia Data Center Fabric и будет устанавливаться на маршрутизаторы линейки Nokia 7250 IXR и 7220 IXR. Решение на базе SR Linux уже проходит тестирование в новом датском датацентре компании Apple.

В отличие от других ОС для сетевого оборудования на базе ядра Linux в SR Linux сохранена возможность доступа к лежащему в основе платформы Linux-окружению, которое не скрыто за специализированными API и интерфейсами. Пользователи имеют доступ к немодифицированному ядру Linux и базовым системным приложениям (bash, cron, Python и т.п.), а специфичные приложения создаются при помощи инструментария NetOps Toolkit, не привязанного к определённым языкам программирования. Приложения на базе NetOps Toolkit, например, реализации протоколов маршрутизации, получают доступ к различным сетевым API, но функционируют как независимые компоненты.

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

Управление может производиться через gNMI (gRPC Network Management Interface), интерфейс командной строки, плагины на Python и API на основе JSON-RPC. Для обращения к функциональности работающих в системе сервисов предлагается использовать gRPC и протокол обмена данными Protocol Buffers. Приложения SR Linux могут обмениваться данными о состоянии, используя архитектуру «publish/subscribe» (pub/sub), в которой также применяется gRPC и Protocol Buffers, а в качестве механизма гарантированной доставки используется IDB (Nokia Impart Database). Для структурирования информации о состоянии приложения и используемой конфигурации применяются модели данных YANG (Yet Another Next Generation, RFC-6020).

Реализации сетевых протоколов, включая Multiprotocol Border Gateway Protocol (MP-BGP), Ethernet VPN (EVPN) и Virtual Extensible LAN (VXLAN), основаны на проверенном стеке протоколов SR OS (Nokia Service Router Operating System), уже применяемом на более чем миллионе маршрутизаторов Nokia. Для абстрагирования от аппаратных компонентов используется подсистема XDP (eXtensible Data Path).

Для автоматизации выполнения операций по созданию, развёртыванию, настройке сетевой инфраструктуры ЦОД, сбору и анализу телеметрии предлагается Nokia Fabric Services Platform (FSP). FSP также предоставляет инструменты программной симуляции сети для упрощения планирования, проектирования, тестирования и отладки сетей в датацентрах. Сетевые компоненты симулируются при помощи контейнерной изоляции на базе платформы Kubernetes, позволяющей запускать отдельные экземпляры SR Linux в своих изолированных окружениях.

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

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

Релиз сетевого конфигуратора NetworkManager 1.26.0

Представлен стабильный релиз интерфейса для упрощения настройки параметров сети — NetworkManager 1.26.0. Плагины для поддержки VPN, OpenConnect, PPTP, OpenVPN и OpenSWAN развиваются в рамках собственных циклов разработки.

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

  • Добавлена новая сборочная опция ‘firewalld-zone’, при включении которой NetworkManager будет устанавливать в динамический межсетевой экран firewalld зону для совместного использования соединения и при активации новых подключений помещать сетевые интерфейсы в эту зону. Для открытия портов для DNS и DHCP, а также для трансляции адресов, NetworkManager по-прежнему вызывает iptables. Новая опция может оказаться полезной для систем, использующих firewalld с бэкендом nftables, на которых недостаточно использования iptables.
  • Расширен синтаксис свойств сопоставления (‘match’), в которых теперь допускается использование операций ‘|’, ‘&’, ‘!’ и ‘\’.
  • Для профилей соединений добавлено свойство MUD URL (RFC 8520, Manufacturer Usage Description) и обеспечена его установка для запросов DHCP и DHCPv6.
  • В плагине ifcfg-rh добавлена обработка свойств 802-1x.pin и «802-1x.{,phase2-}ca-path».
  • В nmcli устранена уязвимость CVE-2020-10754, связанная с игнорированием параметров 802-1x.ca-path и 802-1x.phase2-ca-path при создании нового профиля соединения. При попытке подключения к сети под этим профилем аутентификация не производилась и устанавливалось небезопасное соединение. Уязвимость проявляется только в сборках, использующих для настройки плагин ifcfg-rh.
  • Для Ethernet при деактивации устройства обеспечен сброс оригинальных настроек автосогласования, скорости и duplex.
  • Добавлена поддержка опций «coalesce» и «ring» утилиты ethtool.
  • Обеспечена возможность работы team-соединений без D-Bus (например, в initrd).
  • Для Wi-Fi разрешено продолжение попыток автосоединения при сбое предыдущих попыток активации (начальный сбой установки соединения теперь не блокирует автосоединение, но для существующих заблокированных профилей могут возобновиться попытки автосоединения).
  • Добавлена поддержка типа маршрутов «local», помимо «unicast».
  • В состав включены man-руководства nm-settings-dbus и nm-settings-nmcli.
  • Обеспечена поддержка пометки через D-Bus внешне управляемых устройств и профилей. Подобные устройства, работа с которыми производится через внешний обработчик, теперь также специально помечаются в nmcli.
  • Добавлена поддержка задания опций сетевых мостов.
  • Для профилей соединения добавлены match-сопоставления пути к устройству, драйверу и параметрам ядра.
  • Добавлена поддержка дисциплин ограничения трафика bf и sfq.
  • В nm-cloud-setup реализован провайдер для Google Cloud Platform, который автоматически определяет и настраивает получение трафика от внутренних балансировщиков нагрузки.

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

Релиз тикет-системы OTOBO, форка OTRS

Компания Rother OSS представила первый стабильный релиз тикет-системы OTOBO 10.0.1, форка OTRS CE. Система предназначена для решения таких задач, как обеспечение работы службы технической поддержки (help desk), управление ответами на запросы клиентов (телефонные звонки, email), координирование предоставления корпоративных IT-сервисов, управление заявками в службе продаж и финансовых службах. Код OTOBO написан на языке Perl и распространяется под лицензией GPLv3.

Стефан Ротер, ныне основатель и управляющий директор Rother OSS, присоединился к OTRS GmbH (сегодня OTRS AG) в 2004 году. В 2011 году он основал собственную компанию Rother OSS. К 2019 году Rother OSS сконцентрировалась на предоставлении бизнес-услуг, связанных с вариантами OTRS с открытым исходным кодом. В ответ на изменившуюся стратегию выпуска OTRS AG и задержку с выпуском новых версий OTRS Community Edition, Rother OSS приступили к разработке системы заявок OTOBO (Open Ticket Ours Based Otrs) на основе OTRS версии 6. Бизнес-концепция OTOBO — в поддержке бизнес-пользователей, их консультировании и обучении. Разработки, заказанные заказчиками, которые полезны для более широкой пользовательской базы, планируется возвращать в ее исходный код.

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

  • Обновлён портал для клиентов;
  • Проведена оптимизация форм, добавлена поддержка многостолбцовых форм ввода;
  • Реализован быстрый поиск на основе Elasticsearch;
  • Добавлена поддержка двухфакторной аутентификации, защиты от подбора паролей и расширенных средств для назначения политики определения паролей;
  • Обеспечена интеграция с Docker.

Также разработан инструмент миграции, который позволяет перейти с OTRS CE 6 на OTOBO. Для установки доступен как установочный пакет, так и образы Docker. Также предлагаются услуги хостинга. Демо-доступ: клиентская часть (логин Felix, пароль Felix), интерфейс администратора (логин Lena, пароль Lena).

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

В libtorrent добавлена поддержка протокола WebTorrent

В библиотеку libtorrent, предлагающую эффективную с точки зрения потребления памяти и нагрузки на CPU реализацию протокола BitTorrent, добавлена поддержка протокола WebTorrent. Код работы с WebTorrent войдёт в состав следующего значительного выпуска libtorrent, сформированного после ветки 2.0, которая находится на стадии кандидата в релизы.

WebTorrent представляет собой расширение протокола BotTorrent, позволяющее организовать децентрализованную сеть распространения контента, функционирующую через связывание между собой браузеров пользователей, просматривающих контент. Проект не требует для работы внешней серверной инфраструктуры и браузерных плагинов. Для связывания посетителей сайтов в единую сеть доставки контента достаточно разместить на сайте специальный JavaScript-код, использующий для прямого обмена данными между браузерами технологию WebRTC. Проектом также развивается десктоп-клиент WebTorrent Desktop, обладающий такими расширенными возможностями, как стриминг видео.

Интеграция WebTorrent в libtorrent позволит участвовать в раздаче контента не только через браузеры посетителей сайтов, но и через стационарные торрент-клиенты, использующие библиотеку libtorrent, включая Deluge и qBittorrent (rTorrent изменение не затрагивает, так как он использует другую библиотеку libtorrent). Добавленная в libtorrent реализация WebTorrent написана на C++ и при желании может быть перенесена в другие torrent-библиотеки и клиенты (оригинальный WebTorrent написан на JavaScript).

Таким образом могут формироваться гибридные сети с участниками, способными взаимодействовать с сетями на основе BitTorrent и WebTorrent. Торрент-клиенты на основе libtorrent смогут соединяться с работающими в браузерах пирами WebTorrent, например, участвующими в обмене файлами через instant.io, а также с системами видеовещания или видеохостинга на базе PeerTube. В свою очередь, браузерные клиенты WebTorrent смогут через пользователей стационарных клиентов получить доступ к обширной коллекции торрентов, раздаваемой BitTorrent-пирами поверх TCP/UDP.

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

Основан Xfce Classic, форк Xfce без декорирования окон на стороне клиента

Шон Анастаси (Shawn Anastasio), энтузиаст свободного ПО, в своё время разрабатывавший собственную операционную систему ShawnOS и занимавшийся портировнием Chromium и Qubes OS на архитектуру ppc64le, основал проект Xfce Classic, в рамках которого намерен развивать форки компонентов пользовательского окружения Xfce, работающие без применения декорирования окон на стороне клиента (CSD, client-side decorations), при котором заголовок и рамки окна отрисовываются не оконным менеджером, а самим приложением.

Напомним, что при подготовке следующего выпуска Xfce 4.16, релиз которого ожидается в октябре или ноябре, осуществлён перевод интерфейса на виджет GtkHeaderBar и применение CSD, что дало возможность по аналогии с GNOME добиться размещения меню, кнопок и других элементов интерфейса в заголовке окна, а также обеспечить скрытие рамок в диалогах. Новый механизм отрисовки интерфейса интегрирован в библиотеку libxfce4ui, что привело к автоматическому применению CSD для почти всех диалогов, без необходимости внесения изменений в код существующих проектов.

У перехода на CSD нашлись противники, которые считают, что поддержка CSD должна быть опциональной и пользователь должен иметь возможность продолжить использование классических заголовков окон. Из недостатков применения CSD упоминается слишком массивная область заголовка окна, отсутствие потребности переносить элементы приложения в заголовок окна, неработоспособность тем оформления Xfwm4 и разнобой в оформлении окон приложений Xfce/GNOME и программ, не использующих CSD. Отмечается, что одной из причин неприятия интерфейса GNOME некоторыми пользователями является применение CSD.

Так как за 5 месяцев не было предпринято попыток предоставить поддержку отключения CSD, Шон Анастаси решил взять данный вопрос в свои руки и создал форк библиотеки libxfce4ui, в котором провёл чистку привязки к CSD и вернул старый режим декорирования на стороне сервера (оконного менеджера). Для обеспечения совместимости с приложениями, использующими новый API libxfce4ui, и сохранения ABI, подготовлены специальные обвязки, транслирующие специфичные CSD-методы класса XfceTitledDialog в вызовы класса GtkDialog. В итоге предоставлена возможность избавления приложений Xfce от CSD путём замены библиотеки libxfce4ui, без изменения кода самих приложений.

Дополнительно сформирован форк панели xfce4-panel, включающей изменения для возвращения классического поведения. Для пользователей Gentoo подготовлен overlay для установки libxfce4ui-nocsd. Для пользователей Xubuntu/Ubuntu подготовлен PPA-репозиторий с готовыми пакетами. Мотивы создания форка Шон Анастаси пояснил тем, что он уже много лет использует Xfce и ему нравится интерфейс данного окружения. После принятия решения по изменению интерфейса, с которыми он был несогласен, и отсутствию попыток предоставить опцию для возвращения старого поведения, было решено самостоятельно решить свою проблему и поделиться решением с другими людьми, разделяющими его точку зрения.

Из проблем при использовании Xfce Classic отмечается возникновение впечатления дублирования заголовков из-за отображения повторяющейся информации в заголовке и в окне приложения. Данная особенность соответствует поведению Xfce 4.12 и 4.14, и не связана с CSD. В одних приложениях подобное дублирование выглядит нормально (например, в xfce4-screenshooter), но в других явно неуместно. Для решения данной проблемы не исключается добавление переменной окружения, регулирующей отрисовку XfceHeading.

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

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

В состав ядра Linux 5.8 приняты рекомендации по инклюзивной терминологии

Линус Торвальдс принял в состав ветки ядра Linux 5.8 изменения рекомендаций по стилю оформления кода. В состав принята третья редакция текста об использовании инклюзивной терминологии, которая была одобрена 21 известным разработчиком ядра, включая членов технического комитета Linux Foundation. Линусу был отправлен запрос на включение изменений в ядро 5.9, но он посчитал, что нет оснований ждать следующего окна приёма изменений и принял новый документ в ветку 5.8.

Третий вариант текста от инклюзивной терминологии был сокращён по сравнению с изначальным предложением (был исключён файл inclusive-terminology.rst с рассказом о важности инклюзивного отношения и пояснением причин, по которым следует избегать проблемных терминов). Оставлены только изменения в документ, определяющий стиль кодирования. Разработчикам не рекомендуется использовать связки ‘master / slave’ и ‘blacklist / whitelist’, а также отдельно слово ‘slave’. Рекомендации касаются только нового использования данных терминов. Уже имеющиеся в ядре упоминания указанных слов останутся нетронутыми.

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

Слова ‘blacklist/whitelist’ рекомендуется заменять на ‘denylist / allowlist’ или ‘blocklist / passlist’, а вместо слов ‘master / slave’ предлагаются следующие варианты связок:

  • ‘{primary,main} / {secondary,replica,subordinate}’,
  • ‘{initiator,requester} / {target,responder}’,
  • ‘{controller,host} / {device,worker,proxy}’,
  • ‘leader / follower’,
  • ‘director / performer’.

С изменением согласились (Acked-by):

  • Randy Dunlap ‹rdunlap@infradead.org›
  • Dave Airlie ‹airlied@redhat.com›
  • SeongJae Park ‹sjpark@amazon.de›
  • Christian Brauner ‹christian.brauner@ubuntu.com›
  • James Bottomley ‹James.Bottomley@HansenPartnership.com›
  • Daniel Vetter ‹daniel.vetter@ffwll.ch›
  • Andy Lutomirski ‹luto@kernel.org›
  • Laura Abbott ‹laura@labbott.name›
  • Gustavo A. R. Silva ‹gustavoars@kernel.org›

Изменение рецензировали (Reviewed-by):

  • Matthias Brugger ‹matthias.bgg@gmail.com›
  • Mark Brown ‹broonie@kernel.org›

Изменение подписали (Signed-off-by):

  • Stephen Hemminger ‹stephen@networkplumber.org›
  • Theodore Ts’o ‹tytso@mit.edu›
  • Shuah Khan ‹skhan@linuxfoundation.org›
  • Dan Carpenter ‹dan.carpenter@oracle.com›
  • Kees Cook ‹keescook@chromium.org›
  • Olof Johansson ‹olof@lixom.net›
  • Jonathan Corbet ‹corbet@lwn.net›
  • Chris Mason ‹clm@fb.com›
  • Greg Kroah-Hartman ‹gregkh@linuxfoundation.org›
  • Dan Williams ‹dan.j.williams@intel.com›

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

Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа

Для PostgreSQL предложено дополнение AGE (AgensGraph-Extension) с реализацией языка запросов openCypher для манипуляций с наборами связанных между собой иерархических данных, образующих граф. Вместо столбцов и строк графо-ориентированые БД используют структуру, похожую на сеть — задаются узлы, их свойства и отношения между узлами. AGE распространяется под лицензией Apache 2.0, передан компанией Bitnine под покровительство Фонда Apache и в настоящее время помещён в инкубатор Apache.

Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQL. Ключевым отличием является реализация AGE в форме универсального дополнения, работающего в виде надстройки над штатными выпусками PostgreSQL. Опубликованный на днях выпуск Apache AGE 0.2.0 поддерживает работу с PostgreSQL 11.

В текущем состоянии AGE поддерживает такие возможности языка запросов Cypher, как применение выражения «CREATE» для определения узлов и связей, выражение «MATCH» для поиска данных в графе по заданным условиям (WHERE), в указанном порядке (ORDER BY) и с выставленными ограничениями (SKIP, LIMIT). Результирующий набор данных, возвращаемый запросом, определяется при помощи выражения «RETURN». Для объединения нескольких запросов в цепочку доступно выражение «WITH».

Возможно создание мультимодельных БД, сочетающих модели иерархического хранения свойств в форме графа, реляционную модель и модель хранения документов в формате JSON. Поддерживается выполнение интегрированных запросов, включающих элементы языков SQL и Cypher. Доступно создание индексов для свойств вершин и рёбер графа. Для использования предложен расширенный набор типов Agtype, включающий типы для рёбер, вершин и путей в графе. Агрегатные выражения пока не реализованы. Среди доступных специализированных функций: id, start_id, end_id, type, properties, head, last, length, size, startNode, endNode, timestamp, toBoolean, toFloat, toInteger и coalesce.

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

Предложение по обсуждению вопроса добавления в ядро Linux средств для разработки на языке Rust

Ник Десанье (Nick Desaulniers), занимающийся в Google обеспечением поддержки сборки ядра Linux с использованием компилятора Clang и также помогающий исправлять ошибки в компиляторе Rust, предложил провести на конференции Linux Plumbers Conference 2020 сессию для обсуждения предоставления возможности разработки компонентов ядра на языке Rust. Ник занимается проведением микро-конференции, посвящённой LLVM, и считает, что было бы неплохо обсудить технические аспекты возможной интеграции поддержки Rust в ядро (им уже подготовлен рабочий прототип для KBuild) и понять нужно ли вообще добавлять такую поддержку и какие ограничения по использованию Rust следует принять.

Напомним, что в недавней дискуссии на конференции «Open Source Summit and Embedded Linux» Линус Торвальдс не исключил появление привязок для разработки неосновных подсистем ядра (например, драйверов) на таких языках как Rust. Возможность разработки драйверов на языке Rust позволила бы с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера. Уже существует несколько сторонних проектов по реализации такой возможности:

  • Разработчики из компании «Fish in a Barrel» подготовили инструментарий для написания загружаемых модулей для ядра Linux на языке Rust, используя для повышения защиты набор абстрактных прослоек над интерфейсами и структурами ядра. Прослойки автоматически генерируются на базе имеющихся заголовочных файлов ядра при помощи утилиты bindgen. Для сборки прослоек используется Clang. Собираемые модули помимо прослоек используют пакет staticlib.
  • Исследователи из Китайского университета в Гонконге развивают проект для разработки на Rust драйверов для встраиваемых систем и устройств интернета вещей, который также использует bindgen для генерации прослоек на основе заголовочных файлов ядра. Фреймворк позволяет добиться повышения безопасности драйверов без внесения изменений в ядро — вместо создания в ядре дополнительных уровней изоляции для драйверов, предлагается блокировать проблемы на этапе компиляции, применяя более безопасный язык Rust. Предполагается, что подобный подход может оказаться востребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.
  • Разработчики фреймворка C2Rust для трансляции Си-кода на Rust, проводят эксперименты по преобразованию модулей ядра с минимальными ручными правками. Из проблем отмечается применение во многих частях ядра кода, в котором используются расширения GCC, пока не поддерживаемые в C2Rust. Для решения данной проблемы в C2Rust планируется добавить поддержку GCC атрибутов inline, cold, alias, used и section, а также расширить возможности inline-ассемблера и решить проблемы со структурами, которые одновременно выровнены и упакованы (например, xregs_state). Из существенных проблем, требующих ручной работы, отмечается невозможность транслировать нетривиальные Си-макросы в макросы Rust и необходимость переопределения типов, так как C2Rust транслирует Си-типы в определения в пакете libc, но этот пакет нельзя использовать в модулях ядра.

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

Выпуск P2P-платформы GNUnet 0.13. Продвижение GNS в качестве интернет-стандарта

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, начал процесс стандартизации системы доменных имён GNS (GNU Name System), развиваемой проектом GNUnet в качестве полностью децентрализованной и недоступной для цензуры замены DNS. В настоящий момент опубликован первый черновой вариант стандарта, после стабилизации которого будет сформирован RFC, имеющий статус «Предложенного стандарта».

GNS может применяться бок о бок с DNS и использоваться в традиционных приложениях, таких как web-браузеры. Целостность и неизменность записей обеспечивается за счёт использования криптографических механизмов. В отличие от DNS в GNS вместо древовидной иерархии серверов применяется направленный граф. Преобразование имён сходно с DNS, но запросы и ответы выполняются с сохранением конфиденциальности — обрабатывающий запрос узел не знает кому отдаётся ответ, а транзитные узлы и сторонние наблюдатели не могут расшифровать запросы и ответы.

DNS-зона в GNS определяется при помощи связки из открытого и закрытого ключей ECDSA на основе эллиптических кривых Curve25519. Использование Curve25519 воспринимается некоторыми как весьма странный шаг, так как для ECDSA применяют другие типы эллиптических кривых, а в паре с Curve25519 обычно используют алгоритм цифровых подписей Ed25519, более современный, более безопасный и более быстрый, чем ECDSA. С точки зрения криптостойкости также вызывает сомнение выбор размера ключа — 32 байта вместо 64 байт, обычно используемых для Ed25519, а также применение каскадного симметричного шифрования, используя алгоритмы AES и TwoFish в режиме CFB.

Подобный подход объясняется необходимостью реализации иерархических ключей, дающих возможность использовать корневой открытый ключ для извлечения дочернего открытого ключа, пользуясь свойством линейности кривой Curve25519. Данная особенность позволяет получать дочерние открытые ключи без знания закрытых корневых ключей. Указанная техника также применяется в Bitcoin. 32-байтовый размер ключа выбран для того чтобы ключ вмещался в одну запись DNS.

Дополнительно можно отметить новый выпуск фреймворка GNUnet 0.13, предназначенного для построения защищённых децентрализованных P2P-сетей. Создаваемые при помощи GNUnet сети не имеют единой точки отказа и способны гарантировать неприкосновенность частной информации пользователей, в том числе исключить возможные злоупотребления со стороны спецслужб и администраторов, имеющих доступ к узлам сети. Выпуск отмечен как содержащий значительные изменения протокола, нарушающие обратную совместимость с версиями 0.12.x.

GNUnet поддерживает создание P2P-сетей поверх TCP, UDP, HTTP/HTTPS, Bluetooth и WLAN, может работать в режиме F2F (Friend-to-friend). Поддерживается обход NAT, в том числе с использованием UPnP и ICMP. Для адресации размещения данных возможно использование распределённой хэш таблицы (DHT). Предоставляются средства для развёртывания mesh-сетей. Для выборочного предоставления и отзыва прав доступа применяется сервис децентрализованного обмена атрибутами идентификации reclaimID, использующий GNS (GNU Name System) и шифрование на основе атрибутов (Attribute-Based Encryption).

Система отличается низким потреблением ресурсов и использованием многопроцессной архитектуры для обеспечения изоляции между компонентами. Предоставляются гибкие средства для ведения логов и накопления статистики. Для разработки конечных приложений GNUnet предоставляет API для языка Си и биндинги для других языков программирования. Для упрощения разработки вместо потоков предлагается использовать циклы обработки событий (event loop) и процессы. В состав входит тестовая библиотека для автоматического развёртывания экспериментальных сетей, охватывающих десятки тысяч пиров.

Кроме GNS на базе технологий GNUnet также развивается несколько готовых приложений:

  • Сервис для анонимного обмена файлами, не позволяющий проанализировать информацию за счёт передачи данных только в зашифрованном виде и не дающий отследить кто разместил, искал и скачал файлы благодаря использованию протокола GAP.
  • Система VPN для создания скрытых сервисов в домене «.gnu» и проброса туннелей IPv4 и IPv6 поверх P2P-сети. Дополнительно поддерживаются схемы трансляции IPv4-в-IPv6 и IPv6-в-IPv4, а также создание туннелей IPv4-поверх-IPv6 и IPv6-поверх-IPv4.
  • Сервис GNUnet Conversation для совершения голосовых вызовов поверх GNUnet. Для идентификации пользователей используется GNS, содержимое голосового трафика передаётся в зашифрованном виде. Анонимность пока не предоставляется — другие пиры могут отследить соединение между двумя пользователями и определить их IP-адреса.
  • Платформа для построения децентрализованных социальных сетей Secushare, использующая протокол PSYC и поддерживающая распространение уведомлений в режиме multicast с применением end-to-end шифрования для того, чтобы доступ к сообщениям, файлам, чатам и обсуждениям могли получить только авторизированные пользователи (те кому сообщения не адресованы, включая администраторов узлов, не смогут их прочитать);
  • Система для организации шифрованной электронной почты pretty Easy privacy, применяющая GNUnet для защиты метаданных и поддерживающая различные криптографические протоколы для верификации ключей;
  • Платёжная система GNU Taler, предоставляющая анонимность для покупателей, но отслеживающая транзакции продавцов для обеспечения прозрачности и предоставления налоговой отчётности. Поддерживается работа с различными существующими валютами и электронными деньгами, в том числе с долларами, евро и биткоинами.

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

  • Введён в строй реестр GANA (GNUnet Assigned Numbers Authority), отвечающий за назначение имён и адресов для GNUnet.
  • Реализация децентрализованной системы доменных имён GNS приведена в соответствие со спецификацией, предложенной в IETF. Налажена работа NSS-плагина «block». Добавлены новые флаги SUPPLEMENTAL для записей, которые явно не опубликованы под заданной меткой, но возвращаются резолвером. В утилиту gnunet-namestore добавлен вывод предупреждения при добавлении записей TLSA или SRV вне записи BOX.
  • В механизме отзыва ключей (GNS/REVOCATION) функция доказательства выполненной работы переведена на использование алгоритма хэширования Argon2.
  • В сервисе децентрализованного обмена атрибутами идентификации (RECLAIM) размер тикета увеличен до 256 бит.
  • Транспортный плагин, использующий для передачи данных протокол UDP, перемещён в категорию экспериментальных из-за наличия проблем со стабильностью;
  • Формат файла ключей и метод сериализации закрытых ключей ECDSA унифицирован с другими библиотеками (старые ключи перестанут работать).
  • В качестве реализации алгоритмов шифрования на основе эллиптических кривых задействована библиотека libsodium.
  • Добавлена возможность сборки утилит с библиотекой cURL, не связанной с gnutls.
  • Возвращён сервер непрерывной интеграции Buildbot.
  • В сборочные зависимости включены библиотеки libmicrohttpd, libjansson и libsodium.

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

Google учредил организацию для управления торговыми марками открытых проектов

Компания Google учредила новую некоммерческую организацию «Open Usage Commons«, призванную защищать идентичность открытых проектов и оказывать помощь по управлению торговыми марками (название проекта и логотип), формированию правил по использованию торговых марок и проверке их выполнения. Целью организации является расширение философии и определения Open Source на торговые марки.

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

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

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

Для управления организацией и выработки критериев по принятию открытых проектов под свою опеку сформирован совет директоров, в который включены известные деятели сообщества и индустрии, такие как Кристофер ДиБон (Chris DiBona, управляющий Open Source проектами в Google), Майлз Ворд (Miles Ward, техдиректор SADA Systems), Эллисон Рэндал (Allison Randal, из Software Freedom Conservancy) и Клиф Лампе (Cliff Lampe, профессор из Мичиганского университета). Первыми проектами, присоединившимися к организации, стали платформа микросервисов Istio, web-фреймворк Angular и система рецензирования кода Gerrit.

Дополнение: Компания IBM выразила несогласие с действиями Google по передаче новой организации торговых марок проекта Istio, так как этот шаг нарушает ранее согласованные договорённости. Проект Istio является совместным и образован путём слияния проекта Istio от Google и Amalgam8 от IBM с оставлением общего имени Istio. При образовании совместного проекта было оговорено, что после достижения зрелости он будет передан под покровительство независимой от конкретных производителей некоммерческой организации Cloud Native Computing Foundation (CNCF), которая возьмёт в свои руки в том числе процессы управления лицензиями и торговыми марками. По мнению IBM новая организация Open Usage Commons (OUC) не соответствует принципам открытого управления, независимого от отдельных поставщиков (3 из 6 членов управляющего совета OUC нынешние или бывшие сотрудники Google).

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

Google и Canonical реализовали во Flutter возможность создания десктоп-приложений для Linux

Компании Google и Canonical выступили с совместной инициативой по обеспечению поддержки разработки графических приложений на основе фреймворка Flutter для настольных Linux-систем. Фреймворк построения интерфейса пользователя Flutter написан на языке Dart (runtime-движок для выполнения приложений написан на C++), позволяет создавать универсальные приложения, работающие на разных платформах, и рассматривается как альтернатива React Native.

Несмотря на наличие Flutter SDK для Linux, он до сих пор применялся только для разработки мобильных приложений и не поддерживал сборку десктоп-приложений для Linux. В прошлом году компания Google объявила о намерении добавить во Flutter возможность разработки полноценных настольных программ и представила альфа-выпуск для разработки таких программ для macOS. Теперь Flutter расширен возможностью разрабатывать десктоп-приложения для Linux. Поддержка разработки приложений для Windows пока находится на стадии начального прототипа.

Для отрисовки интерфейса в Linux используется обвязка на основе библиотеки GTK (поддержку Qt и других тулкитов обещают добавить позднее). Помимо родного для Flutter языка Dart, на котором создаются виджеты, приложения могут использовать интерфейс Dart Foreign Function для вызова кода на C/C++ и обращаться ко всем возможностям платформы Linux.

Поддержка разработки приложений для Linux предложена в свежем альфа-выпуске Flutter SDK, в котором также реализована возможность публикации Linix-приложений в каталоге Snap Store. В формате snap можно найти и сборку самого Flutter SDK. Для разработки приложений на базе Flutter предлагается использовать редактор кода Visual Studio Code или среды разработки IntelliJ и Android Studio.

В качестве примера Linux-программ на базе Flutter предложено приложение Flokk Contacts для работы с адресной книгой Google Contacts. В каталоге pub.dev опубликовано три Flutter-плагина с поддержкой Linux: url_launcher для открытия URL в браузере по умолчанию, shared_preferences для сохранения настроек между сеансами и path_provider для определения типовых каталогов (загрузки, изображения, видео и т.п.)

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

Выпуск SFTP-сервера SFTPGo 1.0

Состоялся первый значительный выпуск сервера SFTPGo 1.0, позволяющего организовать удалённый доступ к файлам при помощи протоколов SFTP, SCP/SSH и Rsync. В том числе SFTPGo может использоваться для предоставления доступа к Git-репозиториям, используя протокол SSH. Данные могут отдаваться как с локальной файловой системы, так и из внешних хранилищ, совместимых с Amazon S3 и Google Cloud Storage. Для хранения пользовательской базы и метаданных используются СУБД с поддержкой SQL или формата ключ/значение, такие как PostgreSQL 9.4+, MySQL 5.6+, SQLite 3.x или bbolt 1.3.x. Имеется также режим хранения метаданных в оперативной памяти, не требующий подключения внешней БД. Код проекта написан на языке Go и распространяется под лицензией GPLv3.

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

  • Для каждой учётной записи применяется chroot-изоляция, ограничивающая доступ домашним каталогом пользователя. Возможно создания виртуальных каталогов, ссылающихся на данные вне пользовательского домашнего каталога.
  • Учётные записи хранятся в виртуальной базе пользователей, не пересекающейся с системной БД пользователей. Для хранения БД пользователей могут применяться SQLite, MySQL, PostgreSQL, bbolt и хранение в памяти. Предоставляются средства для сопоставления виртуальных и системных учётных записей — возможно прямое или произвольное сопоставление (один системный пользователь может быть сопоставлен с другим виртуальным пользователем).
  • Поддерживается аутентификация по открытым ключам, ключам SSH и паролям (в том числе интерактивная аутентификация с вводом пароля с клавиатуры). Возможна привязка нескольких ключей для каждого пользователя, а также настройка мультифакторной и многоэтапной аутентификации (например, в случае успешной аутентификации по ключу может дополнительно быть запрошен пароль).
  • Для каждого пользователя возможна настройка разных методов аутентификации, а также определение собственных методов, реализуемых через вызов внешних программ-аутентификаторов (например, для аутентификации через LDAP) или отправку запросов через HTTP API.
  • Возможно подключение внешних обработчиков или вызовов HTTP API для динамического изменения параметров пользователя, вызываемых перед входом пользователя. Поддерживается динамическое создание пользователей при подключении.
  • Поддержка индивидуальных квот на размер данных и число файлов.
  • Поддержка ограничения пропускной способности с раздельной настройкой ограничений для входящего и исходящего трафика, а также ограничений на число одновременных подключений.
  • Средства разграничения доступа, действующие в привязке к пользователю или каталогу (можно ограничить просмотр списка файлов, запретить загрузку, скачивание, перезапись, удаление, переименование или изменение прав доступа, запретить создание каталогов или символических ссылок и т.п.).
  • Для каждого пользователя можно определить индивидуальные сетевые ограничения, например, можно разрешить вход только с определённых IP или подсетей.
  • Поддерживается подключение фильтров загружаемого контента в привязке к отдельным пользователям и каталогам (например, можно блокировать загрузку файлов с определённым расширением).
  • Возможна привязка обработчиков, запускаемых при различных операциях с файлом (загрузка, удаление, переименование и т.п.). Кроме вызова обработчиков поддерживается отправка уведомлений в форме HTTP-запросов.
  • Автоматическое завершение неактивных соединений.
  • Атомарное обновление конфигурации без разрыва соединений.
  • Предоставление метрик для мониторинга в Prometheus.
  • Поддерживается протокол HAProxy PROXY для организации балансировки нагрузки или проксирования соединений к сервисам SFTP/SCP без потери сведений об исходном IP-адресе пользователя.
  • REST API для управления пользователями и каталогами, создания резервных копий и формирования отчётов об активных соединениях.
  • Web-интерфейс (http://127.0.0.1:8080/web) для настройки и мониторинга (поддерживается и настройка через обычные файлы конфигурации).
  • Возможность определения настроек в форматах JSON, TOML, YAML, HCL и envfile.
  • Поддержка подключения по SSH с ограниченным доступом к системным командам. Например, разрешён запуск команд, необходимых для работы Git (git-receive-pack, git-upload-pack, git-upload-archive) и rsync, а также нескольких встроенных команд (scp, md5sum, sha*sum, cd, pwd, sftpgo-copy и sftpgo-remove).
  • Режим portable для совместного использования одного общего каталога с автоматической генерацией учётных данных для подключения, анонсируемых через multicast DNS.
  • Встроенная система профилирования для анализа производительности.
  • Упрощённый процесс миграции системных учётных записей Linux.
  • Хранение логов в формате JSON.

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