Частное репо: следующие подписи были недействительными
На моих бионических "клиентах" я получаю:
GPG error: http://repo.localpod/Dml/ldom-debs/ubuntu bionic InRelease: The following signatures were invalid: ADE541A20ACF8997C01BDCF7090678A30132048A
Обратите внимание, что он говорит "неверно", а не отсутствует!
Это мои собственные пакеты.deb, собранные в репо. (это хорошо работает для верных и xenial)
Я подписал репозиторий чем-то вроде: (вызывается через prespro: conf/distribution)
gpg --batch --yes --keyring $KeyP --secret-keyring $KeyS -a --no-permission-warning --detach-sign --default-key 'ldom install service' --output $3 $1
$1 = .../Release
$2 = .../InRelease
хорошо, так что я попробовал:
wget http://repo.localpod/Dml/ldom-debs/ubuntu/dists/bionic/InRelease
and:
# gpgv --keyring /etc/apt/trusted.gpg "InRelease"
gpgv: Signature made Thu 24 May 2018 12:20:29 PM CEST
gpgv: using DSA key 090678A30132048A
gpgv: Good signature from "ldom install service <tbuunix@...dk>"
Разве это не более или менее, как apt-get проверяет подписи? Или ключ слишком старый? неверный тип?
полная ошибка:
apt-key list
pub rsa2048 2014-06-24 [SC]
754A 1A7A E731 F165 D5E6 D4BD 0E08 A149 DE57 BFBE
uid [ unknown] SaltStack Packaging Team <packaging@saltstack.com>
sub rsa2048 2014-06-24 [E]
pub dsa1024 2013-06-10 [SCA]
ADE5 41A2 0ACF 8997 C01B DCF7 0906 78A3 0132 048A
uid [ unknown] LDOM install service <tbuunix@....dk>
sub elg1024 2013-06-10 [E]
root@ubu18:~# apt-get update
Get:1 http://repo.localpod/Dml/ldom-debs/ubuntu bionic InRelease [1,154 B]
Err:1 http://repo.localpod/Dml/ldom-debs/ubuntu bionic InRelease
The following signatures were invalid: ADE541A20ACF8997C01BDCF7090678A30132048A
Reading package lists... Done
W: GPG error: http://repo.localpod/Dml/ldom-debs/ubuntu bionic InRelease: The following signatures were invalid: ADE541A20ACF8997C01BDCF7090678A30132048A
E: The repository 'http://repo.localpod/Dml/ldom-debs/ubuntu bionic InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Любая подсказка относительно того, что я пропускаю, будет приветствоваться... Спасибо,
/ Holger
обходной путь:
Я закончил тем, что следовал руководству ( https://www.digitalocean.com/community/tutorials/how-to-use-reprepro-for-a-secure-package-repository-on-ubuntu-14-04) --- -> более или менее. ---> все еще немного "в работе", но вот несколько советов:
используя (свежее) изображение докера:
docker run -it -v /your/packages:/debs ubuntu:18.04
apt update
apt install -y vim inetutils-ping curl wget netcat telnet aptitude man manpages bash-completion rng-tools reprepro iproute2
rebuild your packages:
cd /debs/src
ls -d */DEBIAN | xargs -n1 dirname | xargs -n1 dpkg-deb -vD --build
время для ключевых вещей. использовать существующий ключ:
gpg --import /debs/.../secring.gpg
для нового ключа:
gpg --full-generate-key
#rsa 4
#bits 4096
#your_key_name
#passphrase
#
gpg --edit-key your_key_name
#addkey
#(4) RSA (sign only)
#4096
#0
#yes
#yes
#save
gpg --list-secret
gpg --list-key
gpg --export .....your..key.....number............... > keyfile
apt-key add keyfile
хорошо, время для установки репропро:
mkdir /debs/u18repo
cd /debs/u18repo
cat <<END >conf/options
ask-passphrase
END
cat <<END >conf/distributions
Codename: bionic
Components: main
Architectures: amd64
SignWith: .....your..key.....number...............
END
reprepro -b /debs/u18repo includedeb bionic /debs/src/*.deb
gpg --export .....your..key.....number............... > keyfile
тестировать:
apt-key add keyfile
echo "deb file:////debs/u18repo/ bionic main" >> "/etc/apt/sources.list"
apt update
Теперь, если вы используете /debs/u18repo на своих клиентах ( httpd) и импортируете ключ с помощью: apt-key, добавьте http: /.../ keyfile Обновление apt должно работать...
2 ответа
Я была такая же проблема. В файле InRelease есть подписанное PGP сообщение, которое должно содержать:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Это означает, что SHA256 используется для подписи. SHA1 является слабым алгоритмом и не должен использоваться. Поэтому, если есть SHA1, вам нужно обновить конфигурацию gnupg, чтобы использовать sha256.
В моем случае:
echo "personal-digest-preferences SHA256 SHA384 SHA512 SHA224 RIPEMD160" >> ~/.gnupg/gpg.conf
а затем подать в отставку файл InRelease, используя gpg, как обычно.
Я столкнулся с точно такой же проблемой.
Убедитесь, что все используемые вами ключи представлены в двоичном формате, а не в защищенном формате ASCII. Если какой-либо из ключей находится в защищенном формате ASCII, преобразуйте их в двоичный файл, используя -
gpg --dearmor
Согласно этому -
... Причина, по которой мы избегаем ASCII-защищенных файлов, заключается в том, что они не могут использоваться непосредственно SecureApt.
Также убедитесь, что в файле ~/.gnupg/gpg.conf указаны следующие строки или что-то похожее -
cert-digest-algo SHA256
digest-algo SHA256