Специалисты Bitsight TRACE раскрыли устройство ботнета Fuyao, который использует недорогие Android TV-приставки для автоматической накрутки рекламных просмотров и кликов, а также в качестве резидентских прокси. Исследователи пришли к выводу, что приложения Fuyao поставлялись предустановленными на некоторых приставках H96, вероятно в составе модифицированных прошивок. В качестве возможных каналов такой установки называются кастомизация со стороны OEM/дистрибьютора или реселлера и распространение модифицированных ROM для самостоятельной перепрошивки.

Расследование началось с обнаружения оставленного в прошивках механизма удалённого администрирования. Приставки продолжали обращаться к домену, регистрация которого истекла; после его перехвата исследователи получили телеметрию с моделью устройства, версией прошивки, характеристиками оборудования, MAC-адресом и списком установленных Android-пакетов. Именно благодаря этому удалось одновременно увидеть системный пакет sysserver.systemUpdate и приложения Fuyao.

Наиболее конкретно в отчёте фигурирует H96 Max V11. Один из полученных отчётов идентифицировал устройство как H96_Max_V11 с Android 11; исследователи отмечают, что приложения Fuyao чаще всего обнаруживались именно на H96_MAX_V11. При этом сами авторы предупреждают, что статистика может быть смещена: захваченный ими домен давал видимость преимущественно по старым моделям приставок одного бренда.

За 24 часа через перехваченный сервер прошло 65 957 отчётов примерно от 38 тыс. уникальных MAC-адресов, на которых были обнаружены приложения Fuyao. Однако Bitsight специально оговаривает, что 38 тыс. MAC-адресов нельзя автоматически считать 38 тыс. физических приставок: система умеет подменять идентификаторы устройств. С другой стороны, наблюдение охватывало лишь часть инфраструктуры, поэтому реальное число задействованных устройств может быть больше.

После получения задания приставка могла маскироваться под обычный смартфон: Fuyao подменяет системные свойства Android, сведения об аппаратной платформе и параметры браузерного окружения. В перехваченных данных TV-боксы представлялись устройствами Samsung, Xiaomi, Huawei, Vivo и других производителей. Цель такой маскировки — получить более дорогие рекламные показы и клики и одновременно усложнить обнаружение автоматизированного трафика.

Для поиска рекламных элементов используется несколько механизмов — Android Accessibility, OCR и модели компьютерного зрения. В более новых версиях Fuyao разработчики перешли от преимущественно JavaScript-автоматизации к использованию предварительно обученных ML-моделей. В коде также обнаружены заготовки для Azure GPT-4o, предназначенные для принятия решений о том, куда нажимать и куда переходить дальше, однако на момент исследования этот механизм фактически не был подключён к рабочей цепочке.

Особый интерес представляет система создания сценариев рекламного мошенничества. Операторы построили собственный редактор на базе свободной библиотеки Blockly, распространяемой под Apache 2.0. В визуальном редакторе можно задать целевой сайт, параметры браузера, вероятность клика, очистку кэша, bounce rate и другую логику кампании. После сохранения блоки преобразуются в JavaScript и отправляются на приставки. Bitsight обнаружила около 56 исходных модулей, а в ходе наблюдения получила уже порядка 166 уникальных модулей, включая 109 вариантов логики для конкретных сайтов.

Монетизация не ограничивалась рекламой. Приложение Center превращает приставку в резидентский SOCKS5-прокси, через который может проходить чужой сетевой трафик с использованием домашнего IP-адреса владельца. За одни сутки с известной Bitsight инфраструктурой резидентских прокси пересекалась примерно одна из шести наблюдавшихся приставок Fuyao, а за семь дней — примерно одна из четырёх. Более 90% устройств, работавших только как прокси, имели установленным приложение Center.

Любопытно и распределение нагрузки: анализ функции CheckSelf() показал, что при активном HDMI приставка преимущественно используется как прокси, а когда HDMI неактивен — запускает задачи по накрутке рекламы. Таким образом, вредоносная активность может выполняться преимущественно тогда, когда телевизор фактически не используется владельцем.

Приложения способны не только выполнять удалённые задания, но и передавать на управляющий сервер журналы работы, периодические снимки экрана и даже видеопоток экрана через WebRTC. Управление построено на нескольких уровнях C2-серверов и постоянных WebSocket-соединениях.

Bitsight связала Fuyao с китайской компанией Zhejiang Fengwo IoT Technology Co., Ltd, входящей в Fengwo Group. Исследователи называют четыре независимые группы признаков: пересечение TLS-сертификатов, файлы из внутренней wiki, связи с компаниями, использовавшимися для получения рекламных выплат, и зарегистрированные в Китае патенты. По данным Bitsight, как минимум 6–8 патентов напрямую соответствуют подсистемам, обнаруженным при анализе Fuyao.

Связанная с Fengwo инфраструктура рекламировала более 120 тыс. «AI digital humans». Это число не следует путать с независимо подтверждённым размером ботнета: 120 тыс. — заявление самой компании, тогда как через захваченный Bitsight сервер исследователи наблюдали около 38 тыс. уникальных MAC-адресов. На основе условных десяти кликов по $0,10 и дохода от показов авторы оценили теоретическую выручку сети из 120 тыс. устройств примерно в $150 тыс. в сутки, отдельно предупредив, что часть трафика может отбрасываться антифрод-системами.

H96 Max V11 продаётся на российских маркетплейсах

Названная исследователями модель не является какой-либо редкой китайской приставкой. На момент проверки 8 августа H96 Max V11 продолжает продаваться в России. На Ozon размещена карточка H96 Max V11 на Android 11, а на Wildberries продаётся H96 Max V11; присутствуют и другие предложения этой модели, включая вариант H96 MAX V11 4/64 ГБ. В карточках указывается процессор Rockchip RK3318 и Android 11.

Те же характеристики приводит и официальная страница H96 Max V11: RK3318, Android 11 и варианты с 2/4 ГБ ОЗУ и 16/32/64 ГБ встроенной памяти. Производитель отдельно предлагает OEM/ODM-кастомизацию, в том числе изменение boot image, launcher, интерфейса, функций и состава приложений прошивки. Это согласуется с предположением Bitsight о возможности появления Fuyao на этапе кастомизации ROM, но само по себе не является доказательством участия производителя H96 в установке вредоносного ПО.

Важно также не переносить выводы исследования на все продающиеся H96 Max V11. Bitsight обнаружила Fuyao на устройствах с таким идентификатором модели и пишет, что приложения чаще всего встречались именно там, однако не исследовала партии конкретных российских продавцов. Поэтому по одной карточке на Ozon или Wildberries определить наличие Fuyao невозможно — оно зависит от конкретной прошивки и цепочки поставки.

Привет. У меня работает VDS с одним гигом, и, судя по всему - оперативки не хватает для нормальной работы: глючит всё - и убунта, и лайвы, и Минт и др. Начинал я с Убунты 18, но современная 26 не заработала (естесснно). Но я хочу современный дистрибутив. Люди мне советуют всякие легковесные, но - десктопные, а мне, как-то, не надо. Да - я мог-бы иметь возможность запускать графику по желанию, но серверный пакет предполагается «ближе к телу». Собственно из задач: прокси-сервер (для чего, собственна, я его и покупал)(потому и мало оперативки, - дешёвый); развлекухами идут сайты, хранилище… Убунту советовали как лёгкий для новичка. Прошу посоветовать удобный серверный дистрибутив, современный, для малой оперативы.

Вводные: ядро от стоковой Android прошивки устройства на MediaTek. Исходников нет. Цель: пропатчить уже собранное ядро, чтобы оно не забирало bootargs из device tree или загрузчика, но использовало свои из header.

Маловероятно, но есть тут кто шарит за подобное? Может есть у кого опыт. Или, может, кто-то знает профильные форумы\статьи.

Помню давние времена, это был Debian 4, прекрасные третьи кеды, Celeron, HDD диски, какой-то древний GeForce и летающий Linux.

Прошли десятилетия. Из статьи в статью копипастится мантра «Linux для слабого железа», так же она повторяется и в комментариях, непременно сопровождаясь аннотацией «Пишет Вася, 32 Gb RAM, SSD Tb, GeForce RTX 5060 Ti». А я тем временем наблюдаю на своем железе какую-то ужасающую деградацию работы десктопного линукса. И если лет 5 назад это еще не так заметно было, то в последние года два это совсем уже из ряда вон выходящее и описывается одним словом: «безбожно тормозит». Разумеется мне эксперты вторят в один голос дескать у меня руки кривые. Возможно. Но что-то то мне подсказывало, что дело то не совсем в руках, ведь пользуюсь я линуксом то давненько и почему-то раньше, когда был менее опытным, все работало хорошо из коробки.

Итак, я консервативный технический аскет, мое домашнее железо сейчас это HDD (ни разу не покупал домой SSD), средненький проц и 8Gb RAM, видеокарта GTX 970. Это позволяет видеть проблемы сразу, собственно инженеры подтверждают этот тезис, см. https://news.ycombinator.com/item?id=41499633. Я начал искать, почему я наблюдаю отчетливо плохую работу домашней системы на современных дистрибутивах Linux. Первой проблемой стал snap. На таком железе всякие mint и ubuntu ушли в мусорку очень быстро, так как там используется оный, а это мазохизм, если у тебя не SSD и куча оперативы (да и вообще явный продукт копроэкономики). С flathub получше, но тоже нет. Эсперты на этом месте скажут «Ты что идиот? Купи SSD, HDD это прошлый век». У меня бывают долгие отсутствия или я могу попросту положить HDD на полку. С HDD я уверен что данные останутся, с SSD нет, см. статью о потере данных без питания у SSD https://www.ixbt.com/news/2025/04/20/dva-goda-bez-pitanija-issledovanie-podtverdilo-riski-dolgosrochnogo-hranenija-dannyh-na-ssd-bez-pitanija.html. А еще прекрасное, в век LLM SSD теперь ушатываются на раз https://4pda.to/2026/06/23/457958/nejroset_codex_okazalas_sposobna_ubit_ssd_menshe_chem_za_god/. Разумеется я не стал использовать всякие BTRFS, ZFS, XFS и подобные фс, которые уже давно заточены под SSD. Оставил ext4.

А дальше явных проблем я не нашел. Но как быть, если сетап окружения примерно такой же как раньше (использую браузер и IDE), а результат разный в разы? Ну не может же быть дело только в HDD, откуда бы такая деградация. Оказывается видимо может. Я нашел прекрасный тред https://www.linuxquestions.org/questions/slackware-14/disk-thrashing-on-5-15-x-kernels-but-not-on-4-4-x-or-4-19-x-kernels-4175713190/. В общем тенденция такова, что корпы очень сильно отравляют ядро в угоду корпоративным интересам (и корпоративного уровня железа), а домашнее железо игнорят или не сильно на него обращают внимание и с каждой свежей версией ядра на домашнем железе работа Linux деградирует. Видимо сейчас накопилось достаточно проблем, чтобы это стало визуально заметно. Что там напихали со времен 5.15 ядра, каких регресионных изменений, бог его знает, заниматься этим нет ни времени ни желания.

И я решил провести эксперимент, и поставли Debian 10 c бекпортами (ядро 4.19), форматнул с ext2(boot) и ext3, накатил Trinity Desktop https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions#TDE_R14.1.x_series и о чудо, все залетало! Браузер и IDE стали открываться мгновенно, сайты работают шустро, графическая оболочка откликается молниеносно, ощущения что я вернулся во времена Debian 4!

А что насчет старого софта спросите вы, а что, вы не умеет собирать свежий софт из исходников?…

Итого, сижу и наслаждаюсь старым добрым Linux в пятницу и в очередной раз читаю экспертов на сайтах: «У тебя руки кривые, у меня все работает на моей Ubuntu». Разумеется, они абсолютно правы. Всем добра :)

P.S. Жду клоунов в реакциях

Перемещено hobbit из talks

