Book

Будующее ещё не наступило

https://community.synology.com/enu/forum/17/post/112394

TLDR: SSD можно использовать в виде кеша, но только для... одного тома. Нахуй такое нужно вообще, я не могу себе представить. Особенно на 8-дисковом NASe. И ещё работает крайне хуёво, по словам.

В целом, конечно, надо делать мой IO-стартап. Тем более что в нашем текущем начинании "для поддержки штанов" мы пришли к успеху.
Book

Вопрос залу

Как известно, более-менее вменяемых способов аутентифицировать HTTP Request Body есть всего 2:
- Mozilla Hawk
- AWS4

Есть ещё 2 невменяемых:
- Oauth-идиоты что-то там надумали в FAPI2, но во-первых это ещё не релиз а во-вторых я не могу продраться через их сепульки
- Способ, который придумали в UK OpenBanking

Невменяемые способы хороши, но не hipster friendly. Есть ещё совсем невменяемые типа делать всё на коленках поверх RS256 JWT.

Короче, выбор пал на AWS4. Теперь внимание на экран.

https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html говорит, что есть Signed payload option. Как её заюзать? Проблем две:

1. Есть либы по созданию, но не верификации "подписи" (*-наци внутри меня мне не нравится, когда MAC называют digital signature, но такова жизнь).
2. Эти либы всё равно не создают сами x-amz-content-sha256

Вариантов решения несколько:

1. Найти где-то готовую реализацию
2. Налепить на коленках поверх npm i aws4
3. Найти референс-реализацию на левом языке и тестировать нашу реализацию против неё

И вот вопрос залу.

Как быть.

Upd: в Ноде внезапно npm i aws4 умеет генерить x-amz-content-sha256, если написать service: 's3'. А в localstack нет кода, парсящего их x-amz-date, которая ISO8601 без разделителей.

Upd2: Postman внезапно создаёт и "подписывает" x-amz-content-sha256. Хороший мальчик!
Book

Получение публичных ключей из текущего ssh-agent

ssh-add -L внезапно выводит список ключей из текущего SSH-агента. Вопрос в том, есть ли способ установить ключ из ссш-агента в текущий authorized_keys. Ну то есть вариант ssh-add -L >>~/.ssh/authorized_keys но работающий если файла нет или если ключ уже есть.

Только приседать и писать скриптик? Там же не так просто:

(umask 0077 ; mkdir -p .ssh; ssh-add -L >>.ssh/authorized_keys)

Это наверное если без проверки и если все ключи из агента сразу добавлять
Book

Либо крестик либо трусы

В предыдущей серии https://nponeccop.livejournal.com/675359.html мы научились делать мышку в системной консоли.

Но консоль внезапно 8-цветная. Даже не 16-цветная. В 2021 году, Карл.

Но есть отдельно консоль эмулирующая xterm-256color и даже поддерживающая акселерацию. Называется kmscon. Но с ней не работают ни consolation, ни lcxterm.

В-общем, либо 256 цветов, либо мышка.
Book

Neovim в CentOS 8

Проблема vim в том, что это кусок говна, который традиционно обмазывается примитивизмом вроде ctags и нерабочей хуетой.

Ну вот в CentOS 8 инженеры redhat/ibm обычные дятлы в EPEL сделали минимально рабочий vim, с какими-то минимальными плагинами, чтобы можно было работать, но не было проблемы свистопердежа и обмазывания сотнями говна.

Ну и это всё можно вставить в неовим (также из EPEL), и там оно, понятное дело, продолжает работать. А neovim нужен чтобы юзать плагины из VSCode.

В-общем вот:

dnf install neovim python3-neovim awesome-vim-colorschemes vim-{airline,gitgutter}

mkdir -p ~/.local/share/nvim/site/pack/хуй/start/ и туда клонируем coc.nvim и vim-polyglot (ну или vimplug, но это так сказать лишний indirection при сомнительной пользе против обновляющего KISS bash-скрипта)

В результате получается божественно короткий ~/.config/nvim/init.vim:

set runtimepath+=/usr/share/vim/vimfiles
set mouse=a
colorscheme PaperColor
let g:coc_disable_startup_warning = 1

