Утверждённые в этом году исключения разрешают установку альтернативных прошивок на маршрутизаторы и другие сетевые устройства (в том числе совершая jailbreak и обходя привязки к прошивкам с DRM). Исключение даёт пользователю возможность продлить жизненный цикл своего устройства после истечения срока поддержки производителем, установив альтернативную прошивку, такую как OpenWrt.

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

Ранее действующие исключения, связанные с разрешением разблокирования, смены прошивки, ремонта и установки приложений, независимо от того одобрены они производителем или нет, ранее действующие для смартфонов (jailbreak), планшетов и прочих мобильных устройств, расширены в отношении возможности замены программной начинки умных телевизоров.

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

Продлены исключения, связанные дешифровкой материалов c DVD, Blu-Ray и online-сервисов, которые используются для составления ремиксов с включением в них отдельных отрывков видео. Из действия DMCA также выведены компьютерные игры и игровые консоли, производители которых прекратили поддержку своих продуктов (любители компьютерных игр могут легально вносить изменения в старые игровые приложения и прошивки игровых консолей для обхода привязок к внешним игровым сервисам и серверам аутентификации). Продлены исключения, позволяющие использовать альтернативные материалы в 3D-принтерах.

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

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

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

HTTPS защищает передаваемые данные на этапе передачи по сети, но не может исключить нарушение их целостности в результате атак на сервер. Изолированные анклавы, создаваемые при помощи таких технологий, как Intel SGX (Software Guard Extension), ARM TrustZone и AMD PSP (Platform Security Processor), дают возможность защитить важные вычисления и снизить риск утечек или изменения конфиденциальной информации на конечном узле.

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

Помимо штатного для HTTPS процесса установки защищённого соединения, HTTPA дополнительно требует согласования сессионного ключа, заслуживающего доверия. Протокол вводит в обиход новый HTTP-метод «ATTEST», который позволяет обрабатывать три типа запросов и ответов:

«preflight» для проверки, поддерживает ли удалённая сторона аттестацию анклавов;
«attest» для согласования параметров аттестации (выбор криптографического алгоритма, обмен уникальными для сеанса случайными последовательностями, генерация идентификатора сеанса и передача клиенту открытого ключа анклава);
«trusted session» — формирование сессионного ключа для доверительного обмена информацией. Сессионный ключ формируется на основе ранее согласованной предварительной секретной последовательности (pre-session secret), сформированной клиентом с использованием полученного от сервера открытого ключа TEE, и сгенерированных каждой стороной случайных последовательностей.

HTTPA подразумевает, что клиент заслуживает доверия, а сервер нет, т. е. клиент может использовать данный протокол для верификации вычислений в TEE-окружении. При этом HTTPA не гарантирует, что производимые в процессе работы web-сервера остальные вычисления, производимые не в TEE, не были скомпрометированы, что требует применения отдельного подхода к разработке web-сервисов. Таким образом, в основном HTTPA нацелен на использование со специализированными сервисами, к которым предъявляются повышенные требования к целостности информации, такие как финансовые и медицинские системы.

Для ситуаций когда вычисления в TEE должны быть подтверждены как для сервера, так и для клиента предусмотрен вариант протокола mHTTPA (Mutual HTTPA), выполняющий двухстороннюю верификацию. Данный вариант более усложнённый из-за необходимости двустороннего формирования сессионных ключей для сервера и клиента.

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

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

Протокол GPS предусматривает наличие счётчика недель, отсчитывающего недели начиная с 5 января 1980 года. Проблема в том, что при вещании под данный счётчик отводится всего 10 бит, что подразумевает его переполнение через каждые 1023 недели (19.7 лет). Первое переполнение произошло в 1999 году, второе в 2019, а третье произойдёт в 2038 году. Данные события отслеживаются производителями и для них предусмотрены специальные обработчики. В настоящее время параллельно внедрён новый формат GPS-сообщений (CNAV), в котором для счётчика отводится 13 бит (т. е. переполнение ожидается только в 2137 году).

В GPSD в логике корректировки появления лишней секунды (добавляется с целью синхронизации эталонных мировых атомных часов с астрономическим временем Земли) была допущена ошибка из-за которой 24 октября 2021 года преждевременно будет произведено вычитание 1024 из счётчика числа недель. По задумке автора кода сдвиг должен был произойти 31 декабря 2022 года, но перевод этой даты в число недель был выполнен не верно и фактически приведённое в проверке число недель подпадало под октябрь 2021 года (указано значение 2180 вместо 2600).

