Make. Build. Break. Reflect.
908 subscribers
115 photos
1 video
119 links
Полезные советы, всратые истории, странные шутки и заметки на полях от @kruchkov_alexandr
Download Telegram
- "а можете ли вы, мои новые интерны, вводить эти команды? всё ли хорошо тут? ответьте, пожалуйста, на вопрос"
git add .
git commit -m "fix" --no-verify
git push origin main --force
git tag -f prod
git push --force origin prod
git clean -fdx
git reset --hard HEAD~5
git push --force-with-lease
git reflog expire --expire=now --all
git gc --aggressive --prune=now


- "да вроде хорошо. мы часть команд не знаем, но вроде всё как обычно, гит адд, гит коммит и гит пуш. а может и нельзя, мы не знаем часть команд, мы обычно кнопку в vscode жмём"

#git
😁6👍1
#security #git #devops

Часть 1 из 2.

Рано или поздно все инженеры начинают расти профессионально.
Мы узнаем лучшие практики, оптимизируем существующий стек или инфру, внедряем новые технологии.
В какой-то момент мы даже следуем бест практис по security.
Добавление сканеров, проверки на бесящие всех CVE, пайплайны, pre-commit hooks и selinux/securitycontext.
Перечислять всё не буду, это невероятно огромная область.

Но интернет git всё помнит.
Git is the source of truth, как говорит мой коллега.
Это сейчас мы внедрили все практики и больше нет утечек паролей и токенов в гит, а храним всё в vault/aws sm/azure sa.
А что же в истории git?
В гите у нас могут остаться:
- токены
- private keys
- пароли

Давайте проверим и почистим за собой в репозитории.

Экспериментировать мы будем на публичных репах, чтобы вы сперва потренировались, ДО того, как будете ломать свои реальные репозитории🤣.

Предварительная подготовка
- установить gitleaks https://github.com/gitleaks/gitleaks
Эта штука позволяет найти секреты во всех ветках всех файлах всей гит истории.
Описание есть в ридми.
- устанавливаем java
- устанавливаем bfg https://rtyley.github.io/bfg-repo-cleaner/
я просто сделал так
wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar

Эта штука помогает удалить лишнее найденное из гита.
- устанавливаем jq https://github.com/jqlang/jq
эта штука нам нужна для разового парсинга
- ну и git

Приступаем к поиску и очистке.
- форкаем себе рандом популярный проект, а почему бы и да
Ищём тут https://github.com/trending?since=monthly
есть какой-то microsoft/qlib
- клонируем себе форкнутый проект (у вас путь другой будет само собой)
git clone git@github.com:kruchkov-alexandr/qlib.git

- запускаем сканер утечки чувствительных данных не меняя директорию
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json


│╲
│ ○
○ ░
░ gitleaks

12:23PM INF 1790 commits scanned.
12:23PM INF scan completed in 696ms
12:23PM WRN leaks found: 1

Результатом будет джейсон файл с детальным описанием кто, когда, что и за тип секретов.
Можете открыть и посмотреть, что там утек 1 токен от разработчика(он может быть и реальным и фейком).
- Для удобства очищаем его от всего лишнего
cat findings.json | jq -r '.[].Secret' > passwords.txt

Для чего мы это делаем?
Чтобы сгенерить и проверить содержимое файла passwords.txt и ЕСЛИ в нём есть то, чего НЕ НАДО удалять из гита и оно бы осталось в гите, надо убрать из этого файла.
В этом файле то, что будет в последствии удалено из гита.
- заходим в гит репозиторий
cd qlib

- запускам bfg
>java -jar ../bfg-1.14.0.jar --replace-text ../passwords.txt

Видим длинную простыню текста, типа
Commit Tree-Dirt History
------------------------
Earliest Latest
| |
.........................................................DDm
D = dirty commits (file tree fixed)
m = modified commits (commit message or parents changed)
. = clean commits (no changes to file tree)

Before After
-------------------------------------------
First modified commit | 21f0b394 | b3d34764
Last dirty commit | 63021018 | abf5a1bf
Changed files
-------------
Filename Before & After
---------------------------------------------------
data.py | 8de32f3f ⇒ 82298fe3, f6bd7809 ⇒ 8bd16038
In total, 159 object ids were changed. Full details are logged here:
/home/***/GIT/INTERNET/qlib.bfg-report/2025-06-12/12-24-52

- ещё раз смотрим чего же мы там меняем(если есть хоть любые сомнения, прерывайте процесс! операция без бекапов не поддаётся восстановлению!!!)
cat /home/***/GIT/INTERNET/qlib.bfg-report/202*-0*-**/12-24-52/changed-files.txt
8de32f3f6c0373ca1b41fe6d3f4dbd4c23685d71 82298fe3811f0c36aa982a1ff23ee92289cc9346 data.py
f6bd780905649d8d004c13bd98a91044958b9573 8bd160386147b2007172e618dbe049b02cd4bcc3 data.py
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😨2
#security #git #devops

Часть 2 из 2.

- теперь мы выдыхаем, принимаем решение и чистим
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Это мы почистили ЛОКАЛЬНО гит, пока на ремоут сервер не заливали.
- проверяем, что локально всё чисто
cd ..
>gitleaks detect --source qlib --log-opts="--all" --report-path findings.json


│╲
│ ○
○ ░
░ gitleaks

12:29PM INF 1790 commits scanned.
12:29PM INF scan completed in 722ms
12:29PM INF no leaks found

То есть проверка показала, что все токены и пароли были удалены.
- крестимся и пушим в ремоут
cd qlib
git push origin --force

Всё, история в нашем форке почищена.
Можно ещё раз проверить всё
- удаляем локальный репозиторий
cd ..
sudo rm -r qlib

- клонируем с ремоута
git clone git@github.com:kruchkov-alexandr/qlib.git

- проверяем на утечки
gitleaks detect --source qlib --log-opts="--all" --report-path findings.json


│╲
│ ○
○ ░
░ gitleaks

12:33PM INF 1790 commits scanned.
12:33PM INF scan completed in 731ms
12:33PM INF no leaks found

- радуемся, что даже в истории гита нет утечек

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

Инструкция длинная, кажется сложно, но на самом деле это лишь 5 команд и всё.
Не бойтесь. Вы - инженер.
👍16
#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.
🔥208👍7
Приветствую всех.

Поскольку все читатели здесь ради контента, а не моей биографии, сразу перейду к сути.
Этот блог - мои заметки на полях.
Почти не делаю репосты, пишу для души и лишь когда на это есть время/желание.
Обычно это 2-4 поста в неделю.

В основном делюсь:
- информацией, которую узнал только что (даже если она пятилетней давности, но я узнал её сейчас)
- лонгридами, байками или всратыми историями, без указания срока давности
- последовательным описанием моего процесса мышления на работе при решении задач

Интересные, на мой взгляд, сообщения я публикую с тегами:
- пример основных тем канала:
#aws #azure  #kubernetes  #troubleshooting  #costoptimization  #longread  #devops
- пример второстепенных категорий:
#terragrunt  #victoriametrics  #git #docker  #одинденьизжизни  #helm
- для того, чтобы на работе не поехать кукухой, у меня есть:
#пятница  #всратость  #байки

Сообщения без тегов это просто шутка-минутка или мысль, которая была актуальна лишь на момент написания.

Все заметки не имеют строгой последовательности, читать их можно как угодно:
- начать с самого основания канала (за год постов около 230)
- использовать интересующие теги/поиск
- ну или просто начать с новых постов, пропустив всё ранее написанное 😭
Каждый решает, как ему удобно.

Буду рад, если мои заметки помогут кому-то узнать что-то новое, избежать повтора чужих ошибок или просто улыбнуться.
На крайний случай, самоутвердиться за счёт моих факапов или незнания 🐒
Всем привет и желаю приятного чтения.
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍31👨‍💻1