#longread #docker #debezium #всратость #mysql #kafka #realtime

https://telegra.ph/Catch-the-Latest-07-30

#пятница #aws

Redis просто меняет свою лицензию.

Сотрудник AWS с тревожностью:
- Срочно форкаем Redis!
Сотрудник с ОКР:
- Называем просто, чтобы все понимали, что это KeyValue продукт!
Сотрудник с СДВГ:
- Коротко, парни, KeyVal, не тянем!
Сотрудник с дислексией:
- Всё, пишу ValKey
Сотрудник с задержкой обработки:
- Погодите, а мы ничего не путаем? Мы же про редис говорили.
Сотрудник с гиперфокусом:
- А я уже сделал рассылку и лого для ValKey!
Менеджер AWS:
- Bias for Action, guys! Действуем!

А я не знаю откуда ещё могло взяться такое название.

#aws #devops #longread #longstory #msk #apigateway #cloudfront

Суббота, отличная погода и великолепное настроение - идеальный момент для меня, чтобы написать новую историю.

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

https://telegra.ph/My-maiden-magnum-opus-08-01

Тут меня утром AI чуть не заменил через увольнение

Контекст: Grok3 free, prompt с вопросом какую команду и опции ввести для террагрант плана для всех модулей, прежде, чем удалить весь env и чтобы не спрашивал постоянно про external dependencies.
Вернусь-ка я, пожалуй, обратно к --help у террагранта.

#git #eol #lf #crlf

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

Проблема: сохранил редактируемый файл(конфиг/ридми/ямл/докерфайл - да любой текстовый файл) с CRLF = уронил всё, что зависит от этого файла.
Дальше первой строчки никто его не прочитает.
Криво скопировал ответ нейронки из браузера и вставил в файл не посмотрев на EOL - тоже будут ошибки.
Написал скрипт bash - command not found.
Налепил Dockerfile - после первого слоя ничего не будет, плюс ошибка.

Визуально файл такой же, но по факту ничего не работает.
Пора что-то менять.

Проблема с EOL(End of Line) в подавляющем большинстве случаев попадётся всем инженерам, от начинающих сладких пирожочков до самоуверенных синёров-помидоров, кто работает с Windows операционной системой и может не знать/забыть про такие базовые особенности.

Конец строки EOL в операционных системах Linux и Windows обозначается разными символами, что связано с историческими особенностями их развития:
- Linux/Unix: Используется символ перевода строки - LF (Line Feed, \n).
Это стандарт для Unix-систем, включая Linux и macOS.
- Windows: Используется комбинация двух символов - CRLF (Carriage Return + Line Feed, \r\n).
Это стандарт говна, который тебе не нужен.

Тебе почти всегда надо LF.
Для консольных утилит, для CI/CD, для git файлов, для всего.

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

1) Автоматизация в IDE (на примере VSCode)
Зайти в параметры, в поиске ввести EOL, выбрать в выпадающем меню \n
Теперь по дефолту все файлы будут сохраняться в LF EOL.
Ну или добавь "files.eol": "\n" в settings.json

2) Автоматизация в GIT.
В глобальный(ну не для каждого же репозитория же добавлять)

git config --global core.autocrlf false

Эта штука отключает автоматическое преобразование концов строк (CRLF <<->> LF), чтобы Git не вмешивался в формат строк при коммитах или checkout.

git config --global core.eol lf

Устанавливает LF (\n) как стандартный формат конца строки для всех новых файлов в репозиториях.
То есть даже если у тебя слетит настройка в IDE - всё равно гит сохранит как надо для новых файлов.

3) Автоматизация с pre-commit
Во все репозитории добавляй пре-коммит хук в свой файл .pre-commit-config.yaml

---
repos:
....
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
...
      - id: end-of-file-fixer
....

4) Себе попу прикрыл - прикрой и коллегам.
В корне репозиториев, в которых работаешь с командой, добавь/измени файл с именем .gitattributes
Внутри

* text=auto eol=lf

Так же добавь в файл .editorconfig в корне репозитория

root = true
[*]
end_of_line = lf

5) Не веришь автоматизации/нет под рукой IDE/файлы не в гите/временно работаешь по SSH на ремоут сервере - проверяй все файл(ы) и принудительно конвертируй файл(ы) при помощи CLI утилиты.

sudo apt install dos2unix

Примеры использования

dos2unix filename.txt
dos2unix *.txt
dos2unix -r directory/
find . -type f -name "*.sh" -exec dos2unix {} \;

За окном 2025 год.
Не совершай элементарных и детских ошибок.
Всё придумали до нас.
Не нужен тебе CRLF.

FROM debian:trixie

Тихо и незаметно вышел стабильный релиз Debian 13 Trixie.
https://www.debian.org/releases/trixie/release-notes/

Особых ожиданий от него не было, кроме желания обновить множество базовых имиджей для устранения накопившегося технического долга по CVE.
Утомительное говно от шизо-сесурити-параноиков в общем.
Сразу протестировал на нескольких проблемных сервисах - Trivy пока не выявил уязвимостей. Отлично.

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

#пятница

Репозитории в 2018

projectdir
projectfiles

Репозитории в 2022

projectdir
projectfiles
IDEA
.gitignore
.dockeringnore
.helmignore
.gitattributes
.pre-commit-config.yaml
.yamllint
.editorconfig

Репозитории в 2026

projectdir...
projectfiles...
CLAUDE.md
.kiro/steering/product.md
.kiro/steering/structure.md
.kiro/steering/tech.md
.cursor/rules/general_rules.mdc
PERPLEXITY_AI.md
.perplexity/settings.yml
.perplexity/guides/how_to_talk_to_ai.md
README_PYTHON_CHATBOT.md
AI_instructions/do_not_argue_with_robot.txt
.grok_instructions.md
notion_ai_policy.md
consensus/verification.md
midjourney/picture_rules.mdc
kill_all_humans.bender
mintlify_update_all_the_documentation_cause_im_lazy_ass.yml

#gitlab #github #secrets #security

История третья. GitHub.

Третья история это не баг репорт, а собственное исследование в целях повышения опыта и экспертизы в вопросах безопасности.
НЕ ПОВТОРЯТЬ, ЭТО ПРОТИВОЗАКОННО, НЕЛЬЗЯ ПОВТОРЯТЬ
История лишь для ознакомления, повторять абсолютно запрещено, заметка исключительно в целях сокрытия СВОИХ проектов от глупых действий.

Все эти игрища были лишь в организации, где изначально у меня были хоть какие-то, но минимальные права.
Будет ли это работать при публичных репозиториях?
Как мне проверить это и защитить свои публичные репозитории от хакеров?

Немного теории. Выжимка для самых маленьких - вы ведь не хотите читать всю документацию GitHub.
1) Когда я запускаю у себя(личный репо, репо организации) воркфлоу - это МОЙ секьюрити контекст.
Мой securitycontext = мне доступны все секреты.
Если я сделаю форк от любого публичного репозитория, затем "что-то подменяю" в коде и отправлю pull request - это Fork а значит недоступен SecurityContext и секреты. То есть при любом форке - секреты недоступны, только если автор репозитория специально руками не сделает это(по умолчанию выключено).
Однако есть директива pull_request_target
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target
Если в каком-то репозитории есть такая директива = при форке и пулл реквесте мы получаем доступ к SecurityContext.
2)GitHub не дурак и отслеживает любые изменения файлов воркфлоу.
Даже если у нас есть pull_request_target, но мы взяли и подменили workflow файл, добавив туда нечто типа run: python scripts/print_secret.py - этих изменений не будет в воркфлоу - есть дифф между оригиналом

Это всё теория, а что насчёт практики.
Чтобы "взломать все интернеты" нам надо соблюдение таких условий
- чтобы была опасная директива pull_request_target - "pull_request_target"
- чтобы директория была - path:.github/workflows/
- чтобы мы могли как-то где-то что-то запустить, НЕ изменяя файл воркфлоу, но заинжектить свой вредоносный код, а точнее защититься от такой ситуации в своих публичных репозиториях.

Как мы можем заинжектить, не меняя ничего в воркфлоу?
Нам надо найти куски кода, где в run есть:
- нечто типа python script.py (подменяем сам скрипт и он выполняется, извлекая секреты)
- pip install (в setup.py инжектим pre-install и выполнение нашего кода, получаем доступ к секретам)
-npm install/command (ну тут понятно - лепи что хочешь)
- всё подобное, что выше, но для других языков/утилит

В двух словах поиск будет типа

org:*****  path:.github/workflows/ "pull_request_target" "${{ secrets." "install"

В общем и целом это помогает злоумышленнику получить доступ к вашим секретам через форк и пулл реквест.
Однако когда я начал писать об этом репорт, я уже решил почитать документацию и везде написано, что такие действия опасные.
То есть тот, кто включил у себя pull_request_target - сам себе злобный буратино.
Та же ситуация с запуском скриптов из всех примеров выше.
Вероятно от https://hackerone.com/ я получу такой же ответ.
Репорт не стал писать. И слишком много условий и в документации есть миллионы ворнингов.

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

Для себя же стоит запомнить:
- никогда не использовать в своих публичных репозиториях pull_request_target - при форке идёт передача SecurityContext и все секреты отдаются публично.
- нникогда не использовать в своих публичных репозиториях запуск сторонник скриптов типа python script.py
- не рассчитывать на сохранность всех секретов GitLab
- я ещё поиграю в хакера и попробую заработать на других потенциальных уязвимостях

И да - я опять поленился писать лонгрид в один пост, сорян.