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 считается экспериментальным и предназначен только для первых пользователей. Вы предупреждены.

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

| EncSign(X): Подписать и зашифровать для владельца GPG-ключа | Encrypt(K,X): Зашифровать с использованием симметричного алгоритма | Hash(X): SHA-2/256 | | B: список веток | L: список хеша (Hi) и ключа (Ki) для каждого packfile | R: Remote ID | | Для записи репозитория: | | Сохранить каждый packfile P как Encrypt(Ki, P) → P' в файле с именем Hi | где Ki — новая случайная строка, а Hash(P') → Hi | Сохранить в манифесте | | Для чтения репозитория: | | Получить манифест, расшифровать и проверить с помощью связки ключей GPG → | Предупредить, если не совпадает с ранее виденным Remote ID | для каждого в : | Получить файл с сервера → | Проверить, что совпадает с | Расшифровать с помощью → , затем открыть с помощью git

Файл манифеста .............

Пример файла манифеста (с многоточием для краткости)::

$ gpg -d 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
542051c7cd152644e4995bda63cc3ddffd635958 refs/heads/next
3c9e76484c7596eff70b21cbe58408b2774bedad refs/heads/master
pack :SHA256:f2ad50316...cd4ba67092dc4 z8YoAnFpMlW...3PkI2mND49P1qm
pack :SHA256:a6e17bb4c...426492f379584 82+k2cbiUn7...dgXfyX6wXGpvVa
keep :SHA256:f2ad50316...cd4ba67092dc4 1
repo :id:OYiSleGirtLubEVqJpFF

Каждый элемент продолжается до новой строки и соответствует одному из следующих:

<sha-1> <gitref> Идентификатор объекта git и его ссылка

pack :<hashtype>:<hash> <key> Хеш packfile (Hi) и соответствующий симметричный ключ (Ki).

keep :<hashtype>:<hash> <generation> Хеш packfile и его поколение переупаковки

repo <id> Идентификатор remote

extn <name> ... Поле расширения, сохраняется, но не используется.

Обнаружение репозиториев gcrypt

Чтобы определить, является ли git-адрес репозиторием gcrypt, используйте: git-remote-gcrypt --check url Код возврата 0, если репозиторий существует и может быть расшифрован; 1, если репозиторий использует gcrypt, но не может быть расшифрован; и 100, если репозиторий не зашифрован с помощью gcrypt (или не может быть доступен).

Обратите внимание, что при этом содержимое репозитория извлекается в локальный git-репозиторий, так же как и при использовании репозитория gcrypt.

Известные проблемы

Каждый git push фактически имеет флаг --force. Перед отправкой обязательно выполняйте pull.

git-remote-gcrypt может принять решение о переупаковке remote без предупреждения, что означает, что ваш push может внезапно занять значительно больше времени, чем вы ожидали, поскольку придётся повторно загружать всю историю. Такой push может завершиться ошибкой при плохом соединении.

git-remote-gcrypt может сообщить, что репозиторий «не найден», хотя на самом деле он существует, но у git-remote-gcrypt возникают проблемы с аутентификацией, портом или сетевым подключением.

Смотрите также

git-remote-helpers(1), gpg(1)

Авторы

Первоначальным автором git-remote-gcrypt был пользователь GitHub bluss.

Фактическим сопровождающим в 2013 и 2014 годах был Joey Hess.

Текущий сопровождающий, с 2016 года — Sean Whitton [email protected].

Лицензия

Этот документ и git-remote-gcrypt распространяются на одинаковых условиях, GPL-3 (или 2+); см. файл git-remote-gcrypt.

.. этот документ создаёт страницу руководства с помощью rst2man .. vim: ft=rst tw=72 sts=4