Выпуск Tinygo 0.7.0, компилятора языка Go на базе LLVM

Доступен выпуск проекта Tinygo 0.7.0, в рамках которого развивается компилятор языка Go для областей, в которых необходимо компактное представление результирующего кода и низкое потребление ресурсов, таких как микроконтроллеры и компактные однопроцессорные системы. Код распространяется под лицензией BSD.

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

Мотивом создания нового проекта послужило желание использовать привычный для себя язык Go на компактных устройствах — разработчики рассудили, что если существует вариант Python для микроконтроллеров, то почему бы не создать подобное для языка Go. Go выбран вместо Rust так как он более прост в изучении, предоставляет независимую от реализаций потоков поддержку распараллеливания на основе сопрограмм и предлагает обширную стандартную библиотеку («батарейки входят в комплект»).

В текущем виде поддерживается 15 моделей микроконтроллеров, включая различные платы Adafruit, Arduino, BBC micro:bit, ST Micro, Digispark, Nordic Semiconductor, Makerdiary и Phytec. Программы также могут быть собраны для запуска в браузере в формате WebAssembly и в виде исполняемых файлов для Linux.

Ключевые цели проекта:

  • Генерация очень компактных исполняемых файлов;
  • Поддержка наиболее распространённых моделей плат микроконтроллеров;
  • Возможность применения для Web;
  • Поддержка CGo с минимальными накладными расходами при вызове функций на языке Си;
  • Поддержка большей части стандартных пакетов и возможность компиляции типового существующего кода без его изменения.

    Не входит в число основных целей поддержка многоядерных систем, эффективный запуск огромного числа сопрограмм (сам по себе запуск сопрограмм поддерживается в полной мере), достижение уровня производительности эталонного компилятора gc (оптимизация отдаётся на откуп LLVM и в некоторых применениях Tinygo может оказаться быстрее gc) и полная совместимость со всеми приложениями на Go.

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

    Из изменений в выпуске 0.7 отмечается реализация команды «tinygo test», обеспечение поддержки сборки мусора для большинства целевых плат (на базе ARM Cortex-M) и WebAssembly, поддержка платы HiFive1 rev B на основе архитектуры RISC-V и платы Arduino nano33, улучшение поддержки языка (поддержка битовых полей с использованием геттеров и сеттеров, поддержка анонимных структур).

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

  • В Казахстане ряд крупных провайдеров внедрил перехват HTTPS-трафика

    В соответствии с действующими в Казахстане с 2016 года поправками к закону «О связи», многие казахские провайдеры, включая Kcell, Beeline, Tele2 и Altel, с сегодняшнего дня ввели в строй системы перехвата HTTPS-трафика клиентов с подменой изначально используемого сертификата. Изначально систему перехвата планировалось внедрить в 2016 году, но это операция постоянно откладывалась и закон уже стал восприниматься как формальный. Перехват осуществляется под видом заботы о безопасности пользователей и желания оградить их от предоставляющего угрозу контента.

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

    При установке TLS-соединения реальный сертификат целевого сайта подменяется сгенерированным на лету новым сертификатом, который будет помечен браузером как достоверный, если «национальный сертификат безопасности» был добавлен пользователем в хранилище корневых сертификатов, так как подставной сертификат связан цепочкой доверия с «национальным сертификатом безопасности».

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

    Разработчики браузеров рассматривают предложение добавить применяемый для перехвата корневой сертификат в список отозванных сертификатов (OneCRL), как недавно Mozlla поступила с сертификатами удостоверяющего центра DarkMatter. Но смысл такой операции не совсем ясен (в прошлых обсуждениях его посчитали бесполезным), так как в случае с «национальным сертификатом безопасности» этот сертификат изначально не охвачен цепочками доверия и без установки сертификата пользователем браузеры и так выводят предупреждение. С другой стороны, отсутствие реакции со стороны производителей браузеров может стимулировать внедрение подобных систем в других странах. В качестве варианта предлагается также реализовать новый индикатор для локально установленных сертификатов, уличённых в MITM-атаках.

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

    Уязвимость в прошивках BMC-контроллеров, затрагивающая серверы многих производителей

    Компания Eclypsium выявила две уязвимости в прошивках BMC-контроллера, поставляемого в серверах Lenovo ThinkServer, позволяющие локальному пользователю подменить прошивку или выполнить произвольный код на стороне чипа BMC.

    Дальнейший разбор показал, что данные проблемы затрагивают и прошивки BMC-контроллеров, применяемые в серверных платформах Gigabyte Enterprise Servers, которые также используются в серверах таких компаний, как Acer, AMAX, Bigtera, Ciara, Penguin Computing и sysGen. В проблемных BMC-контроллерах применялись уязвимые прошивки MergePoint EMS, разработанные сторонним поставщиком Avocent (в настоящее время является подразделением компании Vertiv).

    Первая уязвимость вызвана отсутствием криптографической верификации загружаемых обновлений прошивки (используется только проверка контрольной суммы CRC32, вопреки рекомендации NIST использовать цифровые подписи), что позволяет атакующему, имеющему локальный доступ к системе, подменить прошивку BMC. Проблема, например, может быть использована для глубокой интеграции руткита, остающегося активным после переустановки операционной системы и блокирующего дальнейшие обновления прошивки (для устранения руткита потребуется применение программатора для перезаписи SPI flash).

    Вторая уязвимость присутствует в коде обновления прошивки и позволяет осуществить подстановку своих команд, которые будут выполнены в BMC c наивысшим уровнем привилегий. Для атаки достаточно изменить значение параметра RemoteFirmwareImageFilePath в файле конфигурации bmcfwu.cfg, через который определяется путь к образу обновляемой прошивки. Во время очередного обновления, которое можно инициировать командой в IPMI, данный параметр будет обработан BMC и использован в составе вызова popen() как часть строки для /bin/sh. Так как строка для формирования shell-команды создаётся с применением вызова snprintf() без должной чистки спецсимволов, атакующие могут подставить свой код для выполнения. Для эксплуатации уязвимости требуется наличие прав, позволяющих отправить через IPMI команду контроллеру BMC (при наличии права администратора на сервере можно отправить команду IPMI без дополнительной аутентификации).

    Компании Gigabyte и Lenovo были оповещены о проблемах ещё в июле 2018 года и успели выпустить обновления до публичного раскрытия сведений. Компания Lenovo выпустила обновления прошивок 15 ноября 2018 года для серверов ThinkServer RD340, TD340, RD440, RD540 и RD640, но устранила в них только уязвимость, позволяющую осуществить подстановку команд, так как во время создания линейки серверов на базе MergePoint EMS в 2014 году верификация прошивок по цифровой подписи ещё не была широко распространена и изначально не заявлялась.

    8 мая этого года компания Gigabyte выпустила обновления прошивок для материнских плат с контроллером ASPEED AST2500, но как и Lenovo устранила только уязвимость, связанную с подстановкой команд. Уязвимые платы на базе ASPEED AST2400 пока остаются без обновления. Gigabyte также заявил о переходе на использование прошивок MegaRAC SP-X от компании AMI. В том числе новые прошивки на базе MegaRAC SP-X будут предложены для систем, ранее поставлявшихся с прошивками MergePoint EMS. Решение принято после заявления Vertiv о прекращении поддержки платформы MergePoint EMS. При этом об обновлении прошивок на серверах, выпускаемых компаниями Acer, AMAX, Bigtera, Ciara, Penguin Computing и sysGen на базе плат Gigabyte и оснащённых уязвимыми прошивками MergePoint EMS пока ничего не сообщается.

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

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

    Возобновление работы по интеграции поддержки Tor в Firefox

    На проходящей в эти дни в Стокгольме встрече разработчиков Tor отдельная секция посвящена вопросам интеграции Tor и Firefox. Ключевые задачи сводятся к созданию дополнения, обеспечивающего работу через анонимную сеть Tor в штатном Firefox, а также к переносу разработанных для Tor Browser патчей в основной состав Firefox. Для отслеживания состояния переноса патчей подготовлен специальный сайт torpat.ch. Перенесено пока 13 патчей, а для 22 патчей заведены обсуждения в багтрекере Mozilla (всего предложено более сотни патчей).

    Основная идея по интеграции с Firefox заключается в использовании Tor при работе в приватном режиме или в создании дополнительного суперприватного режима с Tor. Так как включение поддержки Tor в основой состав Firefox требует большой работы, решено начать с разработки внешнего дополнения. Дополнение будет поставляться через каталог addons.mozilla.org и будет включать кнопку для включения режима работы через Tor. Поставка в форме дополнения позволит оценить общую концепцию того, как может выглядеть встроенная поддержка Tor.

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

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

    Интерфейс Tor-режима пока обсуждается. Например, предлагается при клике на кнопку Tor открывать новое окно с отдельным профилем. В режиме Tor также предлагается полностью запретить отправку запросов по HTTP, так как содержимое незашифрованного трафика может быть перехвачено и модифицировано на выходящих узлах Tor. Защита от подстановки изменений в HTTP трафик через использование NoScript признана недостаточной, поэтому проще ограничить Tor режим только запросами через HTTPS.

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

    В Firefox 70 страницы открытые по HTTP начнут помечаться как небезопасные

    Разработчики Firefox представили план перехода Firefox к пометке всех страниц, открытых по HTTP, индикатором небезопасного соединения. Изменение планируется применить в выпуске Firefox 70, намеченном на 22 октября. В Chrome вывод индикатора, предупреждающего об установке небезопасного соединения, для открытых по HTTP страниц выводится начиная с выпуска Chrome 68, предложенного в июле прошлого года.

    В Firefox 70 также планируется убрать кнопку «(i)» из адресной строки, ограничившись постоянным размещением индикатора уровня безопасности соединения, который также позволяет оценить состояние режимов блокировки кода для отслеживания перемещений. Для HTTP будет явно показан значок проблем с безопасностью, который также будет выводиться для FTP и в случаях проблем с сертификатами:

    Предполагается, что отображения индикатора небезопасного соединения будет стимулировать владельцев сайтов переходить по умолчанию на HTTPS. По статистике сервиса Firefox Telemetry общемировая доля запросов страниц по HTTPS составляет 78.6% (год назад 70.3%, два года назад 59.7%), а в США — 87.6%. Некоммерческим удостоверяющим центром Let’s Encrypt, контролируемым сообществом и предоставляющим сертификаты безвозмездно всем желающим, выдано 106 млн сертификатов, охватывающих около 174 млн доменов (год назад было охвачено 80 млн доменов).

    Переход к пометке HTTP небезопасным является продолжением ранее предпринятых попыток форсирования перехода на HTTPS в Firefox. Например, начиная с выпуска Firefox 51 в браузере был добавлен индикатор проблем с безопасностью, отображаемый в случае обращения без использования HTTPS к страницам, содержащим формы аутентификации. Также началось ограничение доступа к новым Web API — в Firefox 67 для страниц, открытых вне защищённого контекста, запрещён вывод системных уведомлений через API Notifications, а в Firefox 68 при незащищённых обращениях блокируются запросы к вызову getUserMedia() для получения доступа к источникам мультимедийных данных (например, камере и микрофону). В настройки about:config также ранее был добавлен флаг «security.insecure_connection_icon.enabled», позволяющий опционально включить пометку небезопасного соединения для HTTP.

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

    Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020

    После полутора лет разработки представлен релиз кэшируюшего DNS-сервера PowerDNS Recursor 4.2, отвечающего за рекурсивное преобразование имён. PowerDNS Recursor построен на одной кодовой базе с PowerDNS Authoritative Server, но рекурсивный и авторитетный DNS-серверы PowerDNS развиваются в рамках разных циклов разработки и выпускаются в форме отдельных продуктов. Код проекта распространяется под лицензией GPLv2.

    В новой версии устранены все замечания в области поддержки стандартов, связанных с обработкой DNS-пакетов с флагами EDNS. В старых версиях PowerDNS Recursor до 2016 года практиковалось игнорирование пакетов с не поддерживаемыми флагами EDNS, без отправки ответа в старом формате, отбрасывая флаги EDNS, как того требует спецификация. Ранее подобное нестандартное поведение поддерживалось в BIND в форме обходного манёвра, но в рамках проведённой в феврале инициативы DNS flag day, разработчики DNS-серверов приняли решение отказаться от данного хака.

    В PowerDNS основные проблемы в обработке пакетов с EDNS были устранены ещё в 2017 году в выпуске 4.1, а в выпущенной в 2016 году ветке 4.0 всплывали лишь отдельные несовместимости, возникающие при определённом стечении обстоятельств и в общем виде не мешающие нормальной работе. В PowerDNS Recursor 4.2, как и в BIND 9.14, удалены обходные пути поддержки авторитетных серверов, некорректно отвечающих на запросы с флагами EDNS. До сих пор, если после отправки запроса с флагами EDNS через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS. Отныне данное поведение отключено, так как наличие подобного кода приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies для защиты от DDoS-атак.

    В рамках планируемого в следующем году мероприятия DNS flag day 2020 внимание будет сфокусировано на решении проблем с IP-фрагментацией при обработке DNS-сообщений большого размера. В рамках инициативы планируется увеличить рекомендованные размеры буферов для EDNS до значений на уровне 1200 байт, а также перевести обработку запросов по TCP в разряд обязательно поддерживаемых на серверах. Сейчас обязательна поддержка обработки запросов по UDP, а TCP желателен, но не обязателен для работы (стандарт предписывает наличие возможности отключения TCP). Предлагается удалить из стандарта опцию отключения TCP и стандартизировать переход от отправки запроcов по UDP к применению TCP в случаях, когда установленного размера буфера EDNS недостаточно.

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

    В PowerDNS Recursor 4.2 учтены проблемы с большими UDP-пакетами и осуществлён переход на использование размера буфера EDNS (edns-outgoing-bufsize) в 1232 байт, вместо ранее применявшегося лимита в 1680 байт, что должно существенно снизить вероятность потери UDP-пакетов. Значение 1232 выбрано, так как оно является максимумом, при котором размер DNS-ответа с учётом IPv6 укладывается в минимальное значение MTU (1280). До 1232 также уменьшено значение параметра truncation-threshold, отвечающего за обрезание ответов клиенту.

    Другие изменения в PowerDNS Recursor 4.2:

    • Добавлена поддержка механизма XPF (X-Proxied-For), представляющего собой эквивалент HTTP-заголовка X-Forwarded-For для DNS, позволяющего передать сведения об IP-адресе и номере порта изначального инициатора запроса, перенаправленного через промежуточные прокси и балансировщики нагрузки (например dnsdist). Для включения XPF предусмотрены опции «xpf-allow-from» и «xpf-rr-code«;
    • Улучшена поддержка EDNS-расширения Client Subnet (ECS), позволяющая передавать в DNS-запросах авторитетному DNS-серверу сведения о подсети, из которой был отравлен транслируемый по цепочке изначальный запрос (данные об исходной подсети клиента необходимы для эффективной работы сетей доставки контента). В новом выпуске добавлены настройки для выборочного контроля за применением EDNS Client Subnet: «ecs-add-for» со списком сетевых масок, для которых IP будет использован в ECS в исходящих запросах. Для адресов, которые не подпадают под указанные маски, будет использован общий адрес, указанный в директиве «ecs-scope-zero-address«. Через директиву «use-incoming-edns-subnet» можно определить подсети, входящие запросы с заполненными значениями ECS из которых не будут заменяться;
    • Для серверов, обрабатывающих большое число запросов в секунду (более 100 тысяч), предложена директива «distributor-threads«, определяющая число потоков для приема входящих запросов и их распределения между рабочими потоками (имеет смысл только при использовании режима «pdns-distributes-queries=yes«).
    • Добавлена настройка public-suffix-list-file для определения собственного файла со списком публичных суффиксов доменов, в которых пользователи могут регистрировать свои поддомены, вместо встроенного в PowerDNS Recursor списка.

    Проект PowerDNS также объявил о переходе на шестимесячный цикл разработки, в соответствии с которым следующий значительный релиз PowerDNS Recursor 4.3 ожидается в январе 2020 года. Обновления для значительных выпусков будут формироваться в течение года, после чего ещё полгода будут выпускаться исправления уязвимостей. Таким образом поддержка ветки PowerDNS Recursor 4.2 продлится до января 2021 года. Аналогичные изменения цикла разработки приняты для продукта PowerDNS Authoritative Server, выпуск 4.2 которого ожидается в ближайшее время.

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

    • Средства для удалённого сбора статистики;
    • Мгновенный перезапуск;
    • Встроенный движок для подключения обработчиков на языке Lua;
    • Полноценная поддержка DNSSEC и DNS64;
    • Поддержка RPZ (Response Policy Zones) и возможность определения чёрных списков;
    • Механизмы борьбы со спуфингом;
    • Возможность записи результатов резолвинга в виде файлов зон BIND.
    • Для обеспечения высокой производительности применяются современные механизмы мультиплексирования соединений во FreeBSD, Linux и Solaris (kqueue, epoll, /dev/poll), а также высокопроизводительный парсер DNS-пакетов, способный обрабатывать десятки тысяч параллельных запроcов.

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

    Компания Epic Games пожертвовала 1.2 млн долларов Blender и развивает продукты для Linux

    Компания Epic Games, разрабатывающая игровой движок Unreal Engine, пожертвовала 1.2 млн. долларов на развитие свободной системы 3D-моделирования Blender. Средства будут выделяться поэтапно в течение трёх лет. Деньги планируется потратить на расширение штата разработчиков, привлечение новых участников, улучшение координации работы в проекте и повышение качества кода.

    Пожертвование выделено под эгидой программы Epic MegaGrants, в рамках которой планируется потратить 100 млн долларов на гранты разработчикам игр, создателям контента и разработчикам инструментариев, связанных с движком Unreal Engine или открытыми проектами, полезными для сообщества, занимающегося 3D-графикой. По мнению Тима Суини (Tim Sweeney), основателя и руководителя компании Epic Games, открытые инструменты, библиотеки и платформы критически важны для будущего экосистемы цифрового контента. Blender является одним из наиболее востребованных и зарекомендовавших себя в сообществе инструментов, поэтому Epic Games стремится обеспечить его продвижение во благо всех создателей контента.

    Тим Суини также прокомментировал позицию компании по отношению к Linux, который рассматривается как отличная платформа. Продукты Unreal Engine 4, Epic Online Services и Easy Anti-Cheat развиваются для Linux в форме нативных сборок. Компания также рассматривает возможность расширения использованя Wine как средства для запуска в Linux игр из каталога Epic Games. Слухи о прекращении разработки Easy Anti-Cheat для Linux не соответствуют действительности — нативная Linux-версия данного продукта находится на стадии бета-тестирования и уже предоставляет поддержку античита даже для игр, запускаемых с использованием Wine и Proton.

    Напомним, что 19 июля, если не возникнет проблем с тестированием кандидата в релизы, ожидается выпуск Blender 2.80, который является одним из самых значительных выпусков в истории проекта. В новой версии полностью изменён пользовательский интерфейс, который стал привычен для пользователей других графических редакторов и 3D-пакетов. Представлены новые движки рендеринга Workbench для быстрой простой отрисовки и Eevee для рендеринга в режиме реального времени. Переработан 3D Viewport. Добавлена новая система для работы с 2D-эскизами как с трёхмерными объектами. Удалён встроенный игровой движок, вместо которого теперь предлагается использовать сторонние игровые движки.

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

    Microsoft открыл код Quantum Development Kit для разработки квантовых алгоритмов

    Компания Microsoft объявила об открытии исходных текстов пакета Quantum Development Kit (QDK), ориентированного на разработку приложений для квантовых компьютеров. В дополнение к ранее опубликованным примерам квантовых приложений и библиотекам, теперь опубликованы исходные тексты компилятора для языка Q#, runtime-компонентов, квантового симулятора, обработчика LanguageServer для интеграции с интегрированными средами разработки, а также дополнений к редактору Visual Studio Code и пакету Visual Studio. Код опубликован под лицензией MIT, проект доступен на GitHub для приёма изменений и исправлений от сообщества.

    Для разработки квантовых алгоритмов предлагается использовать предметно-ориентированный язык Q#, предоставляющий средства для манипуляции кубитами. Язык Q# во многом напоминает языки C# и F#, отличаясь применением ключевого слова «function» для определения функций, новым ключевым словом «operation» для квантовых операций, отсутствием многострочных комментариев и применением assert вместо обработчиков исключений.

    Для разработки на Q# могут использоваться платформы Windows, Linux и macOS, которые поддерживаются в Quantum Development Kit. Разрабатываемые квантовые алгоритмы могут тестироваться в симуляторе, способном обрабатывать до 32 кубитов на обычном ПК и до 40 кубитов в облаке Azure. Для IDE предоставляются модули для подсветки синтаксиса и отладчик, позволяющий устанавливать точки останова в коде на Q#, выполнять пошаговую отладку, оценивать необходимые для выполнения квантового алгоритма ресурсы и ориентировочную стоимость решения.

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

    В зависимостях к npm-пакету с установщиком PureScript выявлены вредоносные изменения

    В зависимостях к npm-пакету с установщиком PureScript выявлен вредоносный код, проявляющийся при попытке установки пакета purescript. Вредоносный код встроен через зависимости load-from-cwd-or-npm и rate-map. Примечательно, что сопровождением пакетов с данными зависимостями занимается изначальный автор npm-пакета с инсталлятором PureScript, который до недавних пор занимался сопровождением данного npm-пакета, но около месяца назад пакет перешёл к другим сопровождающим.

    Проблему обнаружил один из новых мэйтейнеров пакета, которому права на сопровождение были переданы после многих разногласий и неприятных обсуждений с изначальным автором npm-пакета purescript. Новые мэйнтейнеры отвечают за компилятор PureScript и настаивали, что NPM-пакет с его установщиком должен обслуживаться теми же сопровождающими, а не посторонним лицом. Автор npm-пакета с установщиком PureScript долго не соглашался, но затем уступил и передал доступ к репозиторию. При этом некоторые зависимости остались под его управлением.

    На прошлой неделе был выпущен релиз компилятора PureScript 0.13.2 и новыми сопровождающими было подготовлено соответствующее обновление npm-пакета с установщиком, в зависимостях к которому был выявлен вредоносный код. Смещённый с поста сопровождающего автор npm-пакета с установщиком PureScript заявил, что его учётная запись была скомпрометирована неизвестными атакующими. Тем не менее, в текущем виде действия вредоносного кода ограничивались лишь саботажем установки пакета, который стал первой версией от новых сопровождающих. Вредоносные действия сводились к зацикливанию с выводом ошибки при попытке установить пакет командой «npm i -g purescript» без выполнения явной вредоносной активности.

    Были выявлены две атаки. Через несколько часов после официального выхода новой версии npm-пакета purescript кем-то была сформирована новая версия зависимости load-from-cwd-or-npm 3.0.2, изменения в которой привели к тому, что вызов loadFromCwdOrNpm() вместо списка необходимых для установи бинарных файлов возвращал поток PassThrough, зеркалирующий входные запросы в качестве выходных значений.

    Спустя 4 дня, после того как разработчики разобрались в источнике сбоев и готовились выпустить обновление для исключения load-from-cwd-or-npm из зависимостей, злоумышленниками было выпущено ещё одно обновление load-from-cwd-or-npm 3.0.4, в котором вредоносный код был убран. Тем не менее, почти сразу было выпущено обновление другой зависимости rate-map 1.0.3, в которой было добавлено исправление, блокирующее callback-вызов для загрузки. Т.е. в обоих случаях изменения в новых версиях load-from-cwd-or-npm и rate-map носили характер явной диверсии. Более того, во вредоносном коде имелась проверка, которая активировала сбойные действия только при установке выпуска от новых сопровождающих и никак не проявлялась при установке старых версий.

    Разработчики решили проблему выпуском обновления, в котором проблемные зависимости были удалены. Для того чтобы исключить оседание скомпрометированного кода на системах пользователей после попытки установки проблемной версии PureScript рекомендуется удалить содержимое каталогов node_modules и файлов package-lock.json, после чего выставить в качестве нижнего лимита версию purescript 0.13.2.

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

    Представлен CoreCtrl 1.0, для привязки настроек оборудования к приложениям

    Опубликован первый выпуск приложения CoreCtrl, позволяющего определять профили изменения настроек оборудования, меняющие параметры работы GPU и CPU в зависимости от выполняемого приложения (например, для игр и программ 3D-моделирования можно привязать профиль максимальной производительности, а для браузера и офисных приложений включить режим экономии энергии и снизить частоту для уменьшения шума кулера). Код проекта написан на языке С++ (интерфейс на Qt и QML) и поставляется под лицензией GPLv3.

    Профили привязываются к исполняемым файлам (в том числе к Windows-программам, запускаемым через Wine). Программа отслеживает активность в системе и автоматически активирует или отключает профили при запуске или завершении работы связанного с ними приложения. Система также позволяет отслеживать изменение температуры, состояние системных датчиков и различны метрики (нагрузка на CPU, потребление памяти) во время выполнения приложений.

    В настоящее время проектом поддерживается управление новыми и старыми GPU AMD, включая изменение параметров вращения кулера, опрос датчиков, манипуляции частотой и напряжением, активацию режимов энергопотребления и управления производительностью. Также имеется базовая поддержка изменения частоты CPU, настройки CPU governor, задания лимитов на максимальную частоту и отображения параметров работы процессора. В дальнейшем планируется добавить поддержку других GPU и расширить средства управления CPU.

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

    Выпуск распределённой СУБД TiDB 3.0

    Доступен релиз распределённой СУБД TiDB 3.0, развиваемой под впечатлением от технологий Google Spanner и F1. TiDB относится к категории гибридных систем HTAP (Hybrid Transactional/Analytical Processing), способных как обеспечивать выполнение транзакций в реальном времени (OLTP), так и выполнять обработку аналитических запросов. Проект написан на языке Go и распространяется под лицензией Apache 2.0.

    Особенности TiDB:

    • Поддержка SQL и предоставление клиентского интерфейса, совместимого с протоколом MySQL, что упрощает адаптацию для TiDB существующих приложений, написанных для MySQL, а также позволяет задействовать распространённые клиентские библиотеки. Кроме протокола MySQL для обращения к СУБД можно использовать API на базе JSON и коннектор для Spark.
    • Из возможностей SQL поддерживаются индексы, агрегатные функции, выражения GROUP BY, ORDER BY, DISTINCT, слияния (LEFT JOIN / RIGHT JOIN / CROSS JOIN), представления, оконные функции и подзапросы. Предоставляемых возможностей достаточно для организации работы с TiDB таких web-приложений, как PhpMyAdmin, Gogs и Wordpress;
    • Возможность горизонтального масштабирования и обеспечения отказоустойчивости: размер хранилища и вычислительную мощность можно наращивать простым подключением новых узлов. Данные распределяются по узлам с избыточностью, позволяющей продолжить работу в случае сбоя отдельных узлов. Сбои обрабатываются автоматически.
    • Система гарантирует непротиворечивость и для клиентского ПО выглядит как одна большая СУБД, несмотря на то, что фактически для выполнения транзакции привлекаются данные со множества узлов.
    • Для физического хранения данных на узлах могут применяться разные бэкенды, например, локальные движки хранения GoLevelDB и BoltDB или собственный движок распределённого хранилища TiKV.
    • Возможность асинхронного изменения схемы хранения, позволяющая на лету добавлять столбцы и индексы без остановки обработки текущих операций.

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

    • Проведена работа по увеличению производительности. В тесте Sysbench выпуск 3.0 опережает ветку 2.1 в 1.5 раза при выполнении операций select и update, а в тесте TPC-C в 4.5 раза. Оптимизации затронули различные виды запросов, включая подзапросы «IN», «DO» и «NOT EXISTS», операции слияния таблиц (JOIN), использование индексов и многое другое;
    • Добавлен новый движок хранения TiFlash, позволяющий добиться более высокой производительности при решении аналитических задач (OLAP), благодаря хранению в привязке к столбцам. TiFlash дополняет собой ранее предлагаемое хранилище TiKV, хранящее данные в разрезе строк в формате ключ/значение и более опримальное для задач обработки транзакций (OLTP). TiFlash работает бок о бок с TiKV и данные продолжают как и раньше реплицироваться в TiKV с использоанием протокола Raft для определении консенсуса, но для каждой группы реплик Raft создаётся дополнительная реплика, которая используется в TiFlash. Подобный поход позволяет добиться лучшего разделения ресурсов между задачами OLTP и OLAP, а также делает данные транзакций мгновенно доступными для аналитических запросов;
    • Реализован распределённый сборщик мусора, позволяющий существенно повысить скорость сборки мусора в крупных кластерах и повысить стабильность работы;
    • Добавлена экспериментальная реализация системы разграничения доступа на основе ролей (RBAC). Также обеспечена возможность задания прав доступа для операций ANALYZE, USE, SET GLOBAL и SHOW PROCESSLIST;
    • Добавлена возможность использования выражений SQL для выблрки из лога медленных запросов;
    • Реализован механизм быстрого восстановления удалённых таблиц, позволяющий восстановить случайно удалённые данные;
    • Унифицирован формат записываемых логов;
    • Добавлена поддержка пессимистического режима блокировки, который делает обработку транзакций более близкой к MySQL;
    • Добавлена поддержка оконных функций (window-функции или аналитические функции), совместимых с MySQL 8.0. Оконные функции позволяют для каждой строки запроса выполнить вычисления, используя другие строки. В отличие от агрегатных функций, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят агрегирование на основе содержимого «окна», включающего одну или более строк из результирующего набора. Среди реализованных оконных функций: NTILE, LEAD, LAG, PERCENT_RANK, NTH_VALUE, CUME_DIST, FIRST_VALUE , LAST_VALUE, RANK, DENSE_RANK и ROW_NUMBER;
    • Добавлена экспериментальная поддержка представлений (VIEW);
    • Улучшена система секционирования (партицирования), добавлена возможность распределения данным по секциям на основании диапазона значений или хэшей;
    • Добавлен фреймворк для разработки плагинов, например, уже подготовлены плагины для использования белого списка IP или ведения лога аудита;
    • Обеспечена экспериментальная поддержка функции «EXPLAIN ANALYZE» для построения плана выполнения SQL-запроса (SQL Plan Management);
    • Добавлена команда next_row_id для получения идентификатора следующей строки;
    • Добавлены новые встроенные функции JSON_QUOTE, JSON_ARRAY_APPEND, JSON_MERGE_PRESERVE, BENCHMARK ,COALESCE и NAME_CONST.

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

    Facebook открыл код JavaScript-движка Hermes

    Компания Facebook открыла исходные тексты легковесного JavaScript-движка Hermes, оптимизированного для выполнения приложений на базе фреймворка React Native на платформе Android. Поддержка Hermes встроена в React Native начиная с сегодняшнего выпуска 0.60.2. Проект призван решить проблемы с большим временем запуска нативных JavaScript-приложений и значительным потреблением ресурсов. Код написан на языке C++ и распространяется под лицензией MIT.

    Из достоинств применения Hermes отмечается сокращение времени запуска приложения, снижение потребления памяти и уменьшение размера приложения. Ускорение запуска приложений достигается благодаря применению на этапе сборки предкомпиляции в компактный и эффективный байткод. Для непосредственного выполнения приложения применяется разработанная в рамках проекта виртуальная машина со сборщиком мусора SemiSpace. При применении V8 наиболее длительными являются стадии парсинга исходного кода и его компиляции на лету. Hermes выносит эти стадии на этап сборки и позволяет поставлять приложения в форме оптимизированного байткода.

    Обработка JavaScript разделяется на несколько стадий. Вначале осуществляется парсинг исходных текстов и генерация промежуточного представления кода (Hermes IR), основанного на представлении SSA (Static Single Assignment). Далее, промежуточное представление обрабатывается в оптимизаторе, который применяет техники упреждающей статической оптимизиации для преобразования первичного промежуточного кода в более эффективное промежуточное представление, сохраняя при этом оригинальную семантику программы. На последнем этапе генерируется байткод для регистровой виртуальной машины.

    В движке поддерживается часть JavaScript-стандарта ECMAScript 2015 (конечной целью является его полная поддержка) и обеспечивается совместимость с большинством существующих приложений React Native. В Hermes решено не поддерживать локальный запуск eval(), выражения «with», отражения (Reflect и Proxy), API Intl API и некоторые флаги в RegExp. Для включения Hermes в приложении React Native достаточно добавить в проект опцию «enableHermes: true». Также возможна сборка Hermes в режиме CLI-интерфейса, позволяющая выполнить произвольные JavaScript-файлы из командной строки.

    При этом Facebook не планирует адаптировать Hermes для Node.js и других решений, сосредотачивая внимание только на мобильных приложениях (AOT-компиляция вместо JIT наиболее оптимальна в контексте мобильных приложений на базе React Native). Проведённое сотрудниками Microsoft предварительное тестирование производительности показало, что при использовании Hermes приложение Microsoft Office для Android становится доступно для работы через 1.1 сек. после запуска и потребляет 21.5MB ОЗУ, в то время как при использовании движка V8 на запуск тратится 1.4 сек., а потребление памяти составляет 30MB.

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