Your message dated Sun, 8 Oct 2017 12:24:34 +0200
with message-id <20171008102434.5ypzqm4z2kjbjk3n@crossbow>
and subject line Re: Bug#877948: aptitude: false error: "The following 
signatures were invalid" (gpg con         good)
has caused the Debian Bug report #877948,
regarding aptitude: false error: "The following signatures were invalid" (gpg 
con        good)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
877948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877948
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.6.11-1+b1
Severity: normal

Dear Maintainer,

There are two repositories which are blocked from "aptitude update" on
the basis of "invalid signature", when in fact gpg reports the
signatures are valid.

* 1st package: gc2latex *

  To reproduce, these steps are taken:

    1) apt-key adv --recv-key 0x5145B9CD752C0197
    2) gpg --keyring /etc/apt/trusted.gpg --edit-key 0x5145B9CD752C0197 trust
    3) Selected full trust ("4")

  To prove that gpg find the signature good:

  $ gpg --verify --keyring /etc/apt/trusted.gpg <(curl -s 
http://wertarbyte.de/apt/Release.gpg) <(curl -s 
http://wertarbyte.de/apt/Release)

  results in:

    gpg: Signature made Wed 25 May 2011 11:15:52 PM CEST
        gpg:                using DSA key 5145B9CD752C0197
        gpg: Good signature from "Wertarbyte.de (Software Signing Key) 
<[email protected]>" [unknown]
        gpg: WARNING: This key is not certified with a trusted signature!
        gpg:          There is no indication that the signature belongs to the 
owner.
        Primary key fingerprint: CC49 F74C 816C 499C 899A  4288 5145 B9CD 752C 
0197

  This is the deb line in sources.list:

    deb http://wertarbyte.de/apt/ ./
 
  When doing "aptitude update", the output is:

    W: GPG error: tor+http://wertarbyte.de/apt ./ Release: The following 
signatures were invalid: CC49F74C816C499C899A42885145B9CD752C0197
    E: The repository 'tor+http://wertarbyte.de/apt ./ Release' is not signed.
    E: Failed to download some files

* 2nd package: pwsafe *

  It's the same problem for pwsafe, which has the sources.list entry:
  
    deb http://packages.steve.org.uk/pwsafe/jessie/ ./

  the gpg key of which can be installed this way:
  
    wget -O - http://packages.steve.org.uk/pwsafe/apt-key.pub | apt-key add -

Note the version info below is on Jessie, but the same problem occurs on recent 
versions in Stretch.

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
        linux-vdso.so.1 (0x00007fff97679000)
        /usr/lib/torsocks/libtorsocks.so (0x00007f7d01765000)
        libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x00007f7d013f5000)
        libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x00007f7d011bf000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x00007f7d00f95000)
        libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x00007f7d00d8f000)
        libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x00007f7d00a79000)
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x00007f7d007b0000)
        libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007f7d00598000)
        libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007f7d00187000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007f7cfff6a000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x00007f7cffc5f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7cff95e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x00007f7cff748000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7cff39d000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7cff199000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f7cfef96000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7cfed7b000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x00007f7cfeb6b000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f7cfe948000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7cfe740000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f7cfe53b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7d01fca000)

-- System Information:
Debian Release: 8.6
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common           0.6.11-1
ii  libapt-pkg4.12            1.0.9.8.3
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6                     2.19-18+deb8u6
ii  libcwidget3               0.5.17-2
ii  libgcc1                   1:4.9.2-10
ii  libncursesw5              5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a        2.4.0-1
ii  libsqlite3-0              3.8.7.1-1+deb8u2
ii  libstdc++6                4.9.2-10
ii  libtinfo5                 5.9+20140913-1+b1
ii  libxapian22               1.2.19-1+deb8u1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1.1
ii  sensible-utils                  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47
pn  debtags           <none>
ii  tasksel           3.31+deb8u1

-- no debconf information

--- End Message ---
--- Begin Message ---
Hi,

Disclaimer: Not an aptitude maintainer, but an apt developer and as the report
concerns elements not specific to aptitude I take the liberty to deal with it.


On Sat, Oct 07, 2017 at 05:12:24PM +0200, Anonymous wrote:
> There are two repositories which are blocked from "aptitude update" on
> the basis of "invalid signature", when in fact gpg reports the
> signatures are valid.

The signature is valid for gpg as it has a different interpretation of what it
considers valid (in the version you are using). The signatures are based on the
SHA1 algorithm which is considered weak nowadays – that might still be good
enough for a signature on an email (depending on your requirements), but the apt
team decided that it isn't enough to ensure the security of your system.

APT hence considers signatures based on SHA1 as invalid and expects something 
based
on SHA256 or more. Most browsers do the same for HTTPS certificates by the way 
and
newer gpg versions default to signing with newer algorithms.

Note that the keys itself need to be signed with recent signatures as well!

See also: https://wiki.debian.org/Teams/Apt/Sha1Removal


>     2) gpg --keyring /etc/apt/trusted.gpg --edit-key 0x5145B9CD752C0197 trust
>     3) Selected full trust ("4")

You don't need to do that, apt makes no use of trust in the gpg sense.
Also, that command modifies the trust value of the user running the command –
not what apt will see (if it would use it).


>     wget -O - http://packages.steve.org.uk/pwsafe/apt-key.pub | apt-key add -

Recieving the key from the keyring server is as bad as downloading the key
unverified from the internet. At the very least download via HTTPS. Ideally
you would establish a trustpath from your own key to those keys.

Also, you should prefer dropping files in /etc/apt/trusted.gpg.d instead of
using apt-key. In newer apt versions (>= stretch) you can use ascii armored
keys here as well.

Details on all that in apt-key and apt-secure manpages.


So, as it is working as it should be: Closing as not a bug.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel

Reply via email to