[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

aptitude update "BADSIG" Error (getting silly now)



Just wondering whether anyone here understands the cause of the "BADSIG"
error from "aptitude update", which googling reveals has been
experienced by quite a few people :
http://lists.debian.org/debian-security/2006/08/msg00100.html
http://lists.debian.org/debian-user/2006/12/msg00227.html
http://lists.debian.org/debian-user/2007/06/msg01121.html

The usual suggested causes involve Debian mirrors in an inconsistent
state while updating, broken packages, or corruptions in the package
lists as a result of broken network connections.

With the system I'm working on (a vanilla Etch-with-KDE system), on
every occasion that BADSIG occurs, simply rerunning "aptitude update"
succeeds, without having changed a thing.

Some responses have pointed out that multiple backend machines serving a
single repository alias will be offered by DNS round-robin, so on the
'aptitude update' rerun I'm probably talking to a different server -
understood, but this does NOT mean there isn't a problem needing a fix,
IMHO.

Here's an example :

MYBOX:/etc/apt# aptitude update
Get:1 http://security.debian.org etch/updates Release.gpg [189B]
Get:2 http://security.debian.org etch/updates Release [22.5kB]
Get:3 http://ftp.de.debian.org etch Release.gpg [378B]
Hit http://ftp.de.debian.org etch Release
Ign http://security.debian.org etch/updates Release
Ign http://security.debian.org etch/updates/main Packages/DiffIndex
Ign http://ftp.de.debian.org etch/main Packages/DiffIndex
Ign http://security.debian.org etch/updates/contrib Packages/DiffIndex
Get:4 http://security.debian.org etch/updates/main Packages [216kB]
Hit http://ftp.de.debian.org etch/main Packages
Hit http://security.debian.org etch/updates/contrib Packages
Fetched 238kB in 1s (200kB/s)
Reading package lists... Done
W: GPG error: http://security.debian.org etch/updates Release: The
following signatures were invalid: BADSIG A70DAF536070D3A1 Debian
Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>
W: You may want to run apt-get update to correct these problems

(seconds later ...)

MYBOX:/etc/apt# aptitude update
Get:1 http://security.debian.org etch/updates Release.gpg [189B]
Get:2 http://ftp.de.debian.org etch Release.gpg [378B]
Hit http://security.debian.org etch/updates Release
Hit http://ftp.de.debian.org etch Release
Ign http://security.debian.org etch/updates/main Packages/DiffIndex
Ign http://security.debian.org etch/updates/contrib Packages/DiffIndex
Ign http://ftp.de.debian.org etch/main Packages/DiffIndex
Hit http://security.debian.org etch/updates/main Packages
Hit http://ftp.de.debian.org etch/main Packages
Hit http://security.debian.org etch/updates/contrib Packages
Fetched 190B in 0s (522B/s)
Reading package lists... Done

In case it's relevant, this is on a system on my employer's network,
with aptitude making connections to debian.org via our proxy firewall.

The BADSIG error now occurs every single day.

We have a nightly cronjob on several Debian boxes, that runs
"aptitude update" and emails the sysadmins if updates are waiting - and
the BADSIG situation is silly enough that I've had to add Bash code to
deal with it, like this :

$APTITUDE update &> $UPDATELOG
RC=$?
if grep "The following signatures were invalid: BADSIG" $UPDATELOG; then
    # About half the time, the first "aptitude update" fails with
    # a failure to verify the GPG signature on the package lists
    # - repeating seems to solve the problem - yeesh .. must bug
    # report this (Nick; Nov.2007) :
    MESSAGE=$(date +%R)" : stupid BADSIG error detected" \
            "- retrying once ..."
    echo $MESSAGE >> $REPORTFILE
    sleep 5
    $APTITUDE update &> $UPDATELOG
    RC=$?                      # ... and just carry on
elif grep "403 Forbidden" $UPDATELOG; then
    # We failed because the firewall proxy credentials are incorrect :
    MESSAGE=$(date +%R)" : the proxy firewall username/password" \
            "in /etc/apt/apt.conf is incorrect"
    echo $MESSAGE >> $REPORTFILE
    exitfail
elif grep "Could not resolve" $UPDATELOG; then
    # We failed because no firewall proxy has been specified :
    MESSAGE=$(date +%R)" : it looks like the proxy firewall has" \
            "not been specified in /etc/apt/apt.conf"
    echo $MESSAGE >> $REPORTFILE
    exitfail
fi

[despite the original code comment saying "about half the time" it now
seems to be "all the time"]


There must be a fixable cause for this.  If a mirror can get
inconsistent when half a synchronisation has been done, then the refresh
should be made atomic - the lock-out would only need to be for 5
seconds, based on my experience.  If the lock-out resulted in a timeout
(from aptitude) well at least that would be an understandable
transient-type error to find in your Inbox in the morning - but a
suspect package signature is downright alarming and leads to
blood-curdling fear [I exaggerate slightly :)].

I suppose, given that only /some/ users see this behaviour, the cause
could be some kind of obscure timing fault caused by some oddity of
local configuration.

Or in our case maybe there's some weird caching problem with our web proxy. Does anyone see this error when /not/ using a proxy ?

Anyway, what exactly seems to have been badly signed ?  The error
message doesn't really make sense :

> GPG error: http://security.debian.org etch/updates Release:
> The following signatures were invalid:
> BADSIG A70DAF536070D3A1 Debian Archive Automatic
> Signing Key (4.0/etch) <ftpmaster@debian.org>

That seems to mean the repository's 'Release' file signature is bad, but actually /says/ the *Signing Key* has a bad signature - though I'd have thought the signing key was already on my system, and not something the system had just downloaded. If it's the 'Release' file which has a bad signature, we should just sign it "inline" ("gpg -sa"), rather than with a detached signature - then the file could not get out of step with its signature. If we already do sign it inline then there is a signing problem that may be serious. Er .. er ...

And what does "A70DAF536070D3A1" refer to ?


(Maybe this is a topic for debian-security - not sure)

Cheers,
Nick Boyce
--
Walk towards the light.


Reply to: