You may be familiar with Version 1, which is written in Rust. So, why re-write it in Go?

Ultimately, treefmt is spending most of it's time shelling out calls to the underlying formatters. This process is just as fast/performant in Go as it is in Rust.

The remaining tasks are processing some cli args and parsing a config file. Do we really need something as heavy duty as Rust for that?

Despite all this, you can make good, sane arguments for continuing with Version 1 in Rust instead of a re-write. So here's a bad argument.

Brian wanted to improve performance by moving away from a Toml cache file, introduce pipelines for applying multiple formatters against the same file set, and add an extensible approach for how treefmt walks file systems. He knows Go much better than Rust.

zimbatm thought it was a good idea too.

So here we are 🤷.

Потерпевший — мой брат, узнал о том, что он должен банку ВТБ 1.7 млн за автокредит только вчера. В почтовом ящике обнаружил письмо от банка с требованием начать вносить платежи по договору на автокредит от апреля этого года. Этим банком он года с 2015 не пользовался, в офисы не ходил, по счетам движений не было, да и счет был тоже открыт под теоретическую ипотеку, которая с этим банком так и не состоялась.

Пришел в отделение узнать, что за хуйня, точно ли ваше письмо? Да, говорят, вот тебе твой договор, вот график платежей, пора начинать платить. В банке им пишется претензия, т.к. пока вообще не в курсе что и как, о том, что нихуя, я не оформлял, номер, на который оформлен договор, давно не мой. Прошу кредит с меня снять, ебитесь с мошенником сами. Пока банком принято, ответа от него еще нет.

Дальше идет в салон МТС узнать, что вообще с этим номером, которым уже года с 2019 не пользовался. МТС говорит, с августа 2023 этот номер больше не ваш. А в апреле 2024 его оформили на новое лицо. Никаких выписок по нему не дадим, даже за тот период, когда он был ваш, обращайтесь в головной офис, у нас лапки.
. . .
У ВТБ недавно была очередная утечка персональных данных, ходили даже скрины на пикабушках в начале года, что в тг–каналах продают данные. Пока не видел, что там за данные были, но предположение, по ним можно было сделать выборку о неактивных клиентах и их номеров телефонов.

Затем ищется на сайтах операторов, можно ли купить этот номер.
. . .
А дальше, заполучив нужный номер клиента, который в кабинет ВТБ сто лет даже не заходил, начинается самое охуенное, такого пиздеца похуизма со стороны ИБ я не встречал даже в мелких региональных банках.

Давайте вначале представим, что в таком случае делает, например, Тинькофф или Сбер, сталкивался с заменой симки, поэтому на личном опыте. После замены сим–карты войти в приложение не могу, Сбер заставил зайти в офис по причине противодействия мошенничеству, ок, зашел, паспорт показал, подтвердил, что сим–карту менял — разблокировали. Тинькофф поебал на поддержке, кодовое слово, какие–то еще вопросы — разблокировали.

Теперь случай курильщика ВТБ. Как зайти в онлайн–банк, если для этого нужен логин? Наверное, нужны связи с подкупленным сотрудником банка? Нет. Может быть, эти данные были в той утечке? Нет. Возможно, достаточно знать номер телефона и зайти по нему как логину? Снова нет. 

Звоним на номер 1000 с привязанного к банку номера и говорим роботу одно слово — "Ты пидор!", а нет, это два слова. Тогда "Логин". Вуаля, записывайте, ваш логин — ebat_ty_loh_777, спасибо за ваш звонок. 

Далее все просто, вот логин, забыл пароль, восстановить, введите номер из смс, добро пожаловать в наш банк.

Если подытожить, первое разочарование от Flipper Zero продлилось недолго. Это устройство быстро развивается как платформа, и, пожалуй, сейчас я был бы готов заплатить за него даже больше, чем пару лет назад.

Не скажу, что этот гаджет нужен всем и каждому. Я так и не нашел ему достойного применения в повседневной жизни. Да и специалистам, которые ломают веб, он вряд ли пригодится. Но для физического проникновения на объекты клиентов это инструмент из серии must have. Только не воспринимайте Flipper как панацею: нужно трезво оценивать его возможности и ограничения.

This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function
that is directly called by sshd's SIGALRM handler. In other words:

- OpenSSH < 4.4p1 is vulnerable to this signal handler race condition,
  if not backport-patched against CVE-2006-5051, or not patched against
  CVE-2008-4109, which was an incorrect fix for CVE-2006-5051;

- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable to this signal handler race
  condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added
  to sigdie() by the patch for CVE-2006-5051 transformed this unsafe
  function into a safe _exit(1) call);

- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again to this signal handler
  race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was
  accidentally removed from sigdie()).

This vulnerability is exploitable remotely on glibc-based Linux systems,
where syslog() itself calls async-signal-unsafe functions (for example,
malloc() and free()): an unauthenticated remote code execution as root,
because it affects sshd's privileged code, which is not sandboxed and
runs with full privileges. We have not investigated any other libc or
operating system; but OpenBSD is notably not vulnerable, because its
SIGALRM handler calls syslog_r(), an async-signal-safer version of
syslog() that was invented by OpenBSD in 2001.

apt-get update
apt-get install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wget https://github.com/openssh/openssh-portable/archive/refs/tags/V_9_8_P1.tar.gz
tar -xzf V_9_8_P1.tar.gz
cd openssh-portable-V_9_8_P1
./configure
make
make install
mv /usr/sbin/sshd /usr/sbin/sshd.bak
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
systemctl restart sshd

#!/bin/sh -- # -*- perl -*- -p

Какой вывод можно сделать... последние 20 лет у людей в CS какие-то проблемы с решетками?

The issues raised in my original article about the pre-installed browser extensions are still partially present. Two extensions are relaxing the default protection provided by Content-Security-Policy even though it could have been easily avoided. One extension is requesting massive privileges, even though it doesn’t actually need them. At least they switched from jQuery to React, but they still somehow managed to end up with HTML injection vulnerabilities.

In addition, two extensions will accept messages from any Avast website – or servers pretending to be Avast websites, since HTTPS-encrypted connections aren’t being enforced. In the case of the Privacy Guard (sic!) extension, this messaging exposes users’ entire browsing information to websites willing to listen. Yes, Avast used to collect and sell that information in the past, and this issue could in principle allow them to do it again, this time in a less detectable way.

The Messaging extension is responsible for the rather invasive “onboarding” functionality of the browser, allowing an Avast web server to determine almost arbitrary rules to nag the user – or to redirect visited websites. Worse yet, access to internal browser APIs has been exposed to a number of Avast domains. Even if Avast (and all the other numerous companies involved in running these domains) are to be trusted, there is little reason to believe that such a huge attack surface can possibly be secure. So it has to be expected that other websites will also be able to abuse access to these APIs.