"Никогда такого не было и вот опять!!!111"

https://thechief.io/c/news/51-4-million-docker-images-have-critical-vulnerabilities/

#docker #vulnerability

Антон написал большой пост https://xn--r1a.website/nosingularity/652 про новые штуки и предложения, которые они завезли и планируют завезти в http://holistic.dev и http://parsers.dev.

И там говорится об SQL -> IR компиляции. В связи с чем я вспомнил paper о Snel.

Snel is a relational database engine featuring Just-In-Time (JIT) compilation of queries and columnar data representation. Snel is designed for fast on-line analytics by leveraging the LLVM compiler infrastructure. It also has custom special methods like resolving histograms as extensions to the SQL language. "Snel" means "SQL Native Execution for LLVM".

Если вы таким интересуетесь, то рекомендую глянуть.

Paper прицепил + пост на Medium с подробным рассказом
https://medium.com/grandata-engineering/introducing-snel-a-columnar-just-in-time-query-compiler-for-fast-on-line-analytics-9cf561f82526

Ну и если вас заинтересовало то, что делает Антон, то присоединяйтесь. Антон классный.

> К сожалению, ценой трансформации CentOS станет потеря полной бинарной совместимости с RHEL, а также неизбежное снижение уровня стабильности и пригодности для рабочих внедрений.

> По мнению Пабло Греко, проект CentOS мёртв и больше не существует, так как CentOS Stream это не CentOS, а лишь платформа для разработки следующей версии RHEL.

> Грегори Курцер считает, что снижение пригодности CentOS Stream для предприятий и рабочих проектов, не самая большая проблема. Изменением, побудившим к созданию Rocky Linux, стало сокращение времени поддержи CentOS 8 с 10 до 2 лет. При внедрении CentOS 8 пользователи рассчитывали, что поддержка продлится до 2029 года, а Red Hat решил прекратить её в 2021 году.

Red Hat объясняет трансформацию CentOS желанием сделать более открытой разработку RHEL
https://www.opennet.ru/opennews/art.shtml?num=54288

Use the Microsoft Application Inspector to analyze your source code
https://zimmergren.net/use-microsoft-application-inspector-to-analyze-source-code/
+
A source code analyzer built for surfacing features of interest and other characteristics to answer the question 'What's in the code?' quickly using static analysis with a json based rules engine.
https://github.com/microsoft/ApplicationInspector

Поддерживаемые языки
https://github.com/microsoft/ApplicationInspector/wiki/3.4-Applies_to-(languages)#language-support

Митап от DevOps Novosibirsk "K8s-20, история распространения заболевания"
24 декабря, 15:00 МСК

Самоизоляция 20го года  вызвала взрывной рост Web-а, а значит и взрывной рост потребности в инструментах для такого роста, коим и является Kubernetes.

В этот раз мы вместе с Киром Кузнецовым поговорим, что же интересного произошло в мире Kubernetes и рядом за напряженный 2020-ый год.

Кир Кузнецов – ведущий Ops-инженер Злых марсиан. Причиняет клиентам добро и помогает с Operations и DevOps при вторжении на Землю, деплоит продакшен на Kubernetes.

Регистрация
https://devops-nsk.timepad.ru/event/1510616/

AinD: Android in Docker. Ain't an emulator.
https://github.com/aind-containers/aind

На DevOpsConf 2021 (оффлайновый) открылся приём докладов. Так что если у вас есть чем поделиться с миром, то все подробности можно узнать тут

https://cfp.devopsconf.io/

Звонки мошенников из фальшивых колл-центров банков могут в начале показаться очень реалистичными. Главное научиться их вовремя распознавать.

Набросал реализацию сканера исправлений для исходников ядра на основе coccinelle https://github.com/evdenis/cvehound

Что делает: пытается обнаружить неисправленные куски кода для известных CVE.

Как работает: для каждой CVE в ядре есть шаблон coccinelle/grep с описанием ошибки в коде до исправления, либо описанием какой фикс в коде должен присутствовать. Соответственно, на исходниках запускается поиск на наличие "незапатченного" куска кода, либо проверяется отсутствие исправления.

Зачем нужно: если у вас есть лог разработки (git), то не нужно, можно и по нему проверить. Если у вас на руках только архив с исходниками, тогда проверку можно автоматизировать так. Не всегда есть лог разработки, не все версии ядер основываются на стабильных ветвях, иногда исходники выкладываются просто как архив. Пример - исходники ядер для samsung/huawei телефонов (opensource.samsung.com)

Что сейчас умеет: в первый релиз добавил шаблоны только для ~30 CVE (список https://github.com/evdenis/cvehound/tree/master/cvehound/cve). Запускается как ./cvehound --dir ~/linux, где ~/linux путь к исходникам ядра. Если добавить опцию --verbose будет показывать что сейчас проверяет и выводить файлы, в которых нашел отсутствие фикса. Опция --cve CVE-2020-27194 CVE-2020-29371 позволяет проверить наличие конкретных исправлений.