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 | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