Далее делаем :CocInstall нужным LSP-плагинам и собственно всё.

Ну и это всё работает если дефолтовый терминал доведён до ума передачей из путти putty-256color вместо xterm, и при необходимости .tmux.conf:

set-option -g default-terminal "screen-256color"
set-option -g mouse on
set-option -sg escape-time 10

Ну и там coc можно дальше обмазывать хоткеями, но мне лень.
Book

Хвалёный Python

https://stackoverflow.com/q/14154756/805266

there isn't currently a reliable way to get the dependency of an arbitrary PyPi package remotely without needing to download it completely. And in fact the dependencies sometimes depend on your environment, so an approach like Brian's of executing setup.py code is needed in the general case.

Я тут экспериментирую. Решил водрузить localstack. Но также решил перейти на "дубовый" дистр в лице Центоса, который ссучился (не десктоп).

Но там товарищи рекомендуют... ставить его через pip. Понятно, что это не наш метод.

Наш метод это поставить из дистра, а раз в дистре нет - то поставить из дистра те из зависимостей, которые таки есть. Но оказалось (см. начало поста) что не тут-то было.

python3-{boto3,docopt,pyyaml,dnslib,dulwich,dns}
Book

Хвалёный AWS

https://aws.amazon.com/blogs/compute/nodejs-packages-in-lambda/

Короче говоря, в 2015 году архитекторы AWS рекомендовали устанавливать ноду... из сорцов. Они там ебанулись все, что ли?

ТруЪ-способ - это пекедж. Преимущества? Нуу, я думаю интеграция с dnf update --security всё перебивает. Интересно, как они в условиях отсутствия репы следят, чтобы рантаймы AWS Lambda для ноды обновлялись оперативно.
Book

Очередной Bikeshed

https://docs.microsoft.com/en-us/windows/apps/winui/winui3/

Я тут не очень соображаю, так что могу писать чушь, но интересно следить за процессом.

WinUI 3 is the path forward for all Windows apps—you can use it as the UI layer on your native UWP or Win32 app, or you can gradually modernize your desktop app, piece by piece, with XAML Islands.

All new XAML features will eventually ship as part of WinUI. The existing UWP XAML APIs that ship as part of the OS will no longer receive new feature updates.

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

User32 никто не использует, потому что там контролы прибиты координатами, и надо писать свой лейаут менеджер

MFC никто не использует, потому что это ёбаный C++98 и макросы вокруг Gui32. With MFC in Visual Studio 2015, you can create dialogs that the user can resize. Т.е. какой-то dynamic layout есть, но см. выше.

WinForms никто не использует, потому что это ёбаный C#. Как там с лейаутом, мне неизвестно. Судя по "Create amazing and highly customizable user experiences with the DevExpress Form Layout component." всё примерно также как выше - т.е. встроенный лейаут может и есть, но реально юзабельно только с third party components.

GTK c Glide и Qt c QML находятся, как я понимаю, находятся здесь. И там и там лейаут есть, и вроде как достаточно для того чтобы не было сторонних лейаут-менеджеров.

После WinForms MS решили видимо показать кузькину мать, в результате в что WPF лейаут не просто есть, а с блекджеком и шлюхами, матрицами поворота и прочим инструментарием чтобы делать не просто формочки, а GUI, автокад-фотошоп. В результате WPF никто не использует, потому что а) сложна б) глючно - я так понимаю из-за очень большого количества фич происходит комбинаторный взрыв и нужная комбинация скорее всего не работает.

Поэтому они пошли взад и придумали UWP, который не так убог, как WinForms, но не так сложен, как WPF. Но его тоже никто не использует, ибо это не просто C#, а C# с винстором. Да ещё и прикручен к номеру билда винды.

Поэтому они решили

а) открутить UWP от номера билда - т.е. поддерживать все фичи на всех билдах
б) сделать какую-то поддержку интеграции с лигаси
Book

PKI CA на смарт-карте на основе TPM - часть 3

Часть 1 - tpmvscmgr
Часть 2 - генерация корневого сертификата и настройка openssl сapi.dll engine

Теперь надо залепить собственно CA. Полутайное знание - оно есть в доке но несколько неочевидно при прочтении - что у openssl ca есть аж 10 параметров, которые хорошо бы держать в openssl.conf, а не передавать каждый раз в коммандлайне. Они документированы, но тайность заключается в том, что некоторые значения опциональны в конфиге, но их тогда приходится указывать в коммандлайне. Так что если вы хотите более-менее DRY коммандлайн - то они де факто mandatory хоть формально в доке написано обратное.

Тайное знание - формат private_key в случае capi engine. И то что в serial.hex надо поместить 00 и перевод строки, но будут работать и некоторые другие варианты. index.txt надо создать пустым, но это документировано.

policy (и её зеркальное отражение в req, но об этом позже) - это самое страшное, что есть в любом PKI CA. Да и в любой схеме с подписями. Вам надо придумать набор claims (в терминах JWT), которые вы будете подписывать при выдаче сертификата. В терминах X.509 набор сlaims - это DN, Distinguished Name. Там куча абсурдных сведений типа степени разработанности ануса, и надо решить, какие из них вам нужны, какие нужны системе, в которой сертификат будет работать, а какие не нужны.

Вот Country и Organization Name вам точно НЕ нужны. Поскольку это внутренний CA, организация у вас одна, указывать её нет смысла. См. количество информации - если вероятность 1 то информации у нас 0. Страна тоже не особо нужна. Точнее, страна - это достаточно неудобный классификатор, даже если у вас реально есть несколько разных стран. Остаются Organization Unit и Locality. В-общем изначально решить, что вы будете указывать в OU и L, невозможно. Надо насоздавать всем сертов, а потом, во второй версии CA, понять, нужна ли вам какая-то схема классификации. Поэтому используйте OU или L. Я выбрал L, поскольку SSID это очевидно скорее L чем OU. Но реально надо понимать что это вам скорее всего не понадобится и на данном этапе добавлено на всякий случай.

Common Name как правило вы не выбираете сами, а его выбирает система, в которой используется сертификат. В случае WAP2 EAP-TLS в CN лежит IP. Ну и тут понятно, что вам скорее всего понадобится всего 1 сертификат с CN=IP для каждого IP. А если где-то понадобится 2 разных - то будете различать их по L/OU. Поскольку выдавать неуникальные DN - это моветон.

Итого в конфиг дописывается секция ca, определяющая, вы не поверите, дефолтовые параметры для команды openssl ca:
[ca]
default_ca = ca_section

[ca_section]
dir = MYCA
database      = $dir/index.txt
serial        = $dir/serial.hex
new_certs_dir = $dir/newcert
email_in_dn   = no
policy        = policy_ip_section
default_days  = 365

private_key   = 4 # "Certificate 4" из openssl engine -t -post list_certs 
certificate   = certs/ca.cert.pem
default_md    = sha256

[ policy_ip_section ]
localityName            = supplied
commonName              = supplied
В результате когда к вам придёт CSR, openssl проверит, что в нём есть клаймы L и СN, и выкинет все остальный клаймы, если их укажут при создании CSR. Это тоже документировано, но если вы не используете CSR, то непонятен смысл всего этого птичьего языка. Надеюсь, теперь понятно что такое OpenSSL CA Policy.

Теперь расскажу, где брать certs/ca.cert.pem. Его можно брать 2 путями:

1. Экспорт из certmgr. Это публичный ключ, т.е. экспортировать НУЖНО.

Пускаем mmc. Я предпочитаю добавлять снапины в пустой mmc. File - Add/remove snap-in. Добавляем туда Certificates. Потом в радиобаттоне - My user account.

Там заходим в Personal. Находим в списке наш CA, сгенерённый из powershell в Ч2. All tasks - export. Убеждаемся что приватный ключ экспортировать низя, так как мы это запретили. На следующем этапе выбираем base64, т.к. это PEM, формат, в котором все хотят. Проверяем через openssl x509 -noout -text -in ca.cer что опенссл всё распарсил.

Вроде бы всё норм, но OpenSSL потом откажется этот серт брать. Запасаемся попкором - для этого нам понадобится способ 2, но до него нам ещё надо генерить CSR.