> The tl;dr is that we will be adding AGPL as another license option next to ELv2 and SSPL in the coming weeks.

> “Changing the license was a mistake, and Elastic now backtracks from it”. We removed a lot of market confusion when we changed our license 3 years ago. And because of our actions, a lot has changed. It’s an entirely different landscape now. We aren’t living in the past. We want to build a better future for our users. It’s because we took action then, that we are in a position to take action now.

> “AGPL is not true open source, license X is”: AGPL is an OSI approved license, and it's a widely adopted one. For example, MongoDB used to be AGPL and Grafana is AGPL. It shows that AGPL doesn’t affect usage or popularity. We chose AGPL because we believe it’s the best way to start to pave a path, with OSI, towards more Open Source in the world, not less.

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

> For example, MongoDB used to be AGPL and Grafana is AGPL.

Ага, да. Именно так определяется open source это или нет.

Elasticsearch is open source, again
https://www.elastic.co/blog/elasticsearch-is-open-source-again

Помните историю про беззащитный "не Сапсан" (https://xn--r1a.website/tech_b0lt_Genona/2395), когда раскурочили всё "в щепки"?

Вот не менее интересная история, но про аэропорт.

Через SQL-инъекцию автору удалось стать администратором системы, что позволяет добавить себя в список бортпроводников или пилотов, при этом никакой дополнительной проверки после этого не было.

Several other attacks were also likely possible. Since our vulnerability allowed us to edit an existing KCM member, we could have changed the photo and name of an existing enrolled user, which would likely bypass any vetting process that may exist for new members. If you are able to obtain an unenrolled KCM barcode, you can also enroll it to an employee ID yourself on the KCM website.

Bypassing airport security via SQL injection
https://ian.sh/tsa

Спасибо подписчику за ссылку

Хронология событий

- YouTube стали замедлять

- Пользователи начали делать мозги провайдерам и ливать от них + писать жалобы на провайдеров

- РКН никак не помогал провайдерам решать их проблемы

- Провайдеры самостоятельно стали "ускорять" YouTube за свой счёт

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

https://www.kommersant.ru/doc/6919868

- РКН пришёл сразу к провайдерам и запретил это делать

Роскомнадзор потребовал от операторов связи перестать искажать и подменять интернет-трафик, чтобы не препятствовать работе технических средств противодействия угрозам. 
. . .
До 2 сентября операторы должны предоставить в ГРЧЦ отчёты о принятых мерах.

https://www.kommersant.ru/doc/6921420

ЗЫ
ГРЧЦ подчиняется РКН

#cpp #meme

Семинар Артёма Кашканова: "DekatronPC - собираем самый маленький в мире ламповый компьютер"

Может ли полноценная ламповая вычислительная машина уместиться в половину серверной стойки? Как современные средства проектирования микропроцессоров помогают в создании схем ламповой логики? Как убедиться, что в 4U корпусе не станет жарко, а главное - зачем ламповому компьютеру нужна ПЛИС? Об этом и многом другом создатель релейного компьютера BrainfuckPC расскажет о своем текущем проекте - Brainfuck-компьютере на сверхминиатюрных электронных лампах.
Chaos Constructions'2024

https://vk.com/video-225689_456239149
https://www.youtube.com/watch?v=2tfsED_2fSo

Мы в Luntry запустили инициативу в виде помощи учащимся с исследовательскими работами по теме безопасности контейнеризации, Kubernetes и всему, что с этим связано.

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

Подробнее тут
https://luntry.ru/initiatives/curation

Прямая ссылка на анкету, если Вас заинтересовало - https://docs.google.com/forms/d/e/1FAIpQLSeqAkfyi2wC8CWJJE9hWBEX5Bt5lLFVd4fsZfhiAdeWlzz6CA/viewform

Материалы наших исследований доступны тут - https://luntry.ru/research

ЗЫ Может быть чьим-то куратором буду я 🌝

Слайды с нашего с Никитой выступления "[Dev]iceSecOps, или Зачем мы написали инструмент для анализа прошивок". Рассмотрели существующие решения с открытым кодом и выбрали наиболее подходящие из них не только под наши задачи. Хотя и по итогу написали своё, часть из рассказанных подходов можно будет переиспользовать. Ну и конечно, куда же без radare2 rizin.

Видео с @offzone_moscow будут опубликованы позже, а пока сезонное видео, к сожалению, аккурат к Этому Дню удаленное из ютуба, поэтому Михаил Шуфутинский ⧸ Linkin Park - 3 Сентября (Cover by ROCK PRIVET )

Выложили доклады с DevConf.US 2024

Плейлист
https://www.youtube.com/playlist?list=PLU1vS0speL2a-MgC0CmlLi8-cC1VwRjvB

Программа
https://www.devconf.info/us/schedule/

ЗЫ У меня тут поднакопилось, так что будет ещё пару постов про конфы. Объявляется "Конференций день" на канале 🌝

Выложили доклады с KCD Munich 2024

Плейлист
https://www.youtube.com/playlist?list=PL54A_DPe8WtBuSp7sqpxeuy_UoTTlKB1O

Программа
https://www.kcdmunich.de/schedule/

ЗЫ В списке докладчиков замечен был Максим Набоких, который был архитектором в команде Deckhouse, а теперь в Palark (https://palark.com/). Palark это, цитирую https://xn--r1a.website/flant_chat/7213,

Это юрлицо от создателей и выходцев из Фланта для оказания схожих услуг (DevOps/SRE) на международном рынке. Базируется в Германии.

Доклад Максима - Kubernetes Authentication 2.0: Structured Authentication Configuration

Тем временем начали выкладывать доклады с OFFZONE 2024

Пока только в ВК, будут ли ещё куда-то я не знаю

Ссылка на плейлисты тут
https://vk.com/video/@offzone_moscow/playlists

Программа тут
https://offzone.moscow/program/

ЗЫ На YouTube пока тишина
https://www.youtube.com/@offzone_moscow

UPD YouTube не будет

Оттепель

Проект пока не проект

Проект закона обязывающий блогеров с аудиторией больше 10 000 подписчиков подавать информацию о себе в Роскомнадзор
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=150487

Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.
. . .
Возвращаясь ко второму заголовку: «Explore – не баг, а фича!», стоит отметить, что данный функционал, доступный анонимному пользователю – это все-таки баг. Отслеживать все процессы и пуши, происходящие в Gitlab, а также то, какие данные будут доступны «случайному» пользователю, крайне сложно. Поэтому стоит серьёзно отнестись к настройке приватности вашего репозитория.

Explor-им GitLab
https://habr.com/ru/companies/cyberok/articles/840506/

Обещал написать, что там по #http3, так сказать, в поле.

Я взял 3 реализации HTTP/3, от openssl (далее O), от nginx (далее N), и от MS (далее M).

Я взял несколько сайтов, про кототорые достоверно, что они отдаются через HTTP/3. При этом, надо сказать, что я не нашел такой сайт от MS, с msquic, далее будет понятно, почему.

Плюс к этим сайтам, я взял cloudflare, про который достоверно известно, что они используют свою реализацию HTTP/3 (quiche, у меня ее нет), и я взял google, про который достоверно известно, что у них тоже своя реализация.

Тестировал такой командой:

curl -vvv -k --http3 https://host

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

https://cloudflare-quic.com/

O: HTTP/2
N: HTTP/2
M: HTTP/2

Отсюда можно сразу сделать вывод, что с quiche не дружит никто. Ну, понятное дело, браузеры, наверное, дружат, но у них совсем другие реализации.

https://quic.nginx.org

O: HTTP/3
N: HTTP/3
M: HTTP/2

https://google.com

O: HTTP/3
N: HTTP/3
M: HTTP/2

Клиента, который бы дружил со всеми проверенными реализациями, пока не существует, такие дела.

Отдельно добавлю про клиент от MS (который у меня M, msquic) - он нигде не смог показать факт того, что умеет в HTTP/3. А еще на паре сайтов (например, github.com) выдал такое - curl: (16) Error in the HTTP2 framing layer, и не смог их скачать.

Я полагаю, именно в этом причина того, что MS убрали тестилку с ним, потому что реализация - говно, на нее забили хуй, и использовать ее не надо. Ну или ее плохо интегрировали в curl, но, все равно, HTTP/3 оно не смогло показать нигде.

Для проформы я посмотрел, что же там на https://microsoft.com:

O: HTTP/1
N: HTTP/1
M: HTTP/1

Что это значит? Что и серверная часть msquic - какое-то говно, ну или MS забили на нее, а использовать что-то другое не позволяет гордость.

Вывод пока неутешительный - http3 "сыровато", но вполне может быть готово для десктопа, потому что в браузерах, полагаю, ситуация будет лучше!

И отдельный вывод про MS - MS хорошо делает мышки и шрифты, а все остальное у них - ну такое себе.

Исследователи безопасности из компании NinjaLab разработали технику атаки по сторонним каналам, позволяющую клонировать ECDSA-ключи, хранимые в криптографических токенах YubiKey 5 и других устройствах, в которых используется криптографическая библиотека от компании Infineon. Атака получила кодовое имя EUCLEAK и помимо токенов с чипами Infineon SLE78, таких как YubiKey 5, может применяться ко многим другим системам с микроконтроллерами компании Infineon, включая чипы Infineon Optiga Trust M и Infineon Optiga TPM.
. . .
Возможность совершения атаки подтверждена на практике для ключей YubiKey 5Ci и TPM на чипах SLB96xx, а для других устройств носит теоретический характер. В ключах YubiKey 5 уязвимость устранена в версии прошивки 5.7 путём замены криптографической библиотеки (исправление применимо только к новым устройствам, так как в уже выпущенных устройствах YubiKey возможность обновления прошивки не предусмотрена). Для библиотеки Infineon разработаны блокирующие уязвимость исправления, но они ещё не задействованы так как не прошли сертификацию.
. . .
Кроме физического доступа к ключу для успешного проведения атаки на сервисы с многофакторной аутентификацией злоумышленнику дополнительно требуется каким-то образом узнать логин и пароль от сервиса, для дополнительной аутентификации к которому используется полученный аппаратный ключ, а в случае применения беспарольной аутентификации в режимах FIDO2 Passwordless или Passkey необходимо воспроизвести уникальный биометрический фактор (например, отпечаток пальца).

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

Проблема вызвана использованием в библиотеке Infineon небезопасного алгоритма вычисления обратного элемента по модулю, вычисления в котором занимают фиксированное время, независимо от значений входных данных (для разные векторов наблюдается разное время вычисления обратного элемента по модулю). Подобная особенность позволяет на основе анализа изменения сигнала выделить информацию об отдельных битах во время выполнения операций с вектором инициализации. В случае с ECDSA, определения даже нескольких битов с информацией о векторе инициализации (nonce) достаточно для совершения атаки по последовательному восстановлению всего закрытого ключа. Для успешного воссоздания ключа требуется перехват активности при генерации примерно 40 цифровых подписей.

Атака EUCLEAK, позволяющая клонировать YubiKey 5 и другие ключи на чипах Infineon
https://www.opennet.me/opennews/art.shtml?num=61817

Оригинал
https://ninjalab.io/eucleak/

PDF исследования скину в комменты

Конфликт между старыми разработчиками ядра, которые пишут на C, и новыми, кто хочет в Rust, разгоратеся прямо сильно.

https://lkml.org/lkml/2024/8/28/1532

https://sporks.space/2024/09/05/is-linux-collapsing-under-its-own-weight-on-rust-for-linux/

https://vt.social/@lina/113045455229442533

https://www.opennet.ru/opennews/art.shtml?num=61819

https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=youtu.be&themeRefresh=1

Конфликт, в целом, имеет очень понятную природу - разработчикам Rust нужны врапперы над абстракциями ядра, но:

1) эти абстракции плохо подходят для модели безопасности Rust, и старослужащие не хотят их менять в угоду Rust. Это плохо, я тут на стороне разработчиков Rust.

2) старослужащие хотят менять интерфейсы, и не учить новый язык. То есть, не хотят править абстракции Rust, когда меняют свои интерфейсы. Это, благодаря всратой модели взаимодействия Rust с внешним миром (когда надо руками захардкодить структуры и смещения в них), работает плохо. Тут я на стороне господ старослужащих, потому что надо взять, да сделать норм interop с C, и это задача для разработчиков Rust.

