crimea-karro


[Главная страница]
[Добавить в избранное]

Страницы: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

Анализ степени дублирования кода на GitHub

Представлены результаты изучения дублирования кода в общем объёме исходных текстов, размещённых на GitHub. Проанализировано 4.5 млн различных проектов (без форков репозиториев), включающих более 428 млн файлов с кодом на языках Java, C++, Python и JavaScript. Из этих файлов лишь 85 млн оказались уникальными, т.е. 80% кода на GitHub являются копиями других файлов.

Определение дубликатов выполнялось несколькими методами: путём сравнения хэшей файлов (полные копии), хэшей сгруппированного набора токенов из файла (не учитывает форматирование и комментарии) и оценки частичного заимствования кода при помощи SourcererCC (определён отредактированный код с 80% общих токенов).

Наиболее часто дубликаты встречаются в коде на языке JavaScript, для которого лишь 6% файлов не совпадают (т.е. 94% файлов являются полными клонами 6% файлов), 5% не совпадают по хэшу набора токенов и 2% отличаются с учётом редактирования кода. Наименьшее число дубликатов выявлено для кода на языке Java, для которого не повторяется 60% файлов, 56% наборов токенов и 26% отличаются с учётом редактирования кода. Для C++ эти показатели составляют 27%, 23% и 10%, а для Python - 29%, 27% и 9%.

Наиболее часто повторяющимся стал пустой файл, размером 0 байт, который встречается 2.2 млн раз. Но игнорирование при проверке мелких файлов, в которых встречаются менее 50 токенов, почти не сказывается на уровне совпадений:

Распределение языков по уровню дублирования кода также сохраняется, если провести сравнение не на уровне файлов, а на уровне проектов. Например, около 15% проектов на JavaScript являются полными клонами других проектов, 31% проектов копируют более 80% кода из других проектов, а 48% копируют более 50% кода. Для Java эти показатели составляют 6%, 9% и 14%.



Попытки разобраться почему степень дублирования кода столь велика показали, что наиболее частой причиной появление дубликатов, является включение в репозитории проектов кода из сторонних библиотек и фреймворков, вместо подключения их как внешних зависимостей. Например, для JavaScript очень велика доля копий библиотек, распространяемых через NPM. Несмотря на то, что только 6% проектов включают каталог node_modules, 70% из всех дубликатов на JavaScript связаны с копированием модулей NPM.

В среднем в JavaScript-проект включается 63 зависимости, а уровень вложенности зависимостей составляет 5 (максимальное зафиксированное число зависимостей - 1261, максимальный уровень вложенности - 47). Кроме NPM-модулей достаточно часто в проект включается библиотека jQuery. В Java чаще остальных дублируются компоненты ActionBarSherlock и Cordova, в C/C++ - boost и freetype, в Python копирование распределено более равномерно по разнообразным библиотекам.

Совпадения на уровне изменённого кода (частичное совпадение при проверке SourcererCC)чаще всего оказались вызванными использованием "копипастинга", а также ненамеренным копированием кода или автогенерацией кода в процессе применения типовых фреймворков. Например, для Java чаще всего совпадения выявлялись в коде, сгенерированном при помощи Apache Axis, Android SDK и JAXB, для Python при помощи Django, а для JavaScript - Angular.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47596

Линус Торвальдс раскритиковал ограничительные меры по усилению защиты ядра Linux

Линус Торвальдс не стесняясь в выражениях отверг заявку Кеса Кука (Kees Cook), предложившего включить в состав ядра 4.15 механизм защиты, блокирующий использование вызова usercopy при проведении некоторых видов атак. Суть предложенного метода в запрете применения usercopy для прямого копирования между пространством пользователя и некоторыми областями ядра с введением белого списка допустимых для использования областей памяти. Так как подобный подход потенциально может нарушить работу приложений, использующих usercopy, предусмотрен fallback-режим для kvm и sctp (ipv6).

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

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

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

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

Источник: http://www.opennet.ru/opennews/art.shtml?num=47593

В ядро Linux добавлена поддержка архитектуры RISC-V

В состав ядра Linux принят код для обеспечения работы на системах с архитектурой RISC-V. Пользователи смогут воспользоваться RISC-V начиная с ядра 4.15. Также ожидается включение поддержки новой архитектуры в состав glibc.

После выхода ядра 4.15, ориентировочно в начале февраля 2018 года, RISC-V Linux ABI будет переведён в разряд стабильных интерфейсов, сохраняющих обратную совместимость и готовых для повсеместного использования. До февраля разработчики намерены устранить остающиеся недоработки в ABI. Дистрибутивы, желающие приступить к обеспечению поддержки RISC-V до выхода ядра 4.15 и новой версии Glibc, могут воспользоваться бэкпортами, размещёнными в репозитории freedom-u-sdk (для сборки следует использовать команду "make sim").

RISC-V предоставляет открытую и гибкую систему машинных инструкций, позволяющую создавать микропроцессоры для произвольных областей применения, не требуя при этом отчислений и не налагая условий на использование. RISC-V позволяет создавать полностью открытые SoC и процессоры. В настоящее время на базе спецификации RISC-V разными компаниями и сообществами развивается 7 вариантов ядер микропроцессоров (Rocket, ORCA, PULPino, OPenV/mriscv, VexRiscv, Roa Logic RV12, SCR1) и три SoC (lowRISC, Rocket Chip, Briey), которые разрабатываются под различными свободными лицензиями (BSD, MIT, Apache 2.0).

Источник: http://www.opennet.ru/opennews/art.shtml?num=47590

Проект Pale Moon представил новый браузер Basilisk и платформу UXP

Разработчики Pale Moon представили первый публичный выпуск нового браузера Basilisk, который основан на движке Goanna (ранее созданный проектом форк Gecko) и платформе UXP (Unified XUL Platform), в рамках которой выполнено ответвление остальных компонентов Firefox из репозитория Mozilla Central, избавленных от привязок к коду на языке Rust. Сборки нового браузера подготовлены для Linux (только 64-бит) и Windows.

В браузере обеспечена поддержка старых дополнений на языке XUL, оставлена возможность загрузки любых плагинов с интерфейсом NPAPI (в том числе Unity, Flash и Java), возвращена поддержка звуковой подсистемы ALSA, обеспечена отрисовка шрифтов через библиотеку Graphite. При этом Basilisk также полностью поддерживает современные технологии, включая стандарт ECMAscript 6, API WebExtensions, WebAssembly (WASM), HSTS и TLS 1.3.

В отличие от Pale Moon в Basilisk используется интерфейс пользователя Australis, в виде, соответствующем Firefox 56. Из не принятых возможностей отмечается отключение проверки дополнений по цифровой подписи, отключение многопроцессного режима (Electrolysis), отказ от компонентов на языке Rust и наработок по модернизации интерфейса, подготовленных в рамках проекта Photon и представленных в Firefox 57.

Basilisk позиционируется как экспериментальный браузер, выступающий полигоном для развития платформы UXP, поэтому разработчики не гарантируют стабильность проекта - все релизы будут иметь уровень качества beta-выпусков. В 2018 году браузер Pale Moon планируют перевести на новую платформу UXP, но до этого перехода требуется довести эту платформу до желаемого вида, поэтому и создан ещё один браузер Basilisk, который позволит вести разработку новой платформы параллельно с текущей веткой Pale Moon (по сути Basilisk можно рассматривать как экспериментальную ветку Pale Moon).

Источник: http://www.opennet.ru/opennews/art.shtml?num=47587

GitHub добавил средства информирования об уязвимостях в репозиториях

GitHub реализовал отображение меток, информирующих об использовании проектами зависимостей с неисправленными уязвимостями. Вместе с меткой также выводятся сведения о путях устранения проблемы и версиях, в которых уязвимость уже устранена. В настоящее время выставление меток добавлено только для проектов на языках Javascript и Ruby, которые составляют 75% от кода с зависимостями, размещённого на GitHub. В 2018 году ожидается вывод аналогичных меток для проектов на языке Python. Вывод уведомлений об уязвимостях и построение графа зависимостей по умолчанию включено для всех публично доступных проектов.

Дополнительно можно отметить публикацию отчёта о состоянии безопасности открытого кода, составленного с учётом существенного увеличения числа библиотек в репозиториях. Например, за год число пакетов в NPM увеличилось на 57%, в PyPi на 32%, а в RubyGems на 10.3%. Соответственно на 53.8% увеличилось число уязвимостей в библиотеках из подобных репозиториев, при том, что число уязвимостей в пакетах из состава RHEL наоборот уменьшилось на 65%.

По данным составителей отчёта вызывающие уязвимости ошибки в среднем находятся в коде два с половиной года и в 75% случаев выявляются не мэйнтенерами, а сторонними исследователями. В среднем на исправление проблемы после получения уведомления об уязвимости уходит 16 дней, при том, что 34% мэйнтенеров реагируют на проблему в течение первого дня, а 60% в течение недели. Для 14% проанализированных библиотек выявленные уязвимости так и не были устранены. Только в 16.1% случаев исправления были портированы для прошлых выпусков библиотек.

10% проектов запрашивают для уязвимостей идентификатор CVE, а 25% практикуют умалчивание связи исправленных проблем с уязвимостями. Лишь 11% уязвимостей в Node.js занесены в базу NVD (National Vulnerability Database), для Rubygems этот показатель сооставляет 67%.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47586

Компания IBM представила открытый набор шрифтов Plex

Компания IBM открыла набор шрифтов Plex, доступный в пропорциональном (с засечками и без засечек) и моноширинном вариантах в 9 начертаниях (Bold, Italic, Light, ExtraLight, Medium, Regular, SemiBold, Text и Thin). Plex позиционируются как шрифты широкого назначения, которые могут применяться в различных областях, от Web и подготовки документов до редакторов кода. В компании IBM шрифт уже применяется на сайте, в рекламных материалах и в документообороте в качестве замены проприетарному семейству шрифтов Helvetica Neue, требующему выплаты отчислений.

Исходные тексты шрифта распространяются под свободной лицензией SIL Open Font License, позволяющей неограниченно модифицировать шрифт, использовать его в том числе для коммерческих целей, печати и на сайтах в Web. Для загрузки подготовлены различные форматы, включая ttf, otf, eot, woff и woff2. В настоящий момент в базовый состав не включены символы национальных алфавитов, но шрифт позиционируется как многоязычный с обещанием поддержки 110 языков. По словам разработчиков реализация символов кириллицы находится на финальной стадии и скоро будет опубликована.



Источник: http://www.opennet.ru/opennews/art.shtml?num=47583

Facebook открыл реализацию платформы и протокола маршрутизации Open/R

Facebook открыл наработки, связанные с платформой маршрутизации Open/R, которая изначально развивалась как распределённая система маршрутизации для динамически меняющихся беспроводных mesh-сетей, но затем была перенесена для других сетевых применений, включая опорную сеть Facebook Express Backbone. Код эталонной реализации Open/R написан на языке C++ и распространяется под лицензией MIT. Для определения RPC-вызовов используется язык описания интерфейсов Apache Thrift, а для обмена сообщениями между узлами - шина ZeroMQ.

Для управления доступен расширяемый CLI-интерфейс Breeze, написанный на языке Python. Для интеграции с централизованными системами управления трафиком предоставляется API, позволяющих внешним обработчикам получать сведения о состоянии линков или отслеживать обновления БД, например, получать информацию об изменении пропускной способности. Также доступен эмулятор для тестирования при помощи виртуальных сетей на базе Open/R, поддерживающий симуляцию различных видов сбоев, трафика и характеристик работы участков сети (возникновения потери пакетов, перегрузки, задержек, jitter и т.п.).

Протокол Open/R подходит для создания автономных сетевых решений с построением оптимальных маршрутов на основе построения реплицируемой базы данных о состоянии каналов. Open/R может применяться как альтернатива OSPF и IS-IS, легко адаптируемая для различных применений. Распределённая система маршрутизации является одним из таких применений. Вместо реализации собственных механизмов согласования соединений, оформления кадров и других низкоуровневых элементов протокола, в Open/R применяется идея задействования языка Thrift для кодирования всех связанных с Open/R сообщений и применения для их передачи уже проверенной временем библиотеки ZeroMQ, позволяющей использовать такие расширенные схемы, как издатель-подписчик.

Open/R также изначально спроектирован как универсальная платформа, не привязанная к конкретным аппаратным системам и маршрутизаторам. Логика построения маршрутов и обмена информацией с другими узлами полностью отделена от средств установки маршрутов через специальную прослойку (модуль Platform). В качестве основной платформы для Open/R применяется сетевое оборудование на базе открытой платформы FBOSS, такое как коммутаторы Wedge 100. При этом Open/R не зависит от ASIC и также может работать как поверх обычного сетевого стека Linux, так и с операционными системами Arista EOS и Juniper JunOS (QFX и PTX) через предоставляемый ими API на базе gRPC.

Элементы архитектуры Open/R:

Основные возможности:



Источник: http://www.opennet.ru/opennews/art.shtml?num=47577

Уязвимость в Apache CouchDB, позволяющая совершить атаку на реестр пакетов NPM

Опубликованы сведения о двух уязвимостях, устранённых в недавно опубликованных выпусках документ-ориентированной СУБД Apache CouchDB 2.1.1 и 1.7.1. В своей комбинации уязвимости позволяют провести атаку по удалённому выполнению произвольных shell-команд на сервере с правами процесса CouchDB, имея доступ к БД.

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

Первая уязвимость (CVE-2017-12635) проявляется из-за различий в работе используемых в CouchDB двух парсеров JSON, написанных на Erlang и JavaScript. Парсер на Erlang допускает добавление записи в БД "_users" с повторяющимися ключами, используемыми при определении прав доступа. В том числе можно добавить дубликат записи с меткой "_admin", через которую определяются пользователи с правами администратора. При наличии дубликатов ключей парсер на Erlang выдаёт первое совпадение, а JavaScript последнее.

Например, для добавления пользователя с правами администратора можно выполнить:

     curl -X PUT 'http://localhost:5984/_users/org.couchdb.user:oops'     --data-binary '{       "type": "user",       "name": "oops",       "roles": ["_admin"],       "roles": [],       "password": "password"     }'  

В процессе обработки данного запроса, содержащего два ключа "roles", реализация на Erlang обработает права "_admin", а реализация на JavaScript выдаст пустую строку. Подобное поведение приводит к тому, что при наличии в JSON двух повторяющихся ключей "roles", второй ключ будет использован при авторизации операций записи документа, а первый при авторизации только что созданного нового пользователя. Архитектура CouchDB не позволяет пользователям назначать себе права доступа, но из-за выявленной уязвимости обычный пользователь может назначить себе привилегии администратора.

Вторая уязвимость (CVE-2017-12636) присутствует в средствах настройки CouchDB через HTTP(S) и позволяет изменить путь к некоторым исполняемым файлам, вызываемым в процессе работы СУБД (параметр query_server). Пользователь с правами администратора (данные права можно получить при помощи первой уязвимости) может через манипуляцию с данными настройками вызвать любые shell-комманды в окружении операционной системы сервера, с правами под которыми выполняется СУБД. В том числе можно инициировать загрузку из глобальной сети произвольного скрипта и его выполнение на сервере.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47574

Linux вытеснил остальные ОС из рейтинга суперкомпьютеров Top500

Опубликован 50-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. Новый выпуск рейтинга примечателен двумя важными событиями: Во-первых, Linux полностью вытеснил остальные ОС и теперь используется на всех представленных в рейтинге суперкомпьютерах. Во-вторых, наблюдается наращивание мощных вычислительных кластеров в Китае, которые активно вытесняют из рейтинга американские системы, число которых уменьшилось за полгода с 168 до 143, а число китайских систем возросло со 160 до 202. Примечательно, что всего два c половиной года назад в Китае было 37 кластеров, входящих в TOP500.

В пятёрке самых мощных кластеров отмечается только одно изменение: кластер Gyoukou, введённый в строй японским агентством науки и технологий по изучению морских недр, вытеснил с четвёртого места кластер Titan, построенный в Национальной лаборатории Оук-Ридж (министерство энергетики США) на базе платформы Cray XK7.

Рейтинг по-прежнему возглавляет китайский кластер Sunway TaihuLight, работающий в национальном суперкомпьютерном центре Китая и демонстрирующий производительность в 93 петафлопс, что в три раза больше показателей занимающего второе место китайского кластера Tianhe-2, показавшего производительность в 33.9 петафлопс. На третьем месте кластер Piz Daint, развиваемый в швейцарском национальном суперкомпьютерном центре и демонстрирующий производительность в 19.6 петафлопс.

Наиболее интересные тенденции:

В ближайшие дни ожидается новый выпуск альтернативного рейтинга кластерных систем Graph 500, ориентированного на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и задач по обработке больших массивов данных, свойственных для данных систем. Рейтинг Green500 отдельно больше не выпускается и объединён с Top500, так как обеспечение энергоэффективности теперь отражается в основном рейтинге Top500 (учитывается отношение LINPACK FLOPS к потребляемой мощности в ваттах).



Источник: http://www.opennet.ru/opennews/art.shtml?num=47570

Релиз среды разработки приложений KDevelop 5.2

Состоялся релиз интегрированной среды программирования KDevelop 5.2, полностью поддерживающей процесс разработки для KDE 5, в том числе с использованием Clang в качестве компилятора. Код проекта распространяется под лицензией GPL и использует библиотеки KDE Frameworks 5 и Qt 5.

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



Источник: http://www.opennet.ru/opennews/art.shtml?num=47569 Новости | Севастополь| Crimea-Karro

Страницы: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

crimea-karro.ru