Вот несколько проблем, с которыми я сталкиваюсь в современном C++:

- Более 95% сообщений об ошибках компилятора С++ выглядят гораздо хуже, чем сообщения об ошибках всех остальных языков. И я тут даже не преувеличиваю. Сообщения об ошибках в C++ хуже всех

- Инструменты для сборки проектов — это просто ужас. Я совершенно не понимаю — почему так тяжело пользоваться инструментами сборки C++-проектов, и почему люди, которые их создают, принимают наиглупейшие решения по поводу этих инструментов

- У производителей компиляторов нет стимула следовать стандартам. Я говорил о том, что в Clang имеется ошибка в std::source_location, и это — отличный пример тех проблем, с которыми мы все иногда сталкиваемся. Я твёрдо уверен в том, что комитету по стандартизации языка нужно начать публиковать список компиляторов, в которых не исправлены ошибки, подобные этой

- Язык чрезвычайно сложен из-за его истории. В С++ имеется масса устаревших конструкций, через которые приходится продираться для того чтобы найти что-то ценное. У меня возникает такое ощущение, что это похоже на то, как если бы C++ был бы тремя языками (или ещё большим их количеством), похожими на JavaScript

- Я люто ненавижу RAII. Я встречаюсь с множеством ситуаций, где RAII мешает решать настоящие задачи инициализации сущностей. Причём, мешает настолько, что эта «возможность» C++ становится больше похожей на какой-то сбой, а не на что-то реально полезное

С++ — это настоящий кайфǃ
https://habr.com/ru/companies/wunderfund/articles/874216/

Оригинал
C++ Is An Absolute Blast
https://learncodethehardway.com/blog/31-c-plus-plus-is-an-absolute-blast/

Неприятная история случилась с Kong Ingress Controller в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig. Таймлайн происходящего был таков:

1) 28 августа 2024 года разработчики из Kong исправляют свои пайплайны меняя pull_request на pull_request_target
2) 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target, а значит были уязвимы.
3) Спустя почти два месяца, а именно 23 декабря 2024 года атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub, проэксплуатировав уязвимость в одном из репозиториев.
4) Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предудыщем шаге access token. Они запушили образ docker.io/kong/kubernetes-ingress-controller на Dockerhub с тегом 3.4.
5) 29 декабря 2024 года 4 пользователя отметили в issue на GitHub, что запуск Kong Ingress Controller приводит к аномально высокой нагрузке на ЦП.
6) 2 января 2025 мейнтейнеры подтвердили, что образ был скомпрометирован, а вунтри него содержался XMRig.

Более подробно о всей ситуации можно почитать в блоге KIC тут. Также было опубликовано YARA правило для обнаружения таких нагрузок.

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

"Люблю" такое.
 
- Вхожу в ЛК ДОМ.РУ 
- Выбор по номеру телефона или номеру договора
- Логинюсь по номеру договора
- Просит подтвердить телефон так как скоро будет доступен только вход по номеру телефона
- Подтверждаю
- Перелогинивается под номером телефона и вываливает список всех старых договоров которые к этому номеру привязаны
- Просит выбрать под каким договором залогиниться
- Логинюсь под номером договора
🤯🤯🤯🤯🤯🤯
PROFIT!

https://xn--r1a.website/patchcord/3183

Ранее я писал о баге Haproxy: после рестарта треды не завершались, что приводило к их накоплению, память иссякала и приходил OOM Killer.

Проблему решали костылем — директива hard-stop-after принудительно завершает треды после рестарта.

Но Haproxy не сдается и наносит ответный удар!

Причины еще предстоит выяснить, поэтому это скорее "заметка с полей"

Симптомы схожи: утечка памяти.

Но сбой наступает когда (это гипотеза) заканчивается память для TCP-буферов (net.ipv4.tcp_mem) - ядро с переменным успехом пытается освободить память для новых / существующих соединений, что приводит к затруднению в сетевых взаимодействиях.

На скрине такой период отмечен красным прямоугольником.

# sysctl net.ipv4.tcp_mem
net.ipv4.tcp_mem = 90435  120582  180870

Где 180870 - максимальное значение (в страницах памяти) под все TCP сокеты в системе, что равно ~ 706MB.

Оказалось, что система насыщается "повисшими" соединениями, чьи буферы сокетов содержат данные:

# ss -ntOai | awk '{for(i=1;i<=NF;i++)if($i~/^lastsnd:/){split($i,a,":");print a[2], $2, $4, $5}}' | sort -n | tail 

#lastsnd # Recv-Q #Src #Dst
234423668 157355 10.11.12.4:57354 10.11.6.123:80
235316436 302417 10.11.12.4:56232 10.11.6.124:80
238200680 301585 10.11.12.4:37940 10.11.6.124:80
238726828 300103 10.11.12.4:58944 10.11.6.124:80
243816724 297015 10.11.12.4:51700 10.11.6.125:80
251456440 302959 10.11.12.4:52324 10.11.6.125:80
252237780 302464 10.11.12.4:47786 10.11.6.123:80
257868244 163453 10.11.12.4:41568 10.11.6.125:80
259905196 300433 10.11.12.4:40202 10.11.6.123:80
261307944 214022 10.11.12.4:54888 10.11.6.123:80 # это ~ 72 часа

где:
* lastsnd - время с последней отправки данных, в милисекундах;
* Recv-Q - объем не прочитанных данных, в байтах.

А раз есть не прочитанные данные, значит таймер TCP keepalive не взводится:

static void tcp_keepalive_timer (struct timer_list *t)
{
  ...
  /* It is alive without keepalive 8) */
  if (tp->packets_out || !tcp_write_queue_empty(sk))
    goto resched;
  
  ...
  
  resched:
  inet_csk_reset_keepalive_timer (sk, elapsed);
  goto out;
  
  ...
  
  out:
    bh_unlock_sock(sk);
    sock_put(sk);
}

Был бы повод, а костыль найдется!

Ребята из CloudFlare писали в свое время статью When TCP sockets refuse to die, где в виде решения предлагалось использовать опцию сокета TCP_USER_TIMEOUT:

...it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged, or buffered data may remain untransmitted (due to zero window size) before TCP will forcibly close the corresponding connection and return **ETIMEDOUT** to the application...

В свою очередь Haproxy поддерживает ее через tcp-ut.

Посмотрим, как себя покажет.

tags: #tcp #linux #kernel #troubleshooting

Когда я зашёл в эту issue почитать комментарии, я даже не догадывался что меня там ждёт 🌝

VLC 3.X.X - HTTP Proxy Connection ("--http-proxy")
https://code.videolan.org/videolan/vlc/-/issues/26548#note_303823

Пятница была вчера, но пусть будет и сегодня

Я сам не фанат серии GTA (последняя версия в которую я играл это "GTA 2: Беспредел" 🌝), но тут ребятЫ из Revolution Team завезли мод, который выглядит просто прекрасно

за два дня до релиза Take-Two Interactive удалили наш YouTube-канал без каких-либо предупреждений или попыток связаться с нами.
. . .
В развитие канала было вложено огромное количество сил и времени, включая сотни часов стримов, посвящённых разработке мода. Кроме того, мы утратили связь с нашей зарубежной аудиторией, которая составляла значительную часть сообщества. Тизер-трейлер GTA Vice City Nextgen Edition набрал более 100 000 просмотров и 1 500 комментариев меньше чем за сутки.
. . .
Изначально планировалось выпустить модификацию, которая требовала наличия оригинальной игры, чтобы соблюсти уважение к издателю. Но за эти два дня мы полностью пересобрали проект и теперь он доступен в виде готового «независимого комплекта для установки». Просто скачиваете, устанавливаете и играете. Никаких сложностей с совместимостью версий, так как теперь мод полностью автономный.

https://xn--r1a.website/revteam/432

Ссылки на трейлер
https://www.youtube.com/watch?v=7hqwmq6XT6o
https://vk.com/video-28896333_456239228

Торрент доступен тут (+ скину в комменты)
- https://xn--r1a.website/revteam/433
- https://drive.google.com/file/d/1MDMlOefYoChx6mjkfwuVx0rS6Q2pRjgl/view

В 2024 году я потратил много времени на изучение безопасности расширений
К сожалению в интернете не было единого ресурса по безопасности расширений Chrome.
Поэтому я его сделал!
На данный момент содержит самые используемые мною техники, некоторые из них кажется не применялись до меня.
Так же ресурс содержит базовое введение в безопасность расширений и их структуру.
Помимо прочего так же буду заливать туда баги связанные с extension в самом Chromium, первый мини врайтап на мою CVE-2024-10229.
Make Chrome Extension Safe Again!
https://extensions.neplox.security/

За распространение порнографии в виде snap-пакетов, очевидно.

Проект DistroWatch сообщил о блокировке своей новостной группы в Facebook* и удалении некоторых публикаций с пометкой, что они способствуют распространению, созданию или размещению вредоносного ПО. Попытка отправить апелляцию об ошибочной блокировке не подействовала и привела к блокированию учётной записи создателя группы.

В Facebook наблюдается блокировка публикаций со ссылками на некоторые Linux-ресурсы
https://www.opennet.ru/opennews/art.shtml?num=62632

Starting on January 19, 2025 Facebook's internal policy makers decided that Linux is malware and labelled groups associated with Linux as being "cybersecurity threats". Any posts mentioning DistroWatch and multiple groups associated with Linux and Linux discussions have either been shut down or had many of their posts removed.

We've been hearing all week from readers who say they can no longer post about Linux on Facebook or share links to DistroWatch. Some people have reported their accounts have been locked or limited for posting about Linux.

The sad irony here is that Facebook runs much of its infrastructure on Linux and often posts job ads looking for Linux developers.

Unfortunately, there isn't anything we can do about this, apart from advising people to get their Linux-related information from sources other than Facebook. I've tried to appeal the ban and was told the next day that Linux-related material is staying on the cybersecurity filter. My Facebook account was also locked for my efforts.

https://distrowatch.com/weekly.php?issue=20250127#sitenews

I do confirm that i explicitly tested this with my super unused facebook account, just stating that i was testing restrictions on talking about Linux, the text was: """I don't often (or ever) post anything on Facebook, but when I do, it's to check if they really, as announced on hckrnews, are restricting discussing Linux. So here's a few links to trigger that: https://www.qubes-os.org/downloads/ ... https://www.debian.org/releases/stable/""" and indeed within seconds I got the following warning: """ We removed your post The post may use misleading links or content to trick people to visit, or stay on, a website. """. This is one massive wow considering how much Facebook runs on Linux.

https://news.ycombinator.com/item?id=42840143

Reports show that "multiple groups associated with Linux and Linux discussions have either been shut down or had many of their posts removed." However, we tested a few other Facebook posts with mentions of Linux, and they didn't get blocked immediately.

Facebook flags Linux topics as 'cybersecurity threats' — posts and users being blocked
https://www.tomshardware.com/software/linux/facebook-flags-linux-topics-as-cybersecurity-threats-posts-and-users-being-blocked

ЗЫ
> Facebook*

OpenNet * поставил, а то что принадлежит Meta Platforms, которая была признана властями России экстремистской и запрещена не написали 🌝