Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1059266: error: cannot verify inline signature
12 views
Skip to first unread message
Christian Marillat
Dec 22, 2023, 5:00:04 AM12/22/23
to
Package: dupload
Version: 2.10.4
Severity: grave
Dear Maintainer,
This version fail to check a signature. Work fine with 2.10.3
,----
| $ debrelease
| dupload note: no announcement will be sent.
| Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 10:50:05 2023 CET
| gpgv: using RSA key A401FF99368FA1F98152DE755C808C2B65558117
| gpgv: issuer "mari...@deb-multimedia.org"
| gpgv: Can't check signature: No public key
| openpgp-check: error: cannot verify inline signature for ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found
|
| dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for ../gerbera-dmo_1.12.1-dmo5_amd64.changes
`----
Christian
-- System Information:
Debian Release: trixie/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.8-1-custom (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dupload depends on:
ii libdpkg-perl 1.22.2
ii perl 5.36.0-10
Versions of packages dupload recommends:
ii libio-socket-ssl-perl 2.084-1
ii liburi-perl 5.21-1
ii openssh-client 1:9.6p1-2
Versions of packages dupload suggests:
ii exim4-daemon-heavy [mail-transport-agent] 4.97-2
pn libsecret-tools <none>
ii lintian 2.116.3
-- no debconf information
Version: 2.10.4
Severity: grave
Dear Maintainer,
This version fail to check a signature. Work fine with 2.10.3
,----
| $ debrelease
| dupload note: no announcement will be sent.
| Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 10:50:05 2023 CET
| gpgv: using RSA key A401FF99368FA1F98152DE755C808C2B65558117
| gpgv: issuer "mari...@deb-multimedia.org"
| gpgv: Can't check signature: No public key
| openpgp-check: error: cannot verify inline signature for ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found
|
| dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for ../gerbera-dmo_1.12.1-dmo5_amd64.changes
`----
Christian
-- System Information:
Debian Release: trixie/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.8-1-custom (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dupload depends on:
ii libdpkg-perl 1.22.2
ii perl 5.36.0-10
Versions of packages dupload recommends:
ii libio-socket-ssl-perl 2.084-1
ii liburi-perl 5.21-1
ii openssh-client 1:9.6p1-2
Versions of packages dupload suggests:
ii exim4-daemon-heavy [mail-transport-agent] 4.97-2
pn libsecret-tools <none>
ii lintian 2.116.3
-- no debconf information
Guillem Jover
Dec 22, 2023, 5:40:04 PM12/22/23
to
Hi!
On Fri, 2023-12-22 at 19:37:16 +0100, Aurelien Jarno wrote:
> On 2023-12-22 19:23, Aurelien Jarno wrote:
> > This also causes issues on the riscv64 build daemons running sid:
> >
> > | dupload exit status 9/0
> > | Removed to reupload later.
> > |
> > | Complete output from dupload:
> > | gpgv: using RSA key 670D3AC041E218107D0DE6F9339F749981589F2F
> > |
> > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for emmax_0~beta.20100307-4_riscv64-buildd.changes
Ouch, ok.
> > On 2023-12-22 12:16, Guillem Jover wrote:
> > > Just to understand what is going wrong, I assume you don't have the
> > > debian-keyring package installed (where the signing certificate could
> > > be found in the debian-keyring.gpg keyring), nor the certificate for
> > > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?
> >
> > For debian build daemons, it is not expected to have the keys in the
> > debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
> > exist.
> >
> > > But gpg has it in its certificate store?
> >
> > Yes:
> >
> > buildd@rv-manda-01:~/.gnupg$ gpg -K
> > /home/buildd/.gnupg/pubring.kbx
> > -------------------------------
> > sec rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
> > 670D3AC041E218107D0DE6F9339F749981589F2F
> > uid [ ultime ] buildd autosigning key rv-manda-01 <buildd_riscv6...@buildd.debian.org>
>
> It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg,
> not from ~/.gnupg/trustedkeys.gpg.
The trustedkeys.gpg is a keyring used mainly by gpgv (gpg does not use
it by default, except that the dpkg code will feed it as an additional
keyring if it is found.
I'll prepare an upload right away and force the code to use gpg for
now (as it was used before the recent upload, instead of trying gpgv,
sqop, pgpainless-cli, or sq), until I've devised a better migration
plan, or implemented enough configuration options for people to switch
or use other OpenPGP backends when desired.
Thanks,
Guillem
On Fri, 2023-12-22 at 19:37:16 +0100, Aurelien Jarno wrote:
> On 2023-12-22 19:23, Aurelien Jarno wrote:
> > This also causes issues on the riscv64 build daemons running sid:
> >
> > | dupload exit status 9/0
> > | Removed to reupload later.
> > |
> > | Complete output from dupload:
> > |
> > | dupload note: no announcement will be sent.
> > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 18:06:16 2023 UTC
> > | dupload note: no announcement will be sent.
> > | gpgv: using RSA key 670D3AC041E218107D0DE6F9339F749981589F2F
> > | gpgv: Can't check signature: No public key
> > | openpgp-check: error: cannot verify inline signature for emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature found
> > |
> > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for emmax_0~beta.20100307-4_riscv64-buildd.changes
Ouch, ok.
> > On 2023-12-22 12:16, Guillem Jover wrote:
> > > Just to understand what is going wrong, I assume you don't have the
> > > debian-keyring package installed (where the signing certificate could
> > > be found in the debian-keyring.gpg keyring), nor the certificate for
> > > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?
> >
> > For debian build daemons, it is not expected to have the keys in the
> > debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
> > exist.
> >
> > > But gpg has it in its certificate store?
> >
> > Yes:
> >
> > buildd@rv-manda-01:~/.gnupg$ gpg -K
> > /home/buildd/.gnupg/pubring.kbx
> > -------------------------------
> > sec rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
> > 670D3AC041E218107D0DE6F9339F749981589F2F
> > uid [ ultime ] buildd autosigning key rv-manda-01 <buildd_riscv6...@buildd.debian.org>
>
> It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg,
> not from ~/.gnupg/trustedkeys.gpg.
The trustedkeys.gpg is a keyring used mainly by gpgv (gpg does not use
it by default, except that the dpkg code will feed it as an additional
keyring if it is found.
I'll prepare an upload right away and force the code to use gpg for
now (as it was used before the recent upload, instead of trying gpgv,
sqop, pgpainless-cli, or sq), until I've devised a better migration
plan, or implemented enough configuration options for people to switch
or use other OpenPGP backends when desired.
Thanks,
Guillem
Aurelien Jarno
Dec 24, 2023, 7:30:03 AM12/24/23
to
Hi
On 2023-12-22 23:30, Guillem Jover wrote:
> I'll prepare an upload right away and force the code to use gpg for
> now (as it was used before the recent upload, instead of trying gpgv,
> sqop, pgpainless-cli, or sq), until I've devised a better migration
> plan, or implemented enough configuration options for people to switch
> or use other OpenPGP backends when desired.
Thanks, I confirm it fixes the issue.
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://aurel32.net
On 2023-12-22 23:30, Guillem Jover wrote:
> I'll prepare an upload right away and force the code to use gpg for
> now (as it was used before the recent upload, instead of trying gpgv,
> sqop, pgpainless-cli, or sq), until I've devised a better migration
> plan, or implemented enough configuration options for people to switch
> or use other OpenPGP backends when desired.
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://aurel32.net
0 new messages