Я наткнулся на любопытную статью, в которой авторы размышляли на тему ИИ-управляющего. Причиной этому послужили утверждения Сэма Альтмана (директор OpenAI), что LLM способен выполнять роль управляющего в компании, и несколько организаций, в частности, польская компания производящая напитки Dictador и китайская компания, разрабатывающая компьютерные игры NetDragon Websoft, прямо сейчас проверяют это на правдивость. Во всяком случае, представители этих компаний заявляют, что некоторые серьезные решения в их компаниях принимает ИИ. Марк Цукерберг также надеется часть своих функций как управляющего переложить на плечи ИИ.

И я очень легко могу представить, что в 1С может когда-нибудь появиться сквозная интеграция с LLM, который будет отслеживать и оценивать все записи в этой системе, а также давать указания работающим. И таким образом мы получим реальных ИИ-начальников.

CachyOS Сегодня, 06.08.26 при выполнении команды pacman -Syu выдало следующее -

предупреждение: fatal error from archlinux.gay, skipping for the remainder of this transaction
ошибка: не удалось получить файл 'cachyos-core-v3.db' из archlinux.gay : Could not resolve host: archlinux.gay
ошибка: не удалось получить файл 'cachyos-extra-v3.db' из archlinux.gay : Could not resolve host: archlinux.gay
ошибка: не удалось получить файл 'cachyos.db' из archlinux.gay : Could not resolve host: archlinux.gay```


Как оказалось команда cachyos-rate-mirrors добавляет в mirrorlist archlinux.gay (Russia Mirror much thanks to quinowell and haku.host) с содержимым про гомосеков и лесбиянок и ещё несколько зеркал с похожими названиями

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

Разработчики языка программирования Rust утвердили правила применения AI-ассистентов в проекте. За отдельными исключениями, правила запрещают передачу кода, сгенерированного через AI, но разрешают использование AI для анализа, изучения, рецензирования и проверки кода. Правила распространяются только на основной репозиторий rust-lang/rust, и отдельно утверждаются командами разработчиков субмодулей, подветок и зависимостей из каталога crates.io.

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

Запрещено применение AI для формирования комментариев, отчётов о проблемах и описаний изменений, публикуемых от имени участника. При этом разрешено цитирование выдачи от AI с явной пометкой, что контент сформирован через AI (например, прикрепление результатов диагностики через AI). Запрещено создание документации через AI. При рецензировании запрещено рассмотрение выводов AI как достаточных для приёма или отклонения изменений — результаты проверки через AI могут носить только рекомендательный характер.

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

В рамках эксперимента допускается передача заранее согласованных, некритичных, досконально проверенных и хорошо протестированных изменений, изначально сгенерированных через AI. Перед отправкой pull-запроса c подобным изменением, разработчик должен заранее договориться с рецензирующими. Предлагаемые изменения должны помечаться меткой «ai-assisted» и могут затрагивать вторичные инструменты, такие как tidy и linkchecker, но не должны касаться ключевых возможностей и элементов языка. Для отслеживания результатов эксперимента изменения предписано отправлять в отдельный приватный Zulip-канал, доступ к которому предоставлен только участникам проекта.

Современные информационные технологии кардинально изменили способы хранения и распространения профессиональных знаний. В медицинской сфере это особенно важно, поскольку объем научной информации постоянно увеличивается, а специалистам требуется быстрый доступ к актуальным данным. Именно поэтому разработка специализированных цифровых библиотечных платформ становится одним из приоритетных направлений развития медицинской информационной инфраструктуры.

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

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

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

Электронно-медицинскую библиотеку сделали в Татарстане (разработано государственной организацией РМБИЦ).

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

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

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

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

https://rmbic.tatarstan.ru/

Перемещено hobbit из development

Всем привет.

Почему-то перестали отображаться эмодзи практически во всей системе. Их нет ни для пользователя, ни под рутом. До того, как они пропали, мне пришлось настраивать ШГ в fontconfig через qt5ct, поскольку у меня пропало сглаживание ШГ в запущенных через Wine программах. И пока я подбирала настройки для относительно приемлемого отображения ШГ в Wine (а заодно и в других программах, зависящих от содержимого пользовательского файла fonts.conf, во всей системе пропали эмодзи - вместо них сейчас вообще ничего нет, даже прямоугольников или хотя бы пробелов. Причём сами шрифты с эмодзи (Noto Color Emoji, Emoji One, Segoe UI Emoji) в системе есть, и установлены они в /usr/share/fonts/truetype. Перенос этих шрифтов в папку пользователя ничего не дал, как и удаление fonts.conf вместе с кэшем ШГ, и редактирование/удаление конфигов из /etc/fonts/conf.d. И такое уже повторяется во второй раз, но в первый раз, когда такое случилось, эмодзи вернулись также внезапно, как и исчезли.

И ещё заметила, пока создавала этот тред, что Chromium и Seamonkey могут отображать эмодзи, однако в браузере Luakit и других программах (Leafpad, Libre Office, Geany, iBus) их не видно. При этом ввести эмодзи через iBus всё равно возможно, хоть и вслепую.

В чём дело? Проблемы с fontconfig? Или с чем? Что с системой не так? И как вернуть эмодзи на место?

ОС Runtu 18.04 x32, если что.

Я хочу сделать подсветку кода регулярных выражений и частично сделал (пример-исходник), но мне хотелось сделать типа отличать одни скобки от других, например первая скобка тёмнокрасная, вторая светлокрасная, то есть видеть какая закрытая скобка принадлежит какой открытой скобке, то есть чётные скобки светлокрасные, нечётные тёмнокрасные. Казалось бы алгоритм не сложный, нашёл скобку, добавь +1 к счётчику и бинарный переключатель цвета инвертируй и задай цвет из массива с индексом 1, потом из 0, потом из 1 и т.д. Закрывающие также считаем -1 к счётчику скобок, и тоже если чётный, то один цвет, если нечётный то другой. Ну в общем, когда делал запутался и не работало. Мне предложили сделать со стеком, да почти тоже, со своим не разобрался вставил чужой вариант, но случилось однажды прога упала (при вставке регвыра в поле с подсветкой) и вот думаю, надо со своим разобраться, чтобы понимать в совершенстве как работает и не думать что он является причиной падения.

Всех приветствую.

Хотел обсудить один вопрос. А именно система для сборки прошивок.

Есть много приборов где есть прошивка на базе линукса. У приборов есть архитектура проца (например 3 разных). Разные версии железа. Разный функционал. Есть варианты, когда один и тот же функционал может быть реализован на разном железе. А бывает что на одном железе делают разный функционал (да, это про fpga).

И вот, для всего этого зоопарка нужно нечто, что позволит быстро и без проблем собирать прошивки.

Как я себе это вижу.

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

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

Получается, что прошивка собирается из этих бинарных пакетов. Если надо что-то поменять в прошивке. Собираем новую версию какого-то пакета и потом заново прошивку.

Я не все потребности озвучил, но это пока самые главные.

Резюмирую немного главное:

1. сборка из исходников с заданной версией, архитектурой, конфигом
2. сборка из git репы, с заданным тегом, архитектурой, конфигом
3. хранение в централизованном хранилище
4. централизованное хранение конфигов для сборки прошивки из пакетов для железки и ее версии
5. сборка любой версии прошивки в любой момент из пакетов

И вот теперь вопрос. А что в мире уже придумали на такой случай?

Что я уже видел-гуглил.

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

Пример:

int main()
{
  int fd;
  char *filename;

  filename = malloc_filename();
  fd = open(filename, O_RDWR);
  if (!fd) {
    perror(filename);
    /* free(filename); */
    return 1;
  }
  
  doing_something(fd);

  /* free(filename); */
  /* close(fd); */
  return 0;
}

Что плохого, если я не сделаю free() и close()? Какие подводные камни? Я раньше думал, что valgrind ругается, если сам не сделал free(), но нет (не исключено, что я неправильно воспользовался valgrind).

Арч, КДЕ.

Поставил я себе в настройка переключение раскладки клавиатуры на капс. Но работает, но при нажатии shift+caps оно одновременно зажимает капс и переключает раскладку. На предыдущих системах работало нормально.

Вопрос: как настроить комбинацию shift+caps так, чтобы оно зажимало капс, но не переключало раскладку. Интересует настройка через КДЕ в первую очередь, но можно и другие варианты кидать.

Перемещено hobbit из general

Всем добра! Заранее прошу не кидаться в меня камнями, поскольку с linux знаком на базовом уровне, однако этих знаний достаточно для разворачивания Wireguard на VDS-сервере. Нестандартность моей проблемы осложняет тот факт, что маршрутизатор в домашней сети подключен к провайдеру по PPPoE. Итак, кратко к сути проблемы. После несложной настройки WG-сервера с конфигурацией файла wg0.conf

[Interface]
PrivateKey = <тут указал приватный ключ>
Address = 172.20.4.1/24,fd11:5ee:bad:c0de::a09:da01/64
MTU = 1412
ListenPort = 51828

[Peer]
PublicKey = <тут указал публичный ключ>
PresharedKey = <тут сгенерился ключ шифрования>
AllowedIPs = 172.20.4.10/24,fd11:5ee:bad:c0de::a09:da0a/128

и последующей настройки конфигурации «клиента»:

[Interface]
PrivateKey = <тут указал приватный ключ>
Address = 172.20.4.1/24, fd11:5ee:bad:c0de::a09:da0a/64
DNS = 9.9.9.9, 149.112.112.112
MTU = 1412

[Peer]
PublicKey = <тут указал публичный ключ>
PresharedKey = <тут сгенерился ключ шифрования>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 2.27.31.48:51828 (указал белый IP-адрес VDS-сервера и порт)
PersistentKeepalive = 25

От провайдера при успешном подключении PPPoE маршрутизатор получает IP-адрес 172.31.4.204. При подключении к VPN-туннелю проблем не возникает, однако, трафика от сервера до клиента как такового нет (никакие страницы в браузере не прогружаются). Погуглив, уменьшил размер MTU как в конфигурации файла wg0.conf на сервере, так и на клиентской стороны со стандартного значения 1500 до 1412 - не помогло. Также на стороне «клиента» добавил параметр «PersistentKeepalive = 25», который отправляет пустой пакет серверу для поддержания активного подключения, но это так же не помогло. Фаервол на сервере по умолчанию отключен, как и правила межсетевого экрана на маршрутизаторе (Keenetic Giga). Подскажите, куда ещё копнуть для решения описанной проблемы.

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

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

Есть ощущение, что такое началось после обновления с предпоследней версии блоба на последнюю…

Достался мне старый проект qt2 от предыдущих разрабов … Там в старом QT2 под linux-embedded необходимо генерить файлы .qpf для шрифтов… я научился это делать под Linux … Можно это сделать под Виндой ? Кто то может научился ?

В целом: меня утомили централизованные кастодиальные боты Telegram кошельки с закрытым исходным кодом и отсутствием реальной двухфакторной аутентификации для транзакций. И я сделал свой.

• Вход: Telegram OAuth в Telegram или вход по электронной почте в другом месте.

• Доступ на основе учетной записи: используйте учетную запись Telegram или электронную почту вместо самостоятельного управления закрытым ключом или мнемонической фразой.

• Фичи: просмотр активов, депозит, снятие средств, обмены (swap), газовый аккаунт и P2P-обмен стейблкоины на фиат (только русская локализация, небольшие суммы)

• Меньшая поверхность атаки для децентрализованных приложений: Outruna намеренно не предоставляет общего подключения кошелька для сторонних веб-сайтов Web3. Это исключает распространенный путь фишинга и вредоносной подписи, но не устраняет все риски, связанные с кошельком.

• Поддержка токенов: нативные активы и тщательно отобранный список токенов, в основном основные активы и стейблкоины. Пользователи могут добавлять собственные токены ERC-20 после их проверки.

• Поддерживаются шесть сетей EVM: Ethereum, Base, Polygon, Optimism, Avalanche и Arbitrum.

• Проверка адресов: адреса назначения используют данные о репутации Rabby, а также собственные данные о рисках, если таковые имеются. Для опасных адресов требуется явное подтверждение.

• Защита встроенного кошелька Privy: кошелек принадлежит пользователю, а не является депозитарным балансом Outruna. Privy разделяет ключевой материал на зашифрованные части и восстанавливает их только временно для авторизованной подписи, поэтому Outruna не хранит полный закрытый ключ пользователя во фронтенде во время обычного использования.

• Разделение по газу: используется нативный газ, если он доступен. Также можно использовать газовый аккаунт.

• Двухфакторная аутентификация транзакций: пользователи могут дополнительно включить многофакторную аутентификацию Privy для действий с кошельком. В Outruna это защищает подписание транзакций; Privy также применяет многофакторную аутентификацию, когда ключ встроенного кошелька используется для подписи сообщений, экспорта или восстановления. TOTP работает с Google Authenticator и совместимыми приложениями-аутентификаторами и остается отключенным до завершения регистрации.

• Подписанные сборки: производственные сборки генерируют и проверяют манифест для сгенерированных ресурсов.

• Открытый исходный код, для получения дополнительной информации см. GitHub.

Попробовать можно как через Telegram @outruna_bot так и в браузере

Я старался сделать как можно более удобный фронтенд для кошелька, но я больше все-таки backend’ер и писатель логики сервисов, поэтому проблемы с интерфейсом наверняка будут, Telegram Web App на Preact

Также да, если не трудно прошу по возможности поднять вверх на ProductHunt другие мои проекты.

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

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

Выпущен консольный файловый менеджер Midnight Commander 6.0.3 (mc6), представляющий собой форк GNU Midnight Commander 4.8.33, расширенный поддержкой панельных плагинов и поставляемый со встроенным PTY-терминалом mcterm. Интегрированный в mc6 фреймворк панельных плагинов позволяет отображать в панелях не только файловые системы, но и контейнеры, Git-репозитории, базы данных и объекты удалённых хранилищ. Код проекта написан на языке Си и распространяется под лицензией GPLv3+. Готовые пакеты подготовлены для Debian и Ubuntu, Fedora и RHEL, а также Arch Linux в форматах DEB, RPM и pkg.tar.zst. Для Gentoo дополнительно предоставлен ebuild для установки через локальный overlay.

В состав выпуска вошли плагины для работы с архивами, FTP/SFTP/FTPS, Samba, Git, Docker, Kubernetes, MongoDB и S3-совместимыми хранилищами. Плагины поддерживают стандартные файловые операции, а переработанная поддержка архивов на базе libarchive заметно (в десятки или сотни раз) ускоряет обработку больших архивов.

Во встроенный текстовый редактор mcedit добавлены возможность сворачивания блоков кода, браузер истории Undo/Redo, средства управление макросами и поддержка сохранения файлов через sudo. В разы улучшена производительность при работе с очень длинными строками.

Просмотрщик mcview получил древовидное представление JSON, YAML и XML, интерактивную фильтрацию содержимого, базовую поддержку отображения разметки Markdown и режим воспроизведения файлов с ANSI-последовательностями.

В состав включён встроенный PTY-терминал mcterm с собственным эмулятором терминала, предназначенный для замены традиционного subshell-механизма.

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

Исследователи из компании JFrog проанализировали опубликованные на днях 55 отчётов об уязвимостях в SQLite. На основании данных отчётов организация MITRE присвоила всем проблемам CVE-идентификаторы. Три проблемы получили статус критических, а самой опасной уязвимости (CVE-2026-51302) компания Red Hat присвоила в своих базах уровень 10 из 10, а SUSE — 9.8 из 10. Детальное изучение заявленных ошибок показало, что 54 из 55 уязвимостей, включая отмеченную критическую проблему, являются фикциями и вызваны галлюцинациями AI-модели.

В самой опасной уязвимости было заявлено обращение к памяти после её освобождения в функции exprComputeOperands(), приводящее к возможности выполнения кода при выполнении специально оформленного запроса. Разбор показал, что данной функции не существует в кодовой базе SQLite 3.41, в которой заявлено наличие проблемы (данная функция появилась значительно позднее). Источником возникновения уязвимости было заявлено оставление висячего указателя в функции sqlite3ReleaseTempReg(), но её логика работы не подразумевает освобождением памяти и ограничивается пометкой памяти для повторного использования, что исключает возникновение проблем класса use-after-free в силу архитектуры.

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

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