Каждый раз одно и тоже. На хайпе люди себе гадость тащат всякую даже не задумываясь, что они себе тащат.
First Malicious MCP in the Wild: The Postmark Backdoor That's Stealing Your Emails
https://www.koi.security/blog/postmark-mcp-npm-malicious-backdoor-email-theft
MCP-сервер (Model Context Protocol) это же удобно? Конечно, удобно. И пофиг, что ему прав на всякое выдают немерено и шариться он может много где.
Проверяет ли кто что там в этих MCP-серверах и чего они делают? Естественно, нет. Хорошо, что в данном случае код был открыт.
> Tools built by people we've never met. People we have zero way to vet. And our AI assistants? We just... trust them. Completely.
Скачивался это "помощник" по 1500 раз в неделю. И вот с версии
Это был реальный проект, реально человека, который все предыдущие версии просто работал
> Software engineer from Paris, using his real name, GitHub profile packed with legitimate projects. This wasn't some shady anonymous account with an anime avatar. This was a real person with a real reputation, someone you'd probably grab coffee with at a conference.
> For 15 versions - FIFTEEN - the tool worked flawlessly. Developers were recommending it to their teams.
Если посмотрите на первый скрин, то увидите, что проставлялся адресат для скрытой копии.
По сутиразработчик злоумышленник взял код из официального репозитория (https://github.com/ActiveCampaign/postmark-mcp) добавил одну строчку и опубликовал в NPM с тем же именем (второй скрин).
В посте правильно замечается, что это новый тип угроз к которому никто особо и не готов
> As security teams focus on traditional threats and compliance frameworks, developers are independently adopting AI tools that operate completely outside established security perimeters. These MCP servers run with the same privileges as the AI assistants themselves - full email access, database connections, API permissions - yet they don't appear in any asset inventory, skip vendor risk assessments, and bypass every security control from DLP to email gateways. By the time someone realizes their AI assistant has been quietly BCCing emails to an external server for months, the damage is already catastrophic.
Ну и в целом я разделяю опасения автора
> The postmark-mcp backdoor isn't just about one malicious developer or 1,500 weekly compromised installations. It's a warning shot about the MCP ecosystem itself.
We're handing god-mode permissions to tools built by people we don't know, can't verify, and have no reason to trust. These aren't just npm packages - they're direct pipelines into our most sensitive operations, automated by AI assistants that will use them thousands of times without question.
Когда разработчику написали и спросили за происходящее, то он ничего не ответил и просто удалил репу
> When we reached out to the developer for clarification, we got silence. No explanation. No denial. Nothing. But he did take action - just not the kind we hoped for. He promptly deleted the package from npm, trying to erase the evidence.
First Malicious MCP in the Wild: The Postmark Backdoor That's Stealing Your Emails
https://www.koi.security/blog/postmark-mcp-npm-malicious-backdoor-email-theft
MCP-сервер (Model Context Protocol) это же удобно? Конечно, удобно. И пофиг, что ему прав на всякое выдают немерено и шариться он может много где.
Проверяет ли кто что там в этих MCP-серверах и чего они делают? Естественно, нет. Хорошо, что в данном случае код был открыт.
> Tools built by people we've never met. People we have zero way to vet. And our AI assistants? We just... trust them. Completely.
Postmark это почтовый сервак. postmark-mcp это, соответственно, ИИ-помощник.Скачивался это "помощник" по 1500 раз в неделю. И вот с версии
1.0.16 ВНЕЗАПНО11!!! он стал отсылать каждое письмо на сервак разработчика. Надо ли говорить, что в почте куча важной информации хранится?!Это был реальный проект, реально человека, который все предыдущие версии просто работал
> Software engineer from Paris, using his real name, GitHub profile packed with legitimate projects. This wasn't some shady anonymous account with an anime avatar. This was a real person with a real reputation, someone you'd probably grab coffee with at a conference.
> For 15 versions - FIFTEEN - the tool worked flawlessly. Developers were recommending it to their teams.
Если посмотрите на первый скрин, то увидите, что проставлялся адресат для скрытой копии.
По сути
В посте правильно замечается, что это новый тип угроз к которому никто особо и не готов
> As security teams focus on traditional threats and compliance frameworks, developers are independently adopting AI tools that operate completely outside established security perimeters. These MCP servers run with the same privileges as the AI assistants themselves - full email access, database connections, API permissions - yet they don't appear in any asset inventory, skip vendor risk assessments, and bypass every security control from DLP to email gateways. By the time someone realizes their AI assistant has been quietly BCCing emails to an external server for months, the damage is already catastrophic.
Ну и в целом я разделяю опасения автора
> The postmark-mcp backdoor isn't just about one malicious developer or 1,500 weekly compromised installations. It's a warning shot about the MCP ecosystem itself.
We're handing god-mode permissions to tools built by people we don't know, can't verify, and have no reason to trust. These aren't just npm packages - they're direct pipelines into our most sensitive operations, automated by AI assistants that will use them thousands of times without question.
Когда разработчику написали и спросили за происходящее, то он ничего не ответил и просто удалил репу
> When we reached out to the developer for clarification, we got silence. No explanation. No denial. Nothing. But he did take action - just not the kind we hoped for. He promptly deleted the package from npm, trying to erase the evidence.
😁20🤣5👍4❤2👀2🤡1
Гитлабчик можно уже не обновлять 💅💅💅
Хакерская группа Crimson Collective заявила о получении доступа к одному из внутренних GitLab-серверов компании Red Hat и загрузке с него 570ГБ сжатых данных, содержащих информацию из 28 тысяч репозиториев. Среди прочего в захваченных данных присутствовало около 800 CER-отчётов (Customer Engagement Report), содержащих конфиденциальную информацию о платформах и сетевых инфраструктурах клиентов Red Hat, которым предоставлялись консалтинговые услуги.
В представленных атакующими скриншотах и примерах упоминается о получении данных, связанных с около 800 клиентами Red Hat, среди которых Vodafone, T-Mobile, Siemens, Boeing, Bosch, 3M, Cisco, DHL, Adobe, American Express, Verizon, JPMC, HSBC, Ericsson, Merrick Bank, Telefonica, Bank of America, Delta Air Lines, Walmart, Kaiser, IBM, SWIFT, IKEA и AT&T, а также Центр разработки надводного вооружения ВМС США, Федеральное управление гражданской авиации США, Федеральное агентство по управлению в чрезвычайных ситуациях США, Военно-воздушные силы США, Агентство национальной безопасности США, Ведомство по патентам и товарным знакам США, Сенат США и Палата представителей США.
Утверждается, что захваченные репозитории содержат сведения об инфраструктуре клиентов, конфигурацию, токены аутентификации, профили VPN, данные инвентаризации, Ansible playbook, настройки платформы OpenShift, CI/CD runner-ы, резервные копии и другие данные, которые могут быть использованы для организации атаки на внутренние сети клиентов. Злоумышленники пытались связаться с Red Hat с целью вымогательства, но получили лишь шаблонный ответ с предложением отправить в службу безопасности отчёт об уязвимости.
Компания Red Hat подтвердила инцидент с безопасностью, но не привела подробности и не прокомментировала информацию о содержимом утечки. Упоминается только то, что взломанный GitLab-сервер использовался в консалтинговом подразделении и компания предприняла шаги, необходимые для проверки и восстановления. Представители Red Hat утверждают, что у них нет оснований полагать, что взлом затронул другие сервисы и продукты компании, кроме одного сервера GitLab.
Взлом внутреннего GitLab-сервера Red Hat
https://www.opennet.ru/opennews/art.shtml?num=63986
Твит
https://x.com/intcyberdigest/status/1973422846396473765
Хакерская группа Crimson Collective заявила о получении доступа к одному из внутренних GitLab-серверов компании Red Hat и загрузке с него 570ГБ сжатых данных, содержащих информацию из 28 тысяч репозиториев. Среди прочего в захваченных данных присутствовало около 800 CER-отчётов (Customer Engagement Report), содержащих конфиденциальную информацию о платформах и сетевых инфраструктурах клиентов Red Hat, которым предоставлялись консалтинговые услуги.
В представленных атакующими скриншотах и примерах упоминается о получении данных, связанных с около 800 клиентами Red Hat, среди которых Vodafone, T-Mobile, Siemens, Boeing, Bosch, 3M, Cisco, DHL, Adobe, American Express, Verizon, JPMC, HSBC, Ericsson, Merrick Bank, Telefonica, Bank of America, Delta Air Lines, Walmart, Kaiser, IBM, SWIFT, IKEA и AT&T, а также Центр разработки надводного вооружения ВМС США, Федеральное управление гражданской авиации США, Федеральное агентство по управлению в чрезвычайных ситуациях США, Военно-воздушные силы США, Агентство национальной безопасности США, Ведомство по патентам и товарным знакам США, Сенат США и Палата представителей США.
Утверждается, что захваченные репозитории содержат сведения об инфраструктуре клиентов, конфигурацию, токены аутентификации, профили VPN, данные инвентаризации, Ansible playbook, настройки платформы OpenShift, CI/CD runner-ы, резервные копии и другие данные, которые могут быть использованы для организации атаки на внутренние сети клиентов. Злоумышленники пытались связаться с Red Hat с целью вымогательства, но получили лишь шаблонный ответ с предложением отправить в службу безопасности отчёт об уязвимости.
Компания Red Hat подтвердила инцидент с безопасностью, но не привела подробности и не прокомментировала информацию о содержимом утечки. Упоминается только то, что взломанный GitLab-сервер использовался в консалтинговом подразделении и компания предприняла шаги, необходимые для проверки и восстановления. Представители Red Hat утверждают, что у них нет оснований полагать, что взлом затронул другие сервисы и продукты компании, кроме одного сервера GitLab.
Взлом внутреннего GitLab-сервера Red Hat
https://www.opennet.ru/opennews/art.shtml?num=63986
Твит
https://x.com/intcyberdigest/status/1973422846396473765
😁39🫡17💅6❤3🔥1
How Grab’s Migration from Go to Rust Cut Costs by 70%
https://blog.bytebytego.com/p/how-grabs-migration-from-go-to-rust
tl;dr Основным языком был Go, потом переписали один важный сервис на Rust и снизили затраты на 70%.
Теперь не очень кратко
Был выбран высоконагруженный, но достаточно простой по функциональности сервис
> To approach this decision carefully, the Grab Engineering Team set clear criteria for selecting a service to rewrite. The chosen system needed to be simple enough in its functionality to avoid unnecessary complexity. It also had to serve large amounts of traffic so that any efficiency gains would be meaningful. Finally, the team needed to be confident that engineers were willing and able to learn Rust to support the system for the long term.
Таким сервисом стал
- Фиксирует события, считает их и складывает в ScyllaDB
- Отвечает на GRPC запросы, которые собственно и касаются "циферок"
> While Counter Service handles very high traffic, reaching tens of thousands of requests every second at peak times, the work it performs is straightforward. It counts, stores, and returns numbers.
На первой картинке видно как этот сервис организован
Переписывали сервис "вслепую", как "чёрный ящик". Новая реализация должна была повторять полностью ответы старой системы на одинаковые запросы.
Далее смотрели какие библиотеки есть для Rust, что бы во-первых упростить перенос, во-вторых оценить некую "зрелость" зависимостей.
Here are the main dependencies:
- Datadog StatsD client: The Grab engineering team chose Cadence. It had fewer than 500 GitHub stars, which suggested a smaller user base, but the API was intuitive and covered all the required features.
- OpenTelemetry: They used opentelemetry-rust, which had more than 1,000 stars and solid community backing.
- GRPC: The tonic library was selected, a well-known Rust implementation of GRPC with active use and more than 500 stars.
- Web server: actix-web was picked. It is one of the most popular Rust frameworks, with more than 20,000 stars.
- Redis: Initially, the team tried redis-rs, the “official” Redis client with over 3,000 stars. However, it did not meet the needs of the project’s asynchronous design. They switched to fred.rs, which had over 5,000 stars and better async support.
- Scylla: They used the scylla-rust-driver. Although it had only around 500 stars, it was officially maintained by the Scylla project, giving confidence in its long-term support.
- Kafka: The kafka-rust client, with over 1,000 stars, was adopted to handle messaging needs.
Следующей проблемой было то, что их собственные компоненты и либы были написаны на Go. Одну из таких важных библиотек им пришлось переписать на Rust.
Пост большой и дальше там поднимаются проблемы Borrow Checker'а (а кто с ним не боролся на первых шагах 🌝) и Async Concurrency (тоже ловили проблемы на первых этапах разработки).
Итого
- Сервис перепилили
- latency обе реализации показали приблизительно одинаковую, иногда у Rust даже медленнее (вторая картинка)
- Но для реализации на Rust ресурсов надо меньше:
- The Go service needed about 20 CPU cores.
- The Rust service needed only about 4.5 cores.
- This translated into nearly five times better efficiency and about 70 percent lower infrastructure cost for the same workload.
Основных три общих вывода
- Rust is not always faster than Go. Go is already fast enough for most high-performance services, so Rust will not necessarily reduce latency
- Rust is more efficient. Thanks to its design, Rust uses less computing power to achieve the same results. This makes it especially valuable for services with heavy traffic where cost savings add up quickly
- Rust’s learning curve depends on context. Writing synchronous code in Rust is manageable for most experienced developers, especially with the help of the compiler and the Clippy linter. The real challenge comes with asynchronous code, which requires a deeper understanding of concurrency
https://blog.bytebytego.com/p/how-grabs-migration-from-go-to-rust
tl;dr Основным языком был Go, потом переписали один важный сервис на Rust и снизили затраты на 70%.
Теперь не очень кратко
Был выбран высоконагруженный, но достаточно простой по функциональности сервис
> To approach this decision carefully, the Grab Engineering Team set clear criteria for selecting a service to rewrite. The chosen system needed to be simple enough in its functionality to avoid unnecessary complexity. It also had to serve large amounts of traffic so that any efficiency gains would be meaningful. Finally, the team needed to be confident that engineers were willing and able to learn Rust to support the system for the long term.
Таким сервисом стал
Counter Service, который отслеживает происходящее и предоставляет различные счётчики- Фиксирует события, считает их и складывает в ScyllaDB
- Отвечает на GRPC запросы, которые собственно и касаются "циферок"
> While Counter Service handles very high traffic, reaching tens of thousands of requests every second at peak times, the work it performs is straightforward. It counts, stores, and returns numbers.
На первой картинке видно как этот сервис организован
Переписывали сервис "вслепую", как "чёрный ящик". Новая реализация должна была повторять полностью ответы старой системы на одинаковые запросы.
Далее смотрели какие библиотеки есть для Rust, что бы во-первых упростить перенос, во-вторых оценить некую "зрелость" зависимостей.
Here are the main dependencies:
- Datadog StatsD client: The Grab engineering team chose Cadence. It had fewer than 500 GitHub stars, which suggested a smaller user base, but the API was intuitive and covered all the required features.
- OpenTelemetry: They used opentelemetry-rust, which had more than 1,000 stars and solid community backing.
- GRPC: The tonic library was selected, a well-known Rust implementation of GRPC with active use and more than 500 stars.
- Web server: actix-web was picked. It is one of the most popular Rust frameworks, with more than 20,000 stars.
- Redis: Initially, the team tried redis-rs, the “official” Redis client with over 3,000 stars. However, it did not meet the needs of the project’s asynchronous design. They switched to fred.rs, which had over 5,000 stars and better async support.
- Scylla: They used the scylla-rust-driver. Although it had only around 500 stars, it was officially maintained by the Scylla project, giving confidence in its long-term support.
- Kafka: The kafka-rust client, with over 1,000 stars, was adopted to handle messaging needs.
Следующей проблемой было то, что их собственные компоненты и либы были написаны на Go. Одну из таких важных библиотек им пришлось переписать на Rust.
Пост большой и дальше там поднимаются проблемы Borrow Checker'а (а кто с ним не боролся на первых шагах 🌝) и Async Concurrency (тоже ловили проблемы на первых этапах разработки).
Итого
- Сервис перепилили
- latency обе реализации показали приблизительно одинаковую, иногда у Rust даже медленнее (вторая картинка)
- Но для реализации на Rust ресурсов надо меньше:
- The Go service needed about 20 CPU cores.
- The Rust service needed only about 4.5 cores.
- This translated into nearly five times better efficiency and about 70 percent lower infrastructure cost for the same workload.
Основных три общих вывода
- Rust is not always faster than Go. Go is already fast enough for most high-performance services, so Rust will not necessarily reduce latency
- Rust is more efficient. Thanks to its design, Rust uses less computing power to achieve the same results. This makes it especially valuable for services with heavy traffic where cost savings add up quickly
- Rust’s learning curve depends on context. Writing synchronous code in Rust is manageable for most experienced developers, especially with the help of the compiler and the Clippy linter. The real challenge comes with asynchronous code, which requires a deeper understanding of concurrency
🆒19👍14🤡9❤4🔥4👌2🤨2🥴1
Пентестеры, багхантеры и прочие специалисты по ИБ есть? Принимайте пополнение в свои ряды 🌝
Ранее в пабликах появилось фото Милонова с iPhone 17 Pro — последней моделью смартфона компании Apple.
Изданию «Подъём» Виталий Милонов пояснил, что обзавёлся устройством в исследовательских целях.
«Мы с группой молодых ленинградских учёных из совета ветеранов ищем сейчас уязвимости и дырки в операционной системе для того, чтобы поставить туда полноценное российское ПО».
https://pdmnews.ru/42468/
Ранее в пабликах появилось фото Милонова с iPhone 17 Pro — последней моделью смартфона компании Apple.
Изданию «Подъём» Виталий Милонов пояснил, что обзавёлся устройством в исследовательских целях.
«Мы с группой молодых ленинградских учёных из совета ветеранов ищем сейчас уязвимости и дырки в операционной системе для того, чтобы поставить туда полноценное российское ПО».
https://pdmnews.ru/42468/
😁70🤡45🤣22💊8🎃3☃1🔥1😐1🖕1
Россиянам рекомендовали не указывать в своих профилях в соцсетях полностью фамилию, имя и отчество, а также дату рождения, потому что мошенники могут использовать эту информацию в преступных целях.
МВД рекомендовало не указывать в соцсетях полные персональные данные
https://www.rbc.ru/rbcfreenews/68e1ec7e9a7947f714e346aa
Совет хороший. Вот бы ещё все, в том числе и соцсети, перестали требовать везде номер мобильного телефона, который и является главной зацепкой для мошенников.
https://www.tg-me.com/tech_b0lt_Genona/4953
https://www.tg-me.com/tech_b0lt_Genona/5082
МВД рекомендовало не указывать в соцсетях полные персональные данные
https://www.rbc.ru/rbcfreenews/68e1ec7e9a7947f714e346aa
Совет хороший. Вот бы ещё все, в том числе и соцсети, перестали требовать везде номер мобильного телефона, который и является главной зацепкой для мошенников.
https://www.tg-me.com/tech_b0lt_Genona/4953
https://www.tg-me.com/tech_b0lt_Genona/5082
😁50🤡15👍13🔥4
Там JetBrains опять какую-то херню придумали. Если вы сидите на бесплатной некоммерческой лицензии, то не забудьте отключить новую "фичу", которая будет автоматически собирать данные для обучения AI. Среди этих данных куски вашего кода, действия в терминале, история редактирования.
Better AI Depends on Better Data: We Need Your Help
https://blog.jetbrains.com/blog/2025/09/30/detailed-data-sharing-for-better-ai/
> For individuals on non-commercial licenses: Data sharing is enabled by default, but you can turn it off anytime in the settings.
> We’re now adding the option to allow the collection of detailed code‑related data pertaining to IDE activity, such as edit history, terminal usage, and your interactions with AI features. This may include code snippets, prompt text, and AI responses.
ЗЫ
we will make sure that:
- No sensitive or personal information is shared.
- Data is properly secured.
- Access is restricted to authorized personnel and use cases.
Ну что я могу сказать на make sure:
Better AI Depends on Better Data: We Need Your Help
https://blog.jetbrains.com/blog/2025/09/30/detailed-data-sharing-for-better-ai/
> For individuals on non-commercial licenses: Data sharing is enabled by default, but you can turn it off anytime in the settings.
> We’re now adding the option to allow the collection of detailed code‑related data pertaining to IDE activity, such as edit history, terminal usage, and your interactions with AI features. This may include code snippets, prompt text, and AI responses.
ЗЫ
we will make sure that:
- No sensitive or personal information is shared.
- Data is properly secured.
- Access is restricted to authorized personnel and use cases.
Ну что я могу сказать на make sure:
This media is not supported in your browser
VIEW IN TELEGRAM
😁48🤯6✍1🤡1😐1🫡1
Forwarded from Мемный Болт Генона
Пожар уничтожил облачное хранилище правительства Южной Кореи, резервных копий нет
https://habr.com/ru/news/953800/
Пожар в штаб-квартире Национальной службы информационных ресурсов (NIRS) в Тэджоне (Республика Корея) уничтожил государственную облачную систему G-Drive, стерев рабочие файлы, которые индивидуально сохраняли данные около 750 000 госслужащих, сообщило в среду Министерство внутренних дел и безопасности страны.
Огонь вспыхнул в серверной на пятом этаже центра, повредив 96 информационных систем, признанных критически важными для работы центральных органов власти, включая платформу G-Drive. G-Drive используется с 2018 года и обязывал чиновников хранить все рабочие документы в облаке, а не на личных компьютерах. Каждому сотруднику предоставлялось около 30 гигабайт.
Министерство пояснило, что большинство систем в центре данных Тэджона ежедневно резервируются на отдельное оборудование внутри того же центра и на удалённый объект, но архитектура G-Drive не позволяла делать внешние копии. Эта уязвимость оставила систему без защиты.
Высокопоставленный южнокорейский чиновник, который отвечал за интеграцию информационных систем и данных, покончил жизнь самоубийством, возможно, в связи с данным инцидентом.
Из комментов
Взорвавшаяся батарея, установленная в комнате в августе 2014 года, уже примерно год как отслужила свой 10-летний срок службы.
https://m.koreaherald.com/article/10586088
Часть аккумуляторов уже была перемещена в рамках текущих мер пожарной безопасности, но все 384 оставшихся литий-ионных аккумулятора в ИБП были уничтожены пожаром. Аккумуляторы, произведенные компанией LG Energy Solution, были установлены в стоечных шкафах.
Компания NIRS начала переезд, поскольку аккумуляторные батареи ИБП были установлены на том же этаже, что и серверы, что вызвало опасения по поводу пожарной безопасности. Хотя два предыдущих этапа переезда прошли без происшествий, пожар вспыхнул во время отключения аккумуляторных батарей перед третьим переездом.
https://m.koreaherald.com/article/10585116
> но архитектура G-Drive не позволяла делать внешние копии
Я в этом слабо верю
https://habr.com/ru/news/953800/
Пожар в штаб-квартире Национальной службы информационных ресурсов (NIRS) в Тэджоне (Республика Корея) уничтожил государственную облачную систему G-Drive, стерев рабочие файлы, которые индивидуально сохраняли данные около 750 000 госслужащих, сообщило в среду Министерство внутренних дел и безопасности страны.
Огонь вспыхнул в серверной на пятом этаже центра, повредив 96 информационных систем, признанных критически важными для работы центральных органов власти, включая платформу G-Drive. G-Drive используется с 2018 года и обязывал чиновников хранить все рабочие документы в облаке, а не на личных компьютерах. Каждому сотруднику предоставлялось около 30 гигабайт.
Министерство пояснило, что большинство систем в центре данных Тэджона ежедневно резервируются на отдельное оборудование внутри того же центра и на удалённый объект, но архитектура G-Drive не позволяла делать внешние копии. Эта уязвимость оставила систему без защиты.
Высокопоставленный южнокорейский чиновник, который отвечал за интеграцию информационных систем и данных, покончил жизнь самоубийством, возможно, в связи с данным инцидентом.
Из комментов
Взорвавшаяся батарея, установленная в комнате в августе 2014 года, уже примерно год как отслужила свой 10-летний срок службы.
https://m.koreaherald.com/article/10586088
Часть аккумуляторов уже была перемещена в рамках текущих мер пожарной безопасности, но все 384 оставшихся литий-ионных аккумулятора в ИБП были уничтожены пожаром. Аккумуляторы, произведенные компанией LG Energy Solution, были установлены в стоечных шкафах.
Компания NIRS начала переезд, поскольку аккумуляторные батареи ИБП были установлены на том же этаже, что и серверы, что вызвало опасения по поводу пожарной безопасности. Хотя два предыдущих этапа переезда прошли без происшествий, пожар вспыхнул во время отключения аккумуляторных батарей перед третьим переездом.
https://m.koreaherald.com/article/10585116
> но архитектура G-Drive не позволяла делать внешние копии
Я в этом слабо верю
🔥22😁11😢4🤯1
Media is too big
VIEW IN TELEGRAM
Я себе предысторию форвардил
https://www.tg-me.com/tech_b0lt_Genona/5410
https://www.tg-me.com/tech_b0lt_Genona/5411
Юристы добились от «Ред софт» исполнения лицензии GPL
https://www.linux.org.ru/news/russia/18101384
Bytes & Rights — это юридическая компания, работающая в сфере цифрового права. В мае 2024-го года они приобрели два продукта компании «Ред Софт», а именно «Ред ОС: Рабочая станция» и «Ред ОС: Сервер». В составе этих продуктов множество кода под лицензией GPL, которая требует предоставлять исходники, однако на сайте компании Ред Софт исходных кодов обнаружено не было.
Юристы подготовили и направили в адрес компании «Ред Софт» обращения, в ответ компания пообещала предоставить исходники, но так и не предоставила. В ответ на это, юристы обратились в Генпрокуратуру и Минцифры. Генпрокуратура перенаправила обращение в Минцифры, Минцифры провело анализ и выдало заключение, что продукты «Ред софт» соответствуют критериям включения в Реестр отечественного ПО, никак не комментируя вопрос о предоставлении исходных кодов и соблюдения требований лицензии GPL. Компания «Ред софт», узнав об обращении в Минцифры, заявила, что предоставит исходники и предоставила их — однако юристы утверждают, что исходники были предоставлены не полностью, в них отсутствуют патчи, внесённые разработчиками «Ред Софт».
«В представленных исходных кодах отсутствует часть элементов (файлов, патчей), необходимых для создания, установки и запуска компонентов. Без этих элементов скомпилировать компоненты в том виде, в котором они использованы в продуктах Ред Софт, невозможно. Таким образом, требование лицензии GPL/LGPL не выполнено, поскольку полный исходный код компонентов, защищаемых лицензией GPL, по запросу пользователя не предоставлен», – говорят в Bytes & Rights.
Не удовлетворённые получением лишь исходников юристы пошли на второй круг в Минцифры, и через некоторое время всё-таки получили исходные тексты. Но опять не те. И только с третьего раза после очередного обращения к правообладателю, в Генпрокуратуру и в Минцифры, юристы получили наконец исходные коды, соответствующие предоставляемым программам.
Финальные предоставленные исходники были выложены на gitflic: https://gitflic.ru/team/oss-challenge-team.
Юридические особенности защиты GPL в России:
- Подать иск по ГК может правообладатель.
- Пользователь не является стороной договора GPL.
- Договор в пользу третьего лица возможен, но третье лицо должно быть определено в договоре.
Поэтому юристы избрали вариант доказательства, что в случае непредставленияя исходников продукт становится контрафактным.
К посту прицепил свежее выступление Татьяны Никифоровой "Работают ли лицензии GPL в России? Итоги юридического эксперимента"
Оригинальная ссылка
ХXI конференция разработчиков свободных программ, 2 день, вечер
https://vkvideo.ru/video-667081_456239433
https://www.tg-me.com/tech_b0lt_Genona/5410
https://www.tg-me.com/tech_b0lt_Genona/5411
Юристы добились от «Ред софт» исполнения лицензии GPL
https://www.linux.org.ru/news/russia/18101384
Bytes & Rights — это юридическая компания, работающая в сфере цифрового права. В мае 2024-го года они приобрели два продукта компании «Ред Софт», а именно «Ред ОС: Рабочая станция» и «Ред ОС: Сервер». В составе этих продуктов множество кода под лицензией GPL, которая требует предоставлять исходники, однако на сайте компании Ред Софт исходных кодов обнаружено не было.
Юристы подготовили и направили в адрес компании «Ред Софт» обращения, в ответ компания пообещала предоставить исходники, но так и не предоставила. В ответ на это, юристы обратились в Генпрокуратуру и Минцифры. Генпрокуратура перенаправила обращение в Минцифры, Минцифры провело анализ и выдало заключение, что продукты «Ред софт» соответствуют критериям включения в Реестр отечественного ПО, никак не комментируя вопрос о предоставлении исходных кодов и соблюдения требований лицензии GPL. Компания «Ред софт», узнав об обращении в Минцифры, заявила, что предоставит исходники и предоставила их — однако юристы утверждают, что исходники были предоставлены не полностью, в них отсутствуют патчи, внесённые разработчиками «Ред Софт».
«В представленных исходных кодах отсутствует часть элементов (файлов, патчей), необходимых для создания, установки и запуска компонентов. Без этих элементов скомпилировать компоненты в том виде, в котором они использованы в продуктах Ред Софт, невозможно. Таким образом, требование лицензии GPL/LGPL не выполнено, поскольку полный исходный код компонентов, защищаемых лицензией GPL, по запросу пользователя не предоставлен», – говорят в Bytes & Rights.
Не удовлетворённые получением лишь исходников юристы пошли на второй круг в Минцифры, и через некоторое время всё-таки получили исходные тексты. Но опять не те. И только с третьего раза после очередного обращения к правообладателю, в Генпрокуратуру и в Минцифры, юристы получили наконец исходные коды, соответствующие предоставляемым программам.
Финальные предоставленные исходники были выложены на gitflic: https://gitflic.ru/team/oss-challenge-team.
Юридические особенности защиты GPL в России:
- Подать иск по ГК может правообладатель.
- Пользователь не является стороной договора GPL.
- Договор в пользу третьего лица возможен, но третье лицо должно быть определено в договоре.
Поэтому юристы избрали вариант доказательства, что в случае непредставленияя исходников продукт становится контрафактным.
К посту прицепил свежее выступление Татьяны Никифоровой "Работают ли лицензии GPL в России? Итоги юридического эксперимента"
Оригинальная ссылка
ХXI конференция разработчиков свободных программ, 2 день, вечер
https://vkvideo.ru/video-667081_456239433
🔥57❤6🤡3👏2😁2🎉2😎1
Я на тему AI-краулеров и проблем, которые они создают, уже писал
https://www.tg-me.com/tech_b0lt_Genona/5122
https://www.tg-me.com/tech_b0lt_Genona/5305
Собственно, Anubis вы можете наблюдать сейчас на многих сайтах (первый скрин)
Но битва продолжается
Zip-бомбы против агрессивных ИИ-краулеров
https://habr.com/ru/companies/globalsign/articles/953654/
По информации аналитического отчёта Fastly, краулеры, скраперы и фетчеры иногда создают нагрузку на сайт до 39 тыс. запросов в минуту.
В 2025 году нагрузка от скраперов выросла на 87%, причём основной трафик идёт от RAG-скраперов, а не для первичного обучения моделей.
Сейчас ИИ-краулеры генерируют около 80% всего трафика ИИ-ботов в интернете. Всего 20% приходится на фетчеры, но они ответственны за серьёзные пиковые нагрузки. Например, ClaudeBot компании Anthropic отправил миллион запросов за сутки к сайту с техническими инструкциями iFixit.com и 3,5 млн запросов за четыре часа к Freelancer.com.
Среди всех ботов одним из самых назойливых является краулер Facebook (признана экстремистской организацией в РФ):
Боты Perplexity AI замечены в выходе за диапазон официальных IP-адресов и игнорировании директивы robots.txt.
В последнее для защиты от агрессивных ИИ-краулеров стали активно использоваться zip-бомбы, которые истощают оперативную память в дата-центре краулера. Это может быть стандартный архив размером 10 МБ, который распаковывается в 10 ГБ:
Или валидный HTML:
...со сжатием 1:1030:
Поскольку обычные браузеры вроде Chrome и Firefox тоже выходят из строя при попытке отобразить такой HTML, на него не ставят прямых ссылок с веб-страниц, чтобы живые пользователи не зашли туда по ошибке. Такая страница доступна только для ИИ-ботов.
По мнению некоторых активистов, на эффективность zip-бомб указывает тот факт, что разработчики краулеров пытаются уберечься через запрет на получение zip-контента. В свою очередь, такие директивы — один из признаков вредоносных краулеров, то есть она полезна для фингерпринтинга.
https://www.tg-me.com/tech_b0lt_Genona/5122
https://www.tg-me.com/tech_b0lt_Genona/5305
Собственно, Anubis вы можете наблюдать сейчас на многих сайтах (первый скрин)
Но битва продолжается
Zip-бомбы против агрессивных ИИ-краулеров
https://habr.com/ru/companies/globalsign/articles/953654/
По информации аналитического отчёта Fastly, краулеры, скраперы и фетчеры иногда создают нагрузку на сайт до 39 тыс. запросов в минуту.
В 2025 году нагрузка от скраперов выросла на 87%, причём основной трафик идёт от RAG-скраперов, а не для первичного обучения моделей.
Сейчас ИИ-краулеры генерируют около 80% всего трафика ИИ-ботов в интернете. Всего 20% приходится на фетчеры, но они ответственны за серьёзные пиковые нагрузки. Например, ClaudeBot компании Anthropic отправил миллион запросов за сутки к сайту с техническими инструкциями iFixit.com и 3,5 млн запросов за четыре часа к Freelancer.com.
Среди всех ботов одним из самых назойливых является краулер Facebook (признана экстремистской организацией в РФ):
Боты Perplexity AI замечены в выходе за диапазон официальных IP-адресов и игнорировании директивы robots.txt.
В последнее для защиты от агрессивных ИИ-краулеров стали активно использоваться zip-бомбы, которые истощают оперативную память в дата-центре краулера. Это может быть стандартный архив размером 10 МБ, который распаковывается в 10 ГБ:
$ dd if=/dev/zero bs=1M count=10240 | gzip -9 > 10G.gzip
Или валидный HTML:
...со сжатием 1:1030:
$ fish zip_bomb.fish | gzip -9 > bomb.html.gz
$ du -sb bomb.html.gz
10180 bomb.html.gz
Поскольку обычные браузеры вроде Chrome и Firefox тоже выходят из строя при попытке отобразить такой HTML, на него не ставят прямых ссылок с веб-страниц, чтобы живые пользователи не зашли туда по ошибке. Такая страница доступна только для ИИ-ботов.
По мнению некоторых активистов, на эффективность zip-бомб указывает тот факт, что разработчики краулеров пытаются уберечься через запрет на получение zip-контента. В свою очередь, такие директивы — один из признаков вредоносных краулеров, то есть она полезна для фингерпринтинга.
😁45💊4❤2🤡2🔥1🤣1
Forwarded from Токсичная цифра
Возможно будем обсуждать штрафы для компаний, которые не переводят свое ИТ на решения КИИ и остаются на иностранных решениях, которые в общем неплохие, и за которые теперь можно де-факто не платить (с) Шадаев
😁27🖕14🤡5💊3👍1
Упорный разработчик, конечно. Успехов ему в этом нелёгком деле
Выпуск ZLUDA 5, универсальной открытой реализации технологии CUDA
https://www.opennet.ru/opennews/art.shtml?num=63997
Анджей Яник (Andrzej Janik) представил выпуск ZLUDA 5, открытой реализации технологии CUDA. Целью проекта является предоставление возможности запуска немодифицированных приложений CUDA на системах с GPU, отличными от GPU NVIDIA, с производительностью, близкой к производительности приложений, выполняемых без прослоек. Код проекта написан на языке Rust и распространяется под лицензиями MIT и Apache 2.0.
ZLUDA 5 стал вторым значительным выпуском проекта, сформированным после чистки кодовой базы от кода, разработанного во время работы Анджея в компании AMD. С 2022 года Анджей работал в AMD над созданием слоя для совместимости GPU AMD с CUDA, но в 2024 году проект был свернут. В соответствии с условиями контракта и после получения разрешения на публикацию от представителя AMD, Анджей открыл код наработок, созданных во время работы в AMD и позволяющих выполнять CUDA-приложения поверх стека ROCm и runtime HIP (Heterogeneous-computing Interface for Portability).
В прошлом году Анджей был вынужден убрать код из открытого доступа после письма от юристов, давших понять, что разрешение, данное в ходе переписки по email, не имеет юридической силы. После этого Анджей начал работу над новой редакцией ZLUDA, сформированной на основе кодовой базы, существовавшей до начала работы Анджея в AMD. В текущем виде разработка сосредоточена на выполнении приложений, использующих CUDA для ускорения задач, связанных с машинным обучением. Проект пока ограничивается работой на GPU AMD, но в дальнейшем будет адаптирован для GPU Intel.
Оригинал
ZLUDA update Q3 2025 – ZLUDA 5 is here
https://vosen.github.io/ZLUDA/blog/zluda-update-q3-2025/
Выпуск ZLUDA 5, универсальной открытой реализации технологии CUDA
https://www.opennet.ru/opennews/art.shtml?num=63997
Анджей Яник (Andrzej Janik) представил выпуск ZLUDA 5, открытой реализации технологии CUDA. Целью проекта является предоставление возможности запуска немодифицированных приложений CUDA на системах с GPU, отличными от GPU NVIDIA, с производительностью, близкой к производительности приложений, выполняемых без прослоек. Код проекта написан на языке Rust и распространяется под лицензиями MIT и Apache 2.0.
ZLUDA 5 стал вторым значительным выпуском проекта, сформированным после чистки кодовой базы от кода, разработанного во время работы Анджея в компании AMD. С 2022 года Анджей работал в AMD над созданием слоя для совместимости GPU AMD с CUDA, но в 2024 году проект был свернут. В соответствии с условиями контракта и после получения разрешения на публикацию от представителя AMD, Анджей открыл код наработок, созданных во время работы в AMD и позволяющих выполнять CUDA-приложения поверх стека ROCm и runtime HIP (Heterogeneous-computing Interface for Portability).
В прошлом году Анджей был вынужден убрать код из открытого доступа после письма от юристов, давших понять, что разрешение, данное в ходе переписки по email, не имеет юридической силы. После этого Анджей начал работу над новой редакцией ZLUDA, сформированной на основе кодовой базы, существовавшей до начала работы Анджея в AMD. В текущем виде разработка сосредоточена на выполнении приложений, использующих CUDA для ускорения задач, связанных с машинным обучением. Проект пока ограничивается работой на GPU AMD, но в дальнейшем будет адаптирован для GPU Intel.
Оригинал
ZLUDA update Q3 2025 – ZLUDA 5 is here
https://vosen.github.io/ZLUDA/blog/zluda-update-q3-2025/
👏34🔥15👍6🫡2🤡1
🫡
Qualcomm купил Arduino
Пост на сайте Qualcomm
Qualcomm to Acquire Arduino—Accelerating Developers’ Access to its Leading Edge Computing and AI
https://www.qualcomm.com/news/releases/2025/10/qualcomm-to-acquire-arduino-accelerating-developers--access-to-i
Пост в блоге Arduino
A new chapter for Arduino – with Qualcomm, UNO Q, and you!
https://blog.arduino.cc/2025/10/07/a-new-chapter-for-arduino-with-qualcomm-uno-q-and-you/
И вместе они запускают Arduino UNO Q (https://www.arduino.cc/product-uno-q)
- A Linux® Debian-capable microprocessor powered by the Qualcomm Dragonwing™ QRB2210 processor, with AI and graphic acceleration, quad-core performance and camera/audio/display support
- A real-time STM32U585 microcontroller, perfect for precise control and responsiveness
ЗЫ
> Arduino will retain its independent brand, tools, and mission, while continuing to support a wide range of microcontrollers and microprocessors from multiple semiconductor providers as it enters this next chapter within the Qualcomm family
> continuing to support a wide range of microcontrollers and microprocessors from multiple semiconductor providers
Веры в это мало в долгосрочной перспективе, но будем посмотреть
Qualcomm купил Arduino
Пост на сайте Qualcomm
Qualcomm to Acquire Arduino—Accelerating Developers’ Access to its Leading Edge Computing and AI
https://www.qualcomm.com/news/releases/2025/10/qualcomm-to-acquire-arduino-accelerating-developers--access-to-i
Пост в блоге Arduino
A new chapter for Arduino – with Qualcomm, UNO Q, and you!
https://blog.arduino.cc/2025/10/07/a-new-chapter-for-arduino-with-qualcomm-uno-q-and-you/
И вместе они запускают Arduino UNO Q (https://www.arduino.cc/product-uno-q)
- A Linux® Debian-capable microprocessor powered by the Qualcomm Dragonwing™ QRB2210 processor, with AI and graphic acceleration, quad-core performance and camera/audio/display support
- A real-time STM32U585 microcontroller, perfect for precise control and responsiveness
ЗЫ
> Arduino will retain its independent brand, tools, and mission, while continuing to support a wide range of microcontrollers and microprocessors from multiple semiconductor providers as it enters this next chapter within the Qualcomm family
> continuing to support a wide range of microcontrollers and microprocessors from multiple semiconductor providers
Веры в это мало в долгосрочной перспективе, но будем посмотреть
🫡11👏8👎7🔥3
Выложены доклады с DevConf.US 2025
Плейлист
https://www.youtube.com/playlist?list=PLU1vS0speL2aSrq1uHjSlznWnqMWsmWD1
Программа тут
https://www.devconf.info/us/schedule/
Плейлист
https://www.youtube.com/playlist?list=PLU1vS0speL2aSrq1uHjSlznWnqMWsmWD1
Программа тут
https://www.devconf.info/us/schedule/
👍4❤2🫡2🤡1🥴1💊1