Я следую этому руководству по настройке репозитория debian
https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
Управлять этим хранилищем буду я и мои коллеги. Мы хотим подписать пакеты и само репо, поэтому мне нужен ключ GPG. Естественно, я не должен использовать свой собственный ключ GPG, иначе мои коллеги не смогут управлять репо. Поэтому я подумал о создании нового ключа GPG специально для этого репозитория, а затем поделился закрытым ключом с моими коллегами.
Это правильный способ управления репо множеством людей? Мне не нравится идея совместного использования закрытого ключа (и я думаю, что он не будет хорошо масштабироваться для репозиториев, управляемых многими людьми), но, с другой стороны, я не вижу другого способа сделать это.
Думаю, есть простое решение, но мой недостаток опыта работы с такими серверами мне не помогает.
Изменить: здесь упоминалось совместное использование закрытого ключа http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/ (вариант использования 2 в самом низу)
Я не делал этого с пакетами Debian, но вот что мы сделали с RPM на предыдущем этапе: мы создали сервер подписи, который хранит закрытый ключ, и никто не имел к нему прямого доступа. (Ну, кроме тех из нас, кто был системным администратором в этой системе; в зависимости от ваших потребностей в безопасности вы можете усилить этот «брандмауэр».)
Сервер подписи имеет область Dropbox. Вы можете ограничить это с помощью ssh-ключей или паролей или чего-то еще, или, из-за следующего шага, вы даже можете оставить его открытым для всего мира.
Следите за появлением новых файлов в области Dropbox. Когда они появятся, убедитесь, что они подписаны с действующим ключом одного из сопровождающих. Если нет, удалите их. Затем проверьте, являются ли они действительными файлами пакета с любыми другими проверками, которые вы хотите, скопируйте их в промежуточную область под учетной записью пользователя, зарезервированной для службы подписи. После прохождения проверки подписывающий сервер оставляет пакеты со своим собственным ключом (который, опять же, напрямую не читается).
И поскольку это удобно, у нас был один и тот же сервер, на самом деле запускавший инструменты создания репозитория. Поскольку, в отличие от RPM, ваш репозиторий подписан сам, это кажется особенно удобным, потому что вы можете добавить эту подпись сюда, опять же с закрытым ключом, к которому никто не имеет прямого доступа.
Немного более строгая версия этого метода удаляет автоматический захват, и подписывающие стороны каждый раз вводят кодовую фразу секретного ключа. Таким образом, люди, обслуживающие систему, могут даже не иметь возможности подписывать пакеты путем обмана и прямого доступа к ним. (Конечно, они могут трояны системы, но давайте оставим эту степень паранойи для другой темы. Или вы можете просто решить, что знаете, что вы все равно должны доверять системным администраторам, и обеспечить это политикой, оставив удобство drop- коробочный подход на месте.)