/* sanity check week number, GPS epoch, against leap seconds
     * Does not work well with regressions because the leap_sconds
     * could be from the receiver, or from BUILD_LEAPSECONDS. */
    if (0 < session->context->leap_seconds &&
        19 > session->context->leap_seconds &&
        2180 < week) {
        /* assume leap second = 19 by 31 Dec 2022
         * so week > 2180 is way in the future, do not allow it */
        week -= 1024;
        GPSD_LOG(LOG_WARN, &session->context->errout,
                 "GPS week confusion. Adjusted week %u for leap %d\n",
                 week, session->context->leap_seconds);
    }

По сути лицензия является пермиссивной и близка к лицензии MIT, но создана с оглядкой на российское законодательство и гораздо более многословна. Условия лицензии содержат множество уточнений, и без того следующих из законодательства РФ. В то же время в лицензии присутствуют спорные моменты в части определений. Так, исходный код определяется как «программа для ЭВМ в форме текста на языке программирования, который может быть прочтён человеком», что не обязательно подразумевает возможность получения из него исполняемого кода, а также то, что этот код не является сгенерированным на базе настоящего исходного кода (то есть кода в предпочтительной форме для внесения изменений).

Лицензия разрешает использовать программу или её части в любых не запрещённых законодательством РФ целях, а также изучать, перерабатывать и распространять копии программы и своей изменённой версии. Лицензия не требует распространять производную программу на условиях той же лицензии. В тексте также достаточно подробно раскрыты вопросы освобождения от ответственности — ни одна из сторон лицензионного соглашения не вправе требовать от другой стороны возмещения убытков, в том числе вызванных возможными недостатками или ошибками программы, а лицензиар не обязан исправлять недостатки или ошибки.

Примечательно, что в пояснительном тексте указана версия лицензии 1.0, в то время как текст лицензии имеет версию 1.1. Вероятно, это указывает на то, что лицензия дорабатывалась наспех.

Ubuntu Frame можно использовать для запуска приложений на базе  GTK,  Qt,  Flutter и  SDL2, а также программ на базе Java, HTML5 и Electron. Возможен запуск как приложений, собранных с поддержкой Wayland, так и программ на базе протокола  X11 (используется Xwayland). Для организации работы в Ubuntu Frame с отдельными web-страницами или сайтами развивается программа Electron Wayland с реализацией специализированного полноэкранного web-браузера, а также порт движка WPE WebKit. Для быстрой подготовки и развёртывания решений на основе Ubuntu Frame предлагается использовать пакеты в формате snap, при помощи которых организована изоляция запускаемых программ от остальной системы.

Оболочка Ubuntu Frame адаптирована для работы поверх системного окружения  Ubuntu Core, компактного варианта дистрибутива Ubuntu, поставляемого в форме неделимого монолитного образа базовой системы, в котором не применяется разбивка на отдельные deb-пакеты и используется механизм атомарного обновления всей системы. Компоненты Ubuntu Core, включая базовую систему, ядро Linux, системные надстройки и дополнительные приложения, поставляются в формате snap и управляются инструментарием snapd. Компоненты в формате Span изолируются при помощи AppArmor и Seccomp, что создаёт дополнительный рубеж для защиты системы в случае компрометации отдельных приложений. Базовая файловая система монтируется в режиме только для чтения.

Для создания кастомизированного киоска, ограниченного работой одного приложения, разработчику достаточно подготовить само приложение, а все остальные задачи по поддержке оборудования, поддержанию системы в актуальном состоянии и организации взаимодействия с пользователем берут на себя Ubuntu Core и Ubuntu Frame, включая поддержку управления при помощи экранных жестов на системах с сенсорными экранами. Заявлено, что обновления с устранением ошибок и уязвимостей в выпусках Ubuntu Frame будут формироваться в течение 10 лет. При желании оболочку можно запустить не только в Ubuntu Core, но и в любом дистрибутиве Linux с поддержкой пакетов Snap. В простейшем случае для развёртывания web-киоска достаточно установить и запустить пакет ubuntu-frame и настроить несколько параметров конфигурации:

snap install ubuntu-frame
snap install wpe-webkit-mir-kiosk
snap set wpe-webkit-mir-kiosk daemon=true
snap set ubuntu-frame daemon=true
snap set wpe-webkit-mir-kiosk url=https://example.com

Из возможностей ksmbd выделяется улучшенная поддержка технологии распределённого кэширования файлов (SMB leases) на локальных системах, которая позволяет существенно сократить трафик. В дальнейшем планируется добавление новых возможностей, таких как поддержка RDMA («smbdirect»), а также расширений протокола, связанных с усилением надёжности шифрования и верификацией по цифровым подписям. Отмечается, что подобные расширения гораздо проще реализовать в компактном и хорошо оптимизированном сервере, работающем на уровне ядра, чем в пакете Samba.

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

Ksmbd рассматривается не как отдельный продукт, а скорее как высокопроизводительное и готовое для применения на встраиваемых устройствах расширение к Samba, при необходимости интегрируемое с инструментами и библиотеками Samba. Например, с разработчиками Samba уже согласован вопрос использования в ksmbd совместимых с smbd файлов конфигурации и расширенных атрибутов (xattrs), что упростит переход с smbd на ksmbd и наоборот.

Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией. Впоследствии, когда Linux стал известным проектом, недоброжелатели пытались обвинить Линуса в прямом копировании кода некоторых подсистем MINIX. Нападение отразил Эндрю Таненбаум, автор MINIX, который поручил одному из студентов провести детальное сравнение кода Minix и первых публичных версий Linux. Результаты исследования показали наличие только четырёх несущественных совпадений блоков кода, обусловленных требованиями POSIX и ANSI C.

Первоначально Линус задумал назвать ядро Freax, от слов «free», «freak» и X (Unix). Но имя «Linux» ядро получило с лёгкой руки Ари Лемке (Ari Lemmke), который по просьбе Линуса разместил ядро на FTP-сервере университета, назвав директорию с архивом не «freax», как просил Торвальдс, а «linux». Примечательно, что предприимчивый делец Вильям Делло Крок (William Della Croce) сумел зарегистрировать торговую марку Linux и хотел со временем собирать отчисления, но позднее передумал и передал все права на торговую марку Линусу. Официальный талисман Linux-ядра, пингвин Tux, был выбран в результате соревнования, состоявшегося в 1996 году. Имя Tux расшифровывается как Torvalds UniX.

Динамика роста кодовой базы (количество строк исходного кода) ядра:

0.0.1 — сентябрь 1991, 10 тыс. строк кода;
1.0.0 — март 1994, 176 тыс. строк кода;
1.2.0 — март 1995, 311 тыс. строк кода;
2.0.0 — июнь 1996, 778 тыс. строк кода;
2.2.0 — январь 1999, 1.8 млн. строк кода;
2.4.0 — январь 2001, 3.4 млн. строк кода;
2.6.0 — декабрь 2003, 5.9 млн. строк кода;
2.6.28 — декабрь 2008, 10.2 млн. строк кода;
2.6.35 — август 2010, 13.4 млн. строк кода;
3.0 — август 2011, 14.6 млн. строк кода.
3.5 — июль 2012, 15.5 млн. строк кода.
3.10 — июль 2013, 15.8 млн. строк кода;
3.16 — август 2014, 17.5 млн. строк кода;
4.1 — июнь 2015, 19.5 млн. строк кода;
4.7 — июль 2016, 21.7 млн. строк кода;
4.12 — июль 2017, 24.1 млн. строк кода;
4.18 — август 2018, 25.3 млн. строк кода.
5.2 — июль 2019, 26.55 млн. строк кода.
5.8 — август 2020, 28.4 млн. строк кода.
5.13 — июнь 2021, 29.2 млн. строк кода.

Прогресс развития ядра:

Linux 0.0.1 — сентябрь 1991, первый публичный выпуск, поддерживающий только CPU i386 и загружающийся с дискеты;
Linux 0.12 — январь 1992, код начал распространяться под лицензией GPLv2;
Linux 0.95 — март 1992, обеспечена возможность запуска X Window System, реализована поддержка виртуальной памяти и раздела подкачки.
Linux 0.96-0.99 — 1992-1993, началась работа над сетевым стеком. Представлена файловая система Ext2, добавлена поддержка формата файлов ELF, представлены драйверы для звуковых карт и контроллеров SCSI, реализована загрузка модулей ядра и файловой системы /proc.
В 1992 году появились первые дистрибутивы SLS и Yggdrasil. Летом 1993 года были основаны проекты Slackware и Debian.
Linux 1.0 — март 1994, первый официально стабильный релиз;
Linux 1.2 — март 1995, существенное увеличение числа драйверов, поддержка платформ Alpha, MIPS и SPARC, расширение возможностей сетевого стека, появление пакетного фильтра, поддержка NFS;
Linux 2.0 — июнь 1996 года, поддержка многопроцессорных систем;
Март 1997: основан LKML, список рассылки разработчиков ядра Linux;
1998 год: запущен первый попавший в список Top500 кластер на базе Linux, состоящий из 68 узлов с CPU Alpha;
Linux 2.2 — январь 1999, увеличена эффективность системы управления памятью, добавлена поддержка IPv6, реализован новый межсетевой экран, представлена новая звуковая подсистема;
Linux 2.4 — февраль 2001, обеспечена поддержка 8-процессорных систем и 64 Гб ОЗУ, файловая система Ext3, поддержка USB, ACPI;
Linux 2.6 — декабрь 2003, поддержка SELinux, средства автоматического тюнинга параметров ядра, sysfs, переработанная система управления памятью;
В 2005 году представлен гипервизор Xen, который открыл эру виртуализации;
В сентябре 2008 года сформирован первый релиз платформы Android, основанной на ядре Linux;
В июле 2011 года после 10 лет развития ветки 2.6.x осуществлён переход к нумерации 3.x. Число объектов в Git-репозитории достигло 2 млн;
В 2015 году состоялся выпуск ядра Linux 4.0. Число git-объектов в репозитории достигло 4 млн;
В апреле 2018 года преодолён рубеж в 6 млн git-объектов в репозитории ядра.
В январе 2019 года сформирована ветка ядра Linux 5.0. Репозиторий достиг уровня 6.5 млн git-объектов.
Опубликованное в августе 2020 года ядро 5.8 стало самым крупным по числу изменений из всех ядер за всё время существования проекта.
В ядре 5.13 был поставлен рекорд по числу разработчиков (2150), изменения от которых вошли в состав ядра.
В 2021 году в ветку ядра Linux-next добавлен код для разработки драйверов на языке Rust. Ведётся работа по включению компонентов для поддержки Rust в основной состав ядра.
68% всех изменений в ядро внесены 20 наиболее активными компаниями. Например, при разработке ядра 5.13 10% всех изменений подготовлено компанией Intel, 6.5% — Huawei, 5.9% — Red Hat, 5.7% — Linaro, 4.9% — Google, 4.8% — AMD, 3.1% — NVIDIA, 2.8% — Facebook, 2.3% — SUSE, 2.1% — IBM, 1.9% — Oracle, 1.5% — ARM, 1.4% — Canonical. 13.2% изменений подготовлены независимым участниками или разработчиками, явно не заявившим о своей работе на определённые компании. 1.3% изменений подготовлены студентами, аспирантами и представителями учебных заведений. По числу добавленных в ядро 5.13 строк кода лидирует компания AMD, доля которой составила 20.2% (драйвер amdgpu насчитывает около 3 млн строк кода, что примерно 10% от общего размера ядра — 2.4 млн строк приходится на сгенерированные автоматически заголовочные файлы с данными для регистров GPU).

App Bundle поддерживается начиная с Android 9 и позволяет сформировать набор, включающий всё, что нужно приложению для работы на любом устройстве — языковые наборы, поддержка разных размеров экрана и сборки для различных аппаратных платформ. При загрузке приложения из Google Play на систему пользователя доставляются только код и ресурсы, необходимые для работы на конкретном устройстве. Для разработчика приложения переход на App Bundle как правило сводится к включению другой сборочной опции в настройках и тестированию получившегося AAB-пакета.

По сравнению с загрузкой монолитных пакетов APK использование App Bundle позволяет в среднем на 15% сократить объём загружаемых на систему пользователя данных, что приводит к экономии места на накопителе и ускорению установки приложений. По данным Google в настоящее время уже около миллиона приложений перешло на использование формата App Bundle, включая приложения Adobe, Duolingo, Gameloft, Netflix, redBus, Riafy и Twitter.

Источники:
OpenNet
GoogleBlog Android