Search
Write a publication
Pull to refresh

Comments 10

Имел достаточно негативный опыт работы с git crypt в команде.

Какой-нибудь Mozilla SOPS гораздо лучше и более DevOps yaml friendly, если цель шифрование yaml/json секретов.

А какой негативный опыт был с git-crypt? Опишите?

Не раскрыт момент использования git-crypt с CI системами. Вам всё равно придётся хранить ключ для расшифровки где-то ещё, например, в переменных окружения. Если секретов мало, то полезность git-crypt и mozilla sops стремится к нулю.

Хорошее замечание, попробуем подыскать перевод, где это будет представлено в полном объеме

В конце сказано про приватные ключи gpg, оно не подойдет?

И в любом случае было бы интересно про такую настройку почитать.

Подойдет) Но я так понимаю, хочется почитать же реальный опыт на эту тему.

Да, очень. Мы в отделе, конечно, вряд ли выпустим свои коды в опенсорс, но улучшить защиту - почему бы и нет?

Ключ для расшифровки (git-crypt export-key …) шифруется GPG'ем для заданных получателей командой git-crypt add-gpg-user USERID и коммитится в репозиторий, например:


% git-crypt add-gpg-user 522291A78747D8A3 D3A45B56CB5598D6
[master 8890b9f] Add 2 git-crypt collaborators
 3 files changed, 4 insertions(+)
 create mode 100644 .git-crypt/.gitattributes
 create mode 100644 .git-crypt/keys/default/0/01BDB4F92C70B6388A0E2E8A522291A78747D8A3.gpg
 create mode 100644 .git-crypt/keys/default/0/864BAD7E6FF3126D217041C8D3A45B56CB5598D6.gpg

Добавляем все USERID, которым нужен доступ, в т.ч. себя.


Далее просто запускаем git-crypt unlock без указания файла с ключём и он автоматически расшифрует его, если доступен соответствующий приватный ключ:


% git-crypt lock
% file k1.key
k1.key: data
% git-crypt unlock
% file k1.key
k1.key: ASCII text

И экспортировать ключ (git-crypt export-key …) уже не нужно.

Sign up to leave a comment.