Вот тут (https://vt.social/@lina/113045455229442533) вот подняли интересную тему, что таки надо С++, а не Rust, потому что нормальный interop, нет ебли с lifetime, и вообще, это больше похоже на инкрементальное изменение, которое будет поддержано бОльшим числом мейнтейнеров.

Не хочу делать какое-то summary, надо ходить по ссылкам, и читать, с комментариями, для того, чтобы понять, в каком печальном состоянии находится разработка ядра сейчас.

Всемогущие мейнтейнеры, которые не разговаривают друг с другом, и делать что-то cross subsystems не представляется возможным, такие дела.

Ох уж эти грани 🌝

Я о таком развитии событий ещё 12 июня говорил https://xn--r1a.website/tech_b0lt_Genona/4504

Google больше не даёт создать новый аккаунт на российский номер телефона. Официально компания не объявляла об ограничениях.

При попытке привязать к новому аккаунту российский номер появляется сообщение: «Этот номер нельзя использовать для подтверждения». В этом убедилась редакция Справочной. Мы также выяснили, что с такой проблемой пользователи начали сталкиваться ещё в августе. Ранее зарегистрированные на российские номера аккаунты продолжают работать.

Google запретил создавать аккаунты на российские номера
https://allo.tochka.com/news/google-account

UPD:
https://xn--r1a.website/tech_b0lt_Genona/4645

В комменты принесли

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

Не исключаю наличия проблем на стороне некоторых операторов и истекшие контракты Google с кем-то из них. Но конкретно новость, которую разносят по Telegram - ложь, и сегодня в этом плане ничего не изменилось - ситуация та же что и полгода, год и даже три года назад.

https://xn--r1a.website/cb_economics/4860

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

@delvh I completely agree with you (which should be quite evident from my comments here).

Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it.

This is a cynical take, but I have raised these concerns in private channels and there has been no evidence to refute it. If Gitea Ltd. wants to focus its efforts on the private fork and to make money, that is fine with me, but unfortunately, they also decide what gets merged here, so there is a massive conflict of interest (cough open core). Since Lunny has blocked it and refuses to say why, it appears we are stuck.

I have asked them to commit publicly to not merging code in their private codebase that is still open for review upstream, but that hasn’t been well received, leaving me and some other members of the community pretty disheartened.

https://github.com/go-gitea/gitea/pull/24257#issuecomment-2338274680

Обсуждение на HackerNews

Gitea blocks PR from community, charging $$ for open-source contributions
https://news.ycombinator.com/item?id=41488929

За наводку спасибо @sysadmin_tools