Re: aptitude update "BADSIG" Error (getting silly now)
On Mon, Mar 24, 2008 at 04:29:47 +0000, Nick Boyce wrote:
> 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.
Those are all the innocent explanations I can think of. More paranoid
explanations would go along the lines of someone trying to slip you
doctored packages via a man-in-the-middle attack. However, in your case
I think your proxy is the most likely culprit (see below).
> 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.
I don't think that such a problem would remain unnoticed and unfixed for
a long time for security.debian.org. Most other reports of the BADSIG
problem that I can remember involved much less known secondary mirrors.
You can put the IP addresses into your sources.list instead and check if
the error is tied to one particular server:
$ host security.debian.org
security.debian.org has address 128.31.0.36
security.debian.org has address 212.211.132.32
security.debian.org has address 212.211.132.250
security.debian.org mail is handled by 10 klecker.debian.org.
> 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]
[...]
> 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) <...>
> 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]
[...]
> Reading package lists... Done
It downloaded the Release.gpg file again for security.debian.org
etch/updates. The file was the same length (these signatures tend to be,
AFAIK) but it might have had the same content. The next time when the
problem appears, make a backup copy of
/var/lib/apt/lists/security.debian.org_dists_etch_updates_Release.gpg
and check if the file has changed after you rerun "apt-get update" and
the error disappears. (This is just to rule out bugs with the gpg
signature verification routines.)
> 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.
I download the updated Release and Release.gpg files from
security.debian.org (almost) every day and I do not recall ever having
this problem. As I have said already, I think that by far the most
likely cause is that your proxy sometimes serves you an outdated
Release(.gpg) file from its cache.
> 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 :
[...]
Maybe it would be enough to fetch the critical files yourself with "wget
--no-cache" to flush out-of-date versions before you run the "apt-get
update" command. Maybe the caching behavior of your proxy for these files
can be reconfigured.
> 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 ?
I think people do sometimes see this without using a proxy, but not for
the security server(s), or at least not with the kind of regularity that
you are describing. Does your nightly cronjob hit the server always at
exactly the same time?
> 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) <...>
>
> 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.
The message means that a bad signature was detected, which was
(supposedly) made with the key number A70DAF536070D3A1. You cannot
necessarily tell whether the signature or the signed file has been
corrupted or tempered with; it could be both.
> 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 ...
The signatures are detached; each *_Release.gpg file holds the signature
for the corresponding *_Release file. I think this might fit better with
the two-step process of first creating the Release file and then signing
it, or the detached signatures might simply reflect the fact that the
cryptographic verification feature was added only relatively recently.
> And what does "A70DAF536070D3A1" refer to ?
It is the long ID of the key; quite often you will see only the second
half of it displayed (the short ID).
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Reply to: