Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Dan Williams официально объявил, что NetworkManager полностью перешел с использования устаревшей библиотеки dbus-glib на современную альтернативу - GDBus. Задача решена в основном усилиями уже известного вам Dan Winship. Для подавляющего большинства пользователей изменение будет незаметно. К сожалению, некоторые legacy-апплеты потребуется переделать. Для этого разработчики предлагают использовать библиотеку libnm, которую как раз и создали на этот случай. В процессе перевода некоторых компонентов на использование libnm, удалось заметно сократить их кодовую базу, заодно приобретя юнит-тесты, сократив цепочку зависимостей, и полагаясь на более правильный API.

В последнее время NetworkManager быстро разрабатывается, получая все новые и новые десктопные функции. Появился улучшенный поиск Wi-Fi сетей, реализована улучшенная защита от отслеживания в Wi-Fi сетях (рандомизация MAC-адреса при сканировании). Последняя фича тоже была подсмотрена нашими коллегами у лидеров по юзабилити, придумавших не один хитрый трюк, у компании Apple. Кстати, помните, как они сумели добиться получения DHCP-адреса менее, чем за секунду, а наши коллеги потом разработали свой вариант, превзошедший решение Apple?

Так же нужно отметить долгожданное появление т.н. "Airplane mode" - это уже не NetworkManager, но функционал был давно ожидаемый. Вокруг стабилизирующейся платформы рабочего окружения в Linux тоже начали появляться интересные проекты - например, появилась возможность экспортировать настройки NetworkManager в виде QR-кода. Было сложно скопировать настройки с вашего компьютера на телефон? Теперь это элементарно! Надо лишь знать Python.

Как все знают, недавно было совершено открытие мирового значения - международная группа ученых на деньги США сумела провести эксперимент, доказавший существование гравитационных волн. Эксперимент велся с использованием большого количества открытого ПО, включающего не только готовые компоненты и существующие платформы (пересборки RHEL), но и самописное ПО. Наш коллега, инженер Red Hat, Zeeshan Ali, с большой гордостью отмечает, что GStreamer использовался, как фреймворк для создания системы обработки научных данных.

Наш коллега, участник проекта Fedora и разработчик Bitcoin, Jeff Garzik, объявил о новом биткойн-проекте - Bloq. В его рамках он предлагает услуги заказной разработки технологий на базе блокчейна и услуги техподдержки. За модель он взял Red Hat, которая предлагает примерно то же самое, но не для биткойна.

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


Владелец частной космической компании рассказывает о том, как обстоят дела с аварийностью пусков

Вообще, денег конкретно на Bitcoin стали выделять меньше. А вот blockchain наоборот испытывает подъем интереса. Пока в РФ его собираются запретить, ряд ведущих финансовых институтов и компаний-разработчиков создает свой глобальный "биткойн" для государств и финансовых компаний, лишенный опасной для простого человека свободы, открытости и расширяемости, и подконтрольный ответственным людям, а не какому-то там "коммьюнити". Обещают скоро выложить какие-то исходники на GitHub.

Если серьезно, то мы начинаем понимать, почему представители крупного бизнеса не очень горят желанием использовать уже существующую реализацию блокчейна (Bitcoin). Дело даже не в технических, а в социальных моментах. Сообщество Bitcoin, как оказалось, это причудливая смесь из криптоанархистов с одной стороны и control freak-ов, прямо как из порнографических BDSM-фильмов, с другой. Посередине есть немного обычных людей - стартаперов и энтузиастов технологии. Например, есть объяснение тому, почему в Bitcoin нельзя использовать system-wide библиотеки. С их т.з. нелегально пересобранный Bitcoin-клиент может разрушить сеть, и поэтому они хотят контролировать сборку клиентов, которыми подключаются к этой сети свободных транзакций. Собственно, это и есть причина, почему официального Bitcoin-клиента все еще нет в Fedora, и почему возникли проблемы у ряда альтернативных клиентов, написанных, например, на Erlang. Мы не задаемся вопросом, что же это за сарай они спроектировали, который может обвалить неправильно собранное клиентское приложение - тут высшая математика и мудреная криптография, которая, как они говорят, недоступна всякому плебсу, но зато прекрасно понимаем, почему крупный банкинг технологию blockchain изучает и пробует внедрять кастомизированные реализации, а вот сам Bitcoin использовать не спешит.

Инженеры Red Hat и Google обнаружили, что ошибка переполнения буфера в резолвере Glibc, о которой сообщили полгода назад, действительно является ошибкой переполнения буфера. Ну, бывает, что.

Проблема человеческим языком объясняется на OpenNET.ru, а если хочется по-технически, то наш коллега, Carlos O'Donell, подробно разъяснил печальность происходящего. Специалисты Google уже предложили пример использования этой уязвимости, с необходимыми пояснениями. Для эксплуатации уязвимости многого не нужно. Например, на своем домене поднимите DNS, и выложите где-нибудь на линуксовом сайте ссылку, да так, чтобы запрос прошел через ваш DNS - вот и все! Коллеги-аналитики также заметили, что по умолчанию SSH постоянно что-то резолвит в обратную сторону (порой эту функцию отключают, т.к. тормозит соединение при неправильно настроенных DNS, но могут и не отключать) - можно и тут придумать что-нибудь. Ну и куча десктопного ПО постоянно резолвит домены - от почтовиков, до торрент-клиентов и ПО для Bitcoin. Так что получилась очень кудрявая уязвимость.

Проблему легко было бы исправить правильно настроенным локальным DNS-резолвером, к которому (и только к которому) и обращалась бы функция в Glibc, но даже в Fedora такая фича постоянно переносится с релиза на релиз. Последний раз ее планировали включить в Fedora 22, а теперь перенесли на Fedora 24. Архитектурно оказалось слишком хрупко, и тут мы ждем помощи от разработчиков systemd с их networkd и resolved. А вы думали, они просто так компоненты интегрируют в систему?

Upd: коллеги-аналитики подсказали, что Android в безопасности, т.к. там не используется Glibc.