git-remote-gcrypt

---

GNU Privacy Guard-зашифрованный git remote

:Руководство, раздел: 1

Описание

git-remote-gcrypt — это вспомогательная программа для git remote, позволяющая отправлять и получать данные из репозиториев, зашифрованных с помощью GnuPG, используя собственный формат. Этот вспомогательный remote обрабатывает URI с префиксом gcrypt::.

Поддерживаемые бэкенды: local, rsync:// и sftp://, где репозиторий хранится в виде набора файлов, либо любой <giturl>, где gcrypt будет хранить то же представление в git-репозитории, передаваемое через произвольный git-транспорт. Отдавайте предпочтение local или rsync://, если можете их использовать; см. обсуждение в разделе «Производительность» ниже.

Также существует экспериментальный бэкенд rclone:// только для первых пользователей (вы предупреждены).

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

Установка ............

• используйте менеджер пакетов вашего дистрибутива GNU/Linux — известно, что пакеты есть в Debian, Ubuntu, Fedora, Arch и некоторых меньших дистрибутивах
• на других системах запустите предоставленный скрипт install.sh

Быстрый старт ..........

Создайте зашифрованный remote, отправив в него данные::

git remote add cryptremote gcrypt::rsync://example.com/repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch]      master -> master

Конфигурация

Поддерживаются следующие переменные git-config(1):

remote.<name>.gcrypt-participants .. gcrypt.participants Разделённый пробелами список идентификаторов ключей GPG. Remote шифруется для этих участников, и принимаются только подписи от них. gpg -k выводит список всех известных вам открытых ключей.

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

Настройка ``gcrypt-participants`` для конкретного remote имеет приоритет над переменной репозитория ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants По умолчанию идентификаторы ключей gpg участников скрываются путём шифрования с помощью gpg -R. Установка этой опции в true отключает эту меру безопасности.

Проблема использования ``gpg -R`` заключается в том, что для расшифровки gpg поочерёдно перебирает все доступные секретные ключи, пока не найдёт подходящий. Это может привести к появлению ненужных запросов парольной фразы.

gcrypt.gpg-args Содержимое этой настройки передаётся как аргументы gpg. Например, --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (Последняя из стандартной конфигурации git) Ключ, используемый для подписи. Вам следует установить user.signingkey, если ваш ключ подписи по умолчанию не входит в список участников. Вы можете использовать версию для конкретного remote, чтобы подписывать разные remote разными ключами.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Флаги, передаваемые rsync при загрузке на удалённый сервер с использованием бэкенда rsync://. Если флаги установлены для конкретного remote, глобальные флаги (если они также установлены) не будут применяться для этого remote.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push Давняя ошибка заключается в том, что каждый git push фактически имеет флаг --force.

Если этот флаг установлен в ``true``, git-remote-gcrypt откажется выполнять push, если не передан ``--force`` или refspec не предварены ``+``.

Существует потенциальное решение этой проблемы: https://bugs.debian.org/877464#32

Переменные окружения

GCRYPT_FULL_REPACK Если эта переменная окружения установлена (в любое значение, кроме пустой строки), при push принудительно выполняется полная переупаковка.

Примеры

Как настроить remote для двух участников::

git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master

Как использовать git-бэкенд::

# обратите внимание, что целевой git-репозиторий уже должен существовать, и его
# ветка `next` будет перезаписана!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

Фрагмент URL (здесь #next) указывает, какая ветка бэкенда используется.

Примечания

Совместная работа Шифрование манифеста обновляется при каждом push в соответствии с конфигурацией участников. Каждый пользователь, выполняющий push, должен иметь открытые ключи всех соавторов и правильную конфигурацию участников.

Зависимости rsync, curl и rclone для remote rsync:, sftp: и rclone: соответственно. Основной исполняемый файл требует POSIX-совместимую оболочку, поддерживающую local.

GNU Privacy Guard Поддерживаются как GPG 1.4, так и 2. Вам понадобится личный ключ GPG. Конфигурация GPG влияет на выбор алгоритмов для шифрования с открытым ключом, симметричного шифрования и подписи. Дополнительную информацию см. в man gpg.

Remote ID Remote ID не является секретным; он только гарантирует, что два репозитория, подписанные одним и тем же пользователем, можно различить. Вы увидите предупреждение, если Remote ID изменится, что должно происходить только при пересоздании remote.

Производительность Использование произвольного <giturl> или URI sftp:// требует загрузки всей истории репозитория при каждом push. Это означает, что push вашего репозитория со временем замедляется по мере увеличения истории git, и легко может дойти до того, что дальнейшее использование git-remote-gcrypt станет непрактичным.

Поэтому используйте эти бэкенды только в том случае, если вы знаете, что ваш репозиторий никогда не станет очень большим, а не только то, что он невелик сейчас. Это означает, что эти бэкенды не подходят для большинства репозиториев и, вероятно, пригодны только для необычных случаев, например, для небольших хранилищ учётных данных. Даже в этом случае используйте `rsync://`, если можете. Однако обратите внимание, что `rsync://` не будет работать с такими сервисами хостинга репозиториев, как Gitolite, GitHub или GitLab.

URI rsync Формат URI для бэкенда rsync: rsync://user@host/path, что соответствует расположению rsync user@host:/path, доступному через ssh. Обратите внимание, что путь абсолютный, а не относительно домашнего каталога. Также поддерживается более ранний нестандартный формат URI: rsync://user@host:path, что соответствует расположению rsync user@host:path.

Бэкенд rclone В дополнение к добавлению бэкенда rclone в качестве remote с URI вида gcrypt::rclone://remote:subdir, вы также должны добавить remote в конфигурацию rclone. Обычно это делается выполнением rclone config. См. rclone(1).

Бэкенд rclone считается экспериментальным и предназначен только для первых пользователей. Вы предупреждены.

Формат репозитория .................