Ubuntu

GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5)

Reported by don hardaway on 2005-10-16
746
This bug affects 91 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
High
Brian Murray
Precise
High
Unassigned
Quantal
High
Brian Murray
update-manager (Ubuntu)
Low
Unassigned
Precise
Low
Unassigned
Quantal
Low
Unassigned

Bug Description

I keep getting this when i launch the update manager.

W: GPG error: http://archive.ubuntu.com breezy-updates Release: The following
signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic
Signing Key <email address hidden>

How can I fix it?

***********
WORKAROUND:
----------
Run the following commands(saves a backup of the old lists and creates a new lists folder) and the BADSIG error does not occur :

$ cd /var/lib/apt
$ sudo mv lists lists.old
$ sudo mkdir -p lists/partial
$ sudo apt-get update

***********

comment from Rolf Leggewie: This is due to cache inconsistencies and thus is not necessarily a bug in Ubuntu at all. But I hope the fine devs can find a way to better deal with broken proxies. This is a very visible issue, a large number of internet connections are behind proxies and the users cannot do anything about it.

Dennis Kaarsemaker (dennis) wrote :

By simply waiting. This happens at times during archive updates.

Michael Vogt (mvo) wrote :

Thanks Dennis for ansering this bugreport.

I would like to add that pressing "Reload" in update-manager (or synaptic) helps
in most cases because it will update the package list again and redo the
authentication. This should make the key errors go away. Let us know if that
dosn't fix the problem.

Cheers,
 Michael

don hardaway (don-hardaway) wrote :

I have pressed the reload about 6 times. out of 6 tries only once has the
message not come up. This never happened with Hoary. Something is wrong here.

I have tried reload 12 times in succession, on
several occasions, but always get the GPG error.

I must agree with Don Hardaway on this: "Something
is wrong here."

Robert

Michael Vogt (mvo) wrote :

(In reply to comment #4)
> I have tried reload 12 times in succession, on
> several occasions, but always get the GPG error.
>
> I must agree with Don Hardaway on this: "Something
> is wrong here."

Thanks for your bugreport.

What is your exact error? Is it exactly the same as Don? What is your
sources.list content?

Can you please run
$ apt-get update -o Debug::Acquire::http=True 2> /tmp/apt-http.log
and attach that log to this bugreport (as a file attachment)?

Cheers,
 Michael

Created an attachment (id=4980)
sources.list

Created an attachment (id=4981)
apt-http.log

(In reply to comment #5)
>
> What is your exact error? Is it exactly the same as Don? What is your
> sources.list content?
>
> Can you please run
> $ apt-get update -o Debug::Acquire::http=True 2> /tmp/apt-http.log
> and attach that log to this bugreport (as a file attachment)?
>
> Cheers,
> Michael

Thanks for your reply.

I get the following warning from the update manager:

"W: GPG error: http://archive.ubuntu.com hoary Release: The following
signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive
Automatic Signing Key <email address hidden>"

I have attached my source.list and the log file you requested.

Note that when generating the log file, the following is output to
the terminal:

"Get:1 http://security.ubuntu.com hoary-security Release.gpg [189B]
Get:2 http://archive.ubuntu.com hoary Release.gpg [189B]
Hit http://archive.ubuntu.com hoary Release
Get:3 http://security.ubuntu.com hoary-security Release [16.9kB]
Ign http://archive.ubuntu.com hoary Release
Hit http://archive.ubuntu.com hoary/main Packages
Hit http://archive.ubuntu.com hoary/restricted Packages
Hit http://archive.ubuntu.com hoary/main Sources
Hit http://archive.ubuntu.com hoary/restricted Sources
Hit http://archive.ubuntu.com hoary/universe Packages
Hit http://archive.ubuntu.com hoary/universe Sources
Hit http://security.ubuntu.com hoary-security/main Packages
Hit http://security.ubuntu.com hoary-security/restricted Packages
Hit http://security.ubuntu.com hoary-security/main Sources
Hit http://security.ubuntu.com hoary-security/restricted Sources
Fetched 17.2kB in 0s (23.9kB/s)
Reading package lists... Done"

I hope this helps,

Robert

Any progress?

I still get the error every time I do a reload.

Help (or a work round) would be appreciated.

Robert

Michael Vogt (mvo) wrote :

(In reply to comment #9)
> Any progress?
>
> I still get the error every time I do a reload.

Sorry for the late reply.

> Help (or a work round) would be appreciated.

Does it help if you run:
$ sudo apt-get update -o Acquire::http::No-Cache=True
or
$ sudo apt-get update -o Acquire::BrokenProxy=true

Thanks,
 Michael

michael brenden (mike-brenden) wrote :

same problem here with hoary on 20 dec 2005

root@rock:/etc/apt # apt-get update -o Acquire::BrokenProxy=true
Get:1 http://security.ubuntu.com hoary-security Release.gpg [189B]
Get:2 http://archive.ubuntu.com hoary Release.gpg [189B]
Hit http://security.ubuntu.com hoary-security Release
Hit http://archive.ubuntu.com hoary Release
Hit http://security.ubuntu.com hoary-security/main Packages
Hit http://security.ubuntu.com hoary-security/restricted Packages
Hit http://security.ubuntu.com hoary-security/main Sources
Hit http://security.ubuntu.com hoary-security/restricted Sources
Hit http://security.ubuntu.com hoary-security/universe Packages
Hit http://security.ubuntu.com hoary-security/universe Sources
Ign http://archive.ubuntu.com hoary Release
Hit http://archive.ubuntu.com hoary/main Packages
Hit http://archive.ubuntu.com hoary/restricted Packages
Hit http://archive.ubuntu.com hoary/main Sources
Hit http://archive.ubuntu.com hoary/restricted Sources
Hit http://archive.ubuntu.com hoary/universe Packages
Hit http://archive.ubuntu.com hoary/universe Sources
Hit http://archive.ubuntu.com hoary/multiverse Packages
Hit http://archive.ubuntu.com hoary/multiverse Sources
Fetched 190B in 1s (117B/s)
Reading package lists... Done
W: GPG error: http://archive.ubuntu.com hoary Release: The following signatures
were invalid: BADSIG 40976EAF437D05B5 Ub
untu Archive Automatic Signing Key <email address hidden>
W: You may want to run apt-get update to correct these problems

(In reply to comment #10)
> (In reply to comment #9)
> > Any progress?
> >
> > I still get the error every time I do a reload.
>
> Sorry for the late reply.
>
> > Help (or a work round) would be appreciated.
>
> Does it help if you run:
> $ sudo apt-get update -o Acquire::http::No-Cache=True
> or
> $ sudo apt-get update -o Acquire::BrokenProxy=true
>
> Thanks,
> Michael
>
>

Thank you for your response.

On noticing your suggestions, I gave
'reload' one last try just to make
sure it was still failing - and
(of course!) it wasn't.

So, for the moment at least, the problem
has gone away. Should it return I will
try your suggestions and post the results.

With thanks,

Robert.

Stuart Bishop (stub) wrote :

I'm still see this issue regularly. In the case I just had, reloading would
always fail until I used 'sudo apt-get Acquire::http::BrokenProxy=True'. I'll
try this again next time I see the issue, as this might have just been luck.
I'll attach apt-http.log from the debug run (there are other logs from me
attached to similar bugs, but I'm now with a new ISP).

Stuart Bishop (stub) wrote :

Created an attachment (id=5597)
Stuart Bishop's apt-http.log from apt-get debug run.

Daniel Hahler (blueyed) wrote :

Does someone still experience this bug?

There seem to be quite a lot of matching results with Google (http://www.google.com/search?q=%22BADSIG+40976EAF437D05B5%22).
In a particular case this was caused by a broken file and could get fixed using rescue boot and "fsck -fy /" (http://forum.ubuntuusers.de/goto?post=89197 - german)

I was having this problem consistently today. After reading through the above when I ran with apt-get update -o Acquire::http::No-Cache=True everything worked fine. As another datapoint, I know that our company recently installed a transparent http(s) proxy, so maybe there is something to do with the proxy response going on. I also ran with the debug output while it was failing and the log I got is attached.

Bartek (tschew) wrote :

--------
W: GPG error: http://archive.canonical.com hardy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>
W: GPG error: http://packages.medibuntu.org hardy Release: The following signatures were invalid: BADSIG 2EBC26B60C5A2783 Medibuntu Packaging Team <email address hidden>
W: You may want to run apt-get update to correct these problems
---------

I'm experiencing this bug in hardy. None of the workarounds has helped. I tried removing the keys from the keyring and reimporting them, but that did not help either.

Strangely, I can still install packages from the main repositories without problems, isn't that a bit of a security risk? The medibuntu key has the problem since I imported it the first time around, so I can't install any packages from that repository.

Any tips?

Bartek (tschew) wrote :

apt-get update http debug logfile

DogFoodTaster (tayloral23) wrote :

I followed the fix found in this thread ( http://ubuntuforums.org/showthread.php?t=179303 ). The person in the thread, though, seemed to reexperience the problem after a short while, but so far I have not.

The fix is just to back up sources.list, delete everything in it and run "apt-get update". After the update replace sources.list with the backup and run "apt-get update" again. You should not get the error then.

Tideida (matiaslaertiada) wrote :

I get the same error message, but in my native spanish

W: Ha ocurrido un error durante la verificación de la firma. El repositorio no se ha actualizado y se usarán los archivos de índice anteriores. Error de GPG: http://ar.archive.ubuntu.com hardy-updates Release Las siguientes firms fueron inválidas: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>

W: Imposible obtener http://ar.archive.ubuntu.com/ubuntu/dists/hardy-updates/Release

W: Algunos archivos de índice no se han podido descargar, se han ignorado,
o se ha utilizado unos antiguos en su lugar.

Tideida (matiaslaertiada) wrote :

DogFoodTaster:

I try with that solution, but doesnt work for me. I have the same error message than before.

techieMoe (techiemoe) wrote :

I am also still receiving this error after trying the fix by "DogFoodTaster."

W: GPG error: http://archive.ubuntu.com hardy-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>

I have been steadily receiving this error for several days now. I have tried changing mirrors (I'm currently pointed at the main Ubuntu mirror). I've tried removing and re-adding the keys. Every time the default key above is reported as invalid. When is this going to be fixed?

Sean Tindale (sean.tindale) wrote :

I have this same problem with Hardy. But it goes away after 1/2 a day or so.

My take on this is that apt is doing its job correctly, but the alert / message that is being displayed to the user could be reviewed.

W: GPG error: http://archive.ubuntu.com hardy-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address>

Maybe this could be abbreviated into a more user friendly message that will not lead the user into thinking that their system is in some way compromised.

Just a thought...

Dirk (ubuntu-tobit) wrote :

sudo bash

apt-get clean
cd /var/lib/apt
mv lists lists.old
mkdir -p lists/partial
apt-get clean
apt-get update

Sean Tindale (sean.tindale) wrote :

Hi Dirk

Can you please explain what the above list of commands is trying to achieve?

Thanks

techieMoe (techiemoe) wrote :

I have no idea what Dirk's instructions did, but I no longer see the error. I'll post back if it shows up again.

techieMoe (techiemoe) wrote :

Dirk's instructions worked for a couple of days, but the BADSIG error showed up again this morning.

Andrew Cooks (acooks) wrote :

I believe that this error is caused by a caching proxy which returns stale files, instead of actually retrieving the latest files from the mirror and returning that. In my case, it is a transparent squid proxy.

I added
Acquire::http::No-Cache "true";
Acquire::http::Max-Age "0";
to
/etc/apt/apt.conf.d/10broken_proxy

On inspection of the HTTP traffic, the correct headers were sent in the request, but the proxy happily ignored them and returned a cached response.

I guess I should report this as a squid bug, but that will not help the majority of users experiencing this problem any time soon.

William Ferguson (wlferguson) wrote :

I think Andrew pegged the issue. I am experiencing the same problem which started shortly after we added a Bluecoat web filtering / caching device in to our network. I tried setting up an SSH connection to my house and forwarding the traffic through my home connection (bypassing our cache) and the problem went away.

Guys...I have a problem with my update manager. I'm a new ubuntu user. Right now I'm having this error and I can't update my OS:

Fetched 422kB in 8s (50.6kB/s)
W: GPG error: http://archive.canonical.com hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://packages.medibuntu.org hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2EBC26B60C5A2783
W: GPG error: http://archive.ubuntu.com hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://us.archive.ubuntu.com hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://us.archive.ubuntu.com hardy-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://us.archive.ubuntu.com hardy-backports Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://us.archive.ubuntu.com hardy-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: GPG error: http://us.archive.ubuntu.com hardy-proposed Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5
W: Failed to fetch file:/var/cache/prevu/hardy-debs/./Packages.gz File not found

E: Some index files failed to download, they have been ignored, or old ones used instead.

NuclearPeon (initial-dann) wrote :

I think I may have found a fix. I would get this error and none of the above solutions would work.

W: GPG error: http://packages.medibuntu.org gutsy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2EBC26B60C5A2783
W: You may want to run apt-get update to correct these problems

I opened up a text editor as root and began exploring the /etc/apt/ directory hoping to find the source of the problem.
Voila.
There is a directory called "sources.list.d/" and inside was a file containing the medibuntu information that was stumping apt-get.
I deleted the file and all was well once again.

Hopefully this helps.
NuclearPeon of PeonDevelopments.

NuclearPeon's suggestion worked. I was playing with the medibuntu.list today and thats where all the problems starting coming in. After logging into root and deleting it, everything returned back to normal.

Andrew Cooks (acooks) wrote :

Let's be clear: the problem is not with the medibuntu repositories, but the symptoms might be more pronounced when using those repositories.

Here's another temporary work-around for the people who don't use the medibuntu repositories:
Go to System -> Administration -> Software Sources
Select a different mirror
Update

When the problem returns, try switching repositories again. By switching the mirror, you are asking for a different set of URLs which should hopefully not be cached yet.

knokkels (knokkels) wrote :

Hi, I am also a newbie with the same problem, and as I was reading this thread I decided to look up medibuntu in the repo's.. There is a package called medibuntu keyring (search for medibuntu and you will find it). select and install (apply) it and it won't give the error anymore.
What it does is sign the packages digitally.

hobak_0mega (nasanbaga) wrote :

I was in the same boat as knokkels, but with a regular google search for the 'medibuntu keyring' i found

sudo apt-get update && sudo apt-get install medibuntu-keyring

I also changed mirrors, like Andrew suggested, and the sudo bash code like Dirk exampled, and now it's smooth sailing.

Changed in update-manager:
milestone: ubuntu-6.06 → none
status: Incomplete → New
abdullah (demirabdullah) wrote :

wget -q http://packages.medibuntu.org/medibuntu-key.gpg -O- | sudo apt-key add -

Tricky (richard-nixon) wrote :

This has been giving me problems for several weeks and I was beginning to despair of gettign a solution (meaning I would have to give in to my peers and install RHEL)

Using a Bluecoat proxy at work I tried the suggestions to run the following commands with no success:-
  sudo apt-get update -o Acquire::http::No-Cache=True
  sudo apt-get update -o Acquire::BrokenProxy=true

Following advice above from William Ferguson to use a different proxy I am now getting sucessfull updates. This is repeatable across several machines in my VMWare farm.

We also have a number of squid proxies in several countries and I confirmed it's an issue with at least 1 (but not all) of them. Unfortunately I don't think I can get the version's or config details.

Eiht (eiht27) wrote :

Same as everyone above I was getting this error on Hardy. I added the keyring like knokkels did and it went away....so far. Thanks for the help everyone. It first was just annoying but then it started to show an error on auto updates too. Thanks.

Eiht.

heh thx .. has been running smoothly eversince :)

Knokkels

On Tue, Sep 2, 2008 at 11:27 PM, Eiht <email address hidden> wrote:

> Same as everyone above I was getting this error on Hardy. I added the
> keyring like knokkels did and it went away....so far. Thanks for the
> help everyone. It first was just annoying but then it started to show
> an error on auto updates too. Thanks.
>
>
> Eiht.
>
> --
> GPG error with apt-get (BADSIG 40976EAF437D05B5)
> https://bugs.launchpad.net/bugs/24061
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "apt" source package in Ubuntu: New
> Status in "update-manager" source package in Ubuntu: New
>
> Bug description:
> I keep getting this when i launch the update manager.
>
> W: GPG error: http://archive.ubuntu.com breezy-updates Release: The
> following
> signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic
> Signing Key <email address hidden>
>
> How can I fix it?
>

Thanks for this knokkels,

sudo apt-get install medibuntu-keyring
sudo apt-get update

you rock! Another annoyance bites the dust.

w00t :)
thanks you all .. Guess I am not that much of a n00b after all :)

*bows*

On Fri, Sep 5, 2008 at 10:17 PM, billythekid <email address hidden> wrote:

> Thanks for this knokkels,
>
> sudo apt-get install medibuntu-keyring
> sudo apt-get update
>
> you rock! Another annoyance bites the dust.
>
> --
> GPG error with apt-get (BADSIG 40976EAF437D05B5)
> https://bugs.launchpad.net/bugs/24061
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "apt" source package in Ubuntu: New
> Status in "update-manager" source package in Ubuntu: New
>
> Bug description:
> I keep getting this when i launch the update manager.
>
> W: GPG error: http://archive.ubuntu.com breezy-updates Release: The
> following
> signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic
> Signing Key <email address hidden>
>
> How can I fix it?
>

Daniel T Chen (crimsun) wrote :

As it's impossible for apt or update-manager to work around truly broken proxies, I'm closing this bug.

Changed in update-manager:
status: New → Invalid
Changed in apt:
status: New → Invalid
ac (atul-chauhan9) wrote :
johnrobert (jrfay) wrote :

Thanks to everyone for this thread, and especially to knokkels for the keyring solution that has worked for me. I've just been able to update my system for the first time in weeks.

Peter Funk (pf-artcom-gmbh) wrote :

I got:
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used.GPG error: http://de.archive.ubuntu.com jaunty-proposed Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>

Replacing de.archive.ubuntu.com with archive.ubuntu.com in the line containing jaunty proposed fixed this
for me. May there is a problem on the de (germany) mirror?

Ben (ben2talk) wrote :

W: GPG error: http://archive.canonical.com karmic Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>

I'm just curious why?? I just re imported this signature and reloaded a couple of times...

Dan Kortschak (dan-kortschak) wrote :

I am having the same problem, but using ftp without a proxy (we have proxy authentication problems using http/apt here):

Reading package lists... Done
W: GPG error: ftp://au.archive.ubuntu.com jaunty-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>
W: You may want to run apt-get update to correct these problems

So, at least for this case it is not a matter of apt working around truly broken proxies. Pointing to other repos (ftp://mirror.internode.on.net/) results in no error.

catphive (catphive) on 2010-02-10
Changed in apt (Ubuntu):
status: Invalid → Confirmed
Changed in update-manager (Ubuntu):
status: Invalid → Confirmed
catphive (catphive) wrote :

This happens to me in karmic with ftp as well.

Whether it is ubuntu's fault or not, there needs to be a fix. Throwing up your hands just makes it impossible for a lot of people to use Ubuntu.

Apt-get on Ubuntu is too fragile right now, and breaks whenever anyone sneezes in its general direction. Transparent proxies are a fact of life for most companies. If canonical wants people to use ubuntu in an enterprise setting, they need to fix it.

W: GPG error: ftp://us.archive.ubuntu.com karmic-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>

Rolf Leggewie (r0lf) on 2010-02-17
summary: - GPG error with apt-get (BADSIG 40976EAF437D05B5)
+ GPG error with apt-get/aptitude/update-manager behing proxy (BADSIG
+ 40976EAF437D05B5)
summary: - GPG error with apt-get/aptitude/update-manager behing proxy (BADSIG
+ GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG
40976EAF437D05B5)
description: updated
description: updated
Scott Robbins (scottro11) wrote :

This still exists. As mentioned in the duplicate https://bugs.launchpad.net/ubuntu/+source/apt/+bug/24234
it's been an issue for 5 years.

The fix that works for me is stated by Geoff in the other bug

sudo apt-get update -o Acquire::http::No-Cache=true

Whether this works in all cases or not, I don't know. However, from an advocacy standpoint, regardless of who or what is at fault, it's a bad thing, probably frightening to newcomers.

Perhaps ensuring that a message along with it would solve the problem. As it is, it's cryptic, giving no indication that it's a minor issue that will probably disappear in an hour Something along the lines of, after the error message, please try running sudo apt-get update -o Acquire::http::No-Cache=true, then run apt-get update again would be an explanation that newcomers can understand, one that would probably fix the issue, which will probably continue, since it often just seems to be a minor glitch, and not scare people off.

turned out to be bad physical ports on a router i was useing.

> Date: Fri, 26 Mar 2010 14:42:37 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 24061] Re: GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5)
>
> This still exists. As mentioned in the duplicate https://bugs.launchpad.net/ubuntu/+source/apt/+bug/24234
> it's been an issue for 5 years.
>
> The fix that works for me is stated by Geoff in the other bug
>
> sudo apt-get update -o Acquire::http::No-Cache=true
>
> Whether this works in all cases or not, I don't know. However, from an
> advocacy standpoint, regardless of who or what is at fault, it's a bad
> thing, probably frightening to newcomers.
>
> Perhaps ensuring that a message along with it would solve the problem.
> As it is, it's cryptic, giving no indication that it's a minor issue
> that will probably disappear in an hour Something along the lines of,
> after the error message, please try running sudo apt-get update -o
> Acquire::http::No-Cache=true, then run apt-get update again would be an
> explanation that newcomers can understand, one that would probably fix
> the issue, which will probably continue, since it often just seems to be
> a minor glitch, and not scare people off.
>
> --
> GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5)
> https://bugs.launchpad.net/bugs/24061
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “apt” package in Ubuntu: Confirmed
> Status in “update-manager” package in Ubuntu: Confirmed
>
> Bug description:
> I keep getting this when i launch the update manager.
>
> W: GPG error: http://archive.ubuntu.com breezy-updates Release: The following
> signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic
> Signing Key <email address hidden>
>
> How can I fix it?
>
> comment from Rolf Leggewie: This is due to cache inconsistencies and thus is not necessarily a bug in Ubuntu at all. But I hope the fine devs can find a way to better deal with broken proxies. This is a very visible issue, a large number of internet connections are behind proxies and the users cannot do anything about it.
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/24061/+subscribe

_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_2

Luis Mondesi (lemsx1) wrote :

Ok. So I switched to using apt-cacher-ng for my caching and started to see this bug again.

To fix this, just remove all the Sources, Packages and Translation files from /var/cache/apt-cacher-ng (apt-cacher has the same issues) directory. Example:

DIR=/var/cache/apt-cacher-ng
cd $DIR || exit 1
for file in Release Packages Sources Translation; do
 find . -type f -name "*$file*" -exec rm {} \;
done

After that I would be able to run apt-get update and everything would be fine.

Perhaps this bug should include apt-cacher and apt-cacher-ng as they are both part of this problem and they need new logic to update those control files mentioned above.

Martin Forest (martin-forest) wrote :

On the apt-cache-ng server, I just removed all content in the directory /var/cache/apt-cacher-ng/uburep/dists and restarted apt-cache-ng. I no longer have the error. All cached files are in /var/cache/apt-cacher-ng/uburep/pool/ so removing the dists info, does not generate a lot of internet traffic...

(I 've had this issue since 8.04. I'm now running 10.0.4 and ran in to the same issue... I wonder...)

Finger crossed for the rest of you!
/Martin

Does this issue occur in Maverick?

Changed in update-manager (Ubuntu):
status: Confirmed → Incomplete
Changed in apt (Ubuntu):
status: Confirmed → Incomplete
Micah Gersten (micahg) wrote :

Already confirmed on Lucid with a previous comment.

Changed in apt (Ubuntu):
status: Incomplete → Confirmed
Changed in update-manager (Ubuntu):
status: Incomplete → Confirmed
george7 (geomonroe) wrote :

the bad router was from the wgr family the physical ports stopped working after a firmware update

Oliver Stieber (oliverthered) wrote :
Download full text (3.3 KiB)

Ok, I had this [or at least something oh so similar].

first I tried the
    sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update

    sudo apt-get update

work around, with no success.
then:
cd /var/lib/apt
sudo mv lists lists.old
sudo mkdir -p lists/partial
sudo apt-get update

which worked.
So then I thought, seeing as no-one seems to have a clue what's going on and the bug has been in apt-get or a dependency for a log time I'd spend a few minutes to find out what the problem really is.
(one of the files that failed for me was a release repository file so it's static SFAIK)
ls list
'file that failed'
ls lists/partial
'file that failed'
'file that failed'.gpg
delta lists/'file that failed' lists/partial/'file that failed'

deta says.
Bits before MD5Sum: in lists/partial file contain the HTML of my landing page.
Bits before MD5Sum: in lists contain HTTP like header (line separated key colon space value pares)

So this identifies a couple of potential problems on it's own, if not more.
1: even though the file fails the .gpg checksum or whatever it is test, no mention of any way to examine and then 'force' apt to fix the problem e.g. junk the file is apparently offered or given.
2: Two separate HTTP requests to two (or more) separate locations are made to build a composite file up, but validation is somewhat lacking (on either the date returned[thought that's what I think the .gpg is for?], or that the file serving up the files actually matches that which has been requested.

file in partial and in lists had same date.
So I assume the date of the landing page was compared against the date of the file in lists, but the date in one of the parts of the body or somewhere was used for the file date.
so
1: dates of the multiple parts of the file should match, and this is not being tested for.
2: (should be fixed by the above/possibly) the date that used to check to see if an update is needed comes from a different request than the date of the actual file itself.

it doesn't matter if the .gpg file is in partial or not, effect is still the same.
touch -m on the file in partial, with a date before the file date, causes a new file to be fetched.

So there seem to be quite a number of bugs in just the way this fault presented itself on my computer 'Ubuntu 10.04'

url/ip address validation and that kind of thing should possibly be looked at, or at-least allow the user to lock them. I have no idea why the file is in multiple parts, that should have the same date and I imagine be on the exact same server, but not validation is performed to that regard.

should files in partial be validated when update (or whatever) is called and the user asked if they want to junk old crappy ones before continuing?

I think the error should really give a bit more info, other errors tell you what to do, or work around (sometimes they don't actually fix the issue, but it's a start!)

anyhow, I'm going to pull some source down, and hope I don't have to shut my eye's too often whilst fixing this one.(soon hopefully)

Ok, that all took me about 50mins to find out after having a poke around.
I expect there are other bugs, so I'll do a good ...

Read more...

Oliver Stieber (oliverthered) wrote :
Download full text (4.0 KiB)

Ok, I had this [or at least something oh so similar]. BADSIG

All I did was
first I tried the
    sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update

    sudo apt-get update

work around, with no success.
then:
cd /var/lib/apt
sudo mv lists lists.old
sudo mkdir -p lists/partial
sudo apt-get update

which worked.

then install kdiff3
delta the directories to see what was wrong.
identify the differences between the good and the ugly (list.old)

one error was against archive.canonical.com lucid Release
I thought that would be a nice stable file to pick, seeing as fixes don't get put into the release repo.

and in the delta 'archive.canonical.com_ubuntu_dists_lucid_Release' showed up with oddness.

Here's a brief write up of what I identified and how. I'm also going to poke through the code from the BADSIG message and see if it's pretty damb easy to read the code and backtrace the problem. (or at-least release a version that actually collects the info that hasn't been for 5 years, in lieu of a 'proper' fix)

then work out as follows:

So then I thought, seeing as no-one seems to have a clue what's going on and the bug has been in apt-get or a dependency for a log time I'd spend a few minutes to find out what the problem really is.
(one of the files that failed for me was a release repository file so it's static SFAIK)
ls list
'file that failed'
ls lists/partial
'file that failed'
'file that failed'.gpg
delta lists/'file that failed' lists/partial/'file that failed'

deta says.
Bits before MD5Sum: in lists/partial file contain the HTML of my landing page.
Bits before MD5Sum: in lists contain HTTP like header (line separated key colon space value pares)

So this identifies a couple of potential problems on it's own, if not more.
1: even though the file fails the .gpg checksum or whatever it is test, no mention of any way to examine and then 'force' apt to fix the problem e.g. junk the file is apparently offered or given.
2: Two separate HTTP requests to two (or more) separate locations are made to build a composite file up, but validation is somewhat lacking (on either the date returned[thought that's what I think the .gpg is for?], or that the file serving up the files actually matches that which has been requested.

file in partial and in lists had same date.
So I assume the date of the landing page was compared against the date of the file in lists, but the date in one of the parts of the body or somewhere was used for the file date.
so
1: dates of the multiple parts of the file should match, and this is not being tested for.
2: (should be fixed by the above/possibly) the date that used to check to see if an update is needed comes from a different request than the date of the actual file itself.

it doesn't matter if the .gpg file is in partial or not, effect is still the same.
touch -m on the file in partial, with a date before the file date, causes a new file to be fetched.

So there seem to be quite a number of bugs in just the way this fault presented itself on my computer 'Ubuntu 10.04'

url/ip address validation and that kind of thing should possibly be looked at, or at-least allow the user to lock them. ...

Read more...

Philip Guyton (phil-lxnet) wrote :

I am using apt-cacher-ng on 10.04 and had this problem.
Things were complicated by me having forgotten about a file:-
cat /etc/apt/apt.conf.d/80aptcacherng
Acquire::http { Proxy "http://127.0.0.1:3142"; };

So I first removed this file such that I could have no apt-cacher-ng via command line and turn on via synaptic settings network after the following.

I then did:-

sudo rm -rf /var/cache/apt-cacher-ng/uburep/dists/*
sudo /etc/init.d/apt-cacher-ng restart
(thanks to Martin Forest above)

sudo apt-get clean
sudo mv /var/lib/apt/lists /var/lib/apt/lists.old
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get clean
sudo apt-get update
(thanks to Oliver Stieber and others)
I have put some clean's in there as well.

I add this comment as having tried a variety of 'fixes' that didn't the above worked for me.
Hope this helps someone.

Pieter (diepes) wrote :

No 100% sure if i have the same problem.

$ sudo apt-get update
...
Fetched 2,673B in 5s (446B/s)
Reading package lists... Done
W: GPG error: http://extras.ubuntu.com maverick Release: The following signatures were invalid: BADSIG DB141E2302FDF932 Launchpad Application Review Board PPA
W: GPG error: http://archive.canonical.com lucid Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <email address hidden>
$

I fixed it with info from here
http://ohioloco.ubuntuforums.org/showthread.php?t=803585
sudo bash
apt-get clean
cd /var/lib/apt
mv lists lists.old
mkdir -p lists/partial
apt-get clean
apt-get update

Philip Guyton (phil-lxnet) wrote :

Like Pieter above I have recently received a BADSIG DB141E2302FDF932 error along with the original BADSIG 40976EAF437D05B5 on a different machine to my previous post. The procedure I used earlier in this thread worked to clear the BADSIG 40976EAF437D05B5 error but not the other one.

from
http://ubuntuforums.org/showthread.php?t=1632093

I got:-
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DB141E2302FDF932

which worked for me but I am unsure if this is a safe fix. Please comment if you can confirm the correctness of the above.

Vish (vish) on 2010-11-30
description: updated
description: updated
Changed in update-manager (Ubuntu):
importance: Medium → Low
Changed in apt (Ubuntu):
importance: Undecided → Low
Vish (vish) wrote :

Looks like this is a quite a well-known issue in debian systems.
- Virtual Box even mentions this workaround in their Linux downloads page:
"What to do when experiencing The following signatures were invalid: BADSIG ... when refreshing the packages from the repository? " <http://www.virtualbox.org/wiki/Linux_Downloads>

Changed in update-manager (Ubuntu):
assignee: Michael Vogt (mvo) → nobody
Changed in apt (Ubuntu):
status: Confirmed → Won't Fix
Changed in update-manager (Ubuntu):
status: Confirmed → Won't Fix
Changed in apt (Ubuntu):
status: Won't Fix → Triaged
Tim Cutts (timc) wrote :

Robbie, why has this been triaged as "Won't fix?" this causes real problems for people trying to run Ubuntu on machines behind Squid proxies that they don't control (for example in a corporate or university environment).

It seems to me that an appropriate fix would be for apt-get clean to actually remove the cached lists files, as well as the partial directory contents. At the moment, there's no apt-get command which properly cleans the downloaded files.

As such, this is really a problem in Debian, not Ubuntu, and should be passed upstream.

This happens to me if update-mangager starts before I've had a change to type the proxy password (pretty much every day in the office)

It would be nice if apt would wipe the BADSIGs on a restart, so that I can get a fresh list after typing the proxy password without manually removing files in /var/lib/apt/lists/. I'm going to have to cron it otherwise. Why does it not overwrite BADSIGs with new ones?

Alternatively I'm going to have to get update-manager to wait a bit until 10 minutes after login to start downloading.

Colin Watson (cjwatson) wrote :

As far as I can see, the problem here is that apt is inappropriately caching files that fail validation, rather than removing them and allowing them to be fetched again. Fixing that would probably be enough to consign this bug to the dustbin of history, which I'm sure would be welcomed by all concerned.

I put a bit of effort into coming up with a reliable reproduction case for this bug. I've attached a 'dummy-proxy' script, which is a trivial Twisted server that can be used as an HTTP proxy; it listens on localhost:8080 and returns some junk HTML in response to every request. Run it in one terminal. In another terminal, run:

  chdist create captive-portal
  echo 'deb http://archive.ubuntu.com/ubuntu lucid main' >~/.chdist/captive-portal/etc/apt/sources.list
  chdist apt-get captive-portal update
  # should complete successfully
  http_proxy=http://localhost:8080/ chdist apt-get captive-portal update
  # should fail
  chdist apt-get captive-portal update
  # now this fails with BADSIG

Changed in apt (Ubuntu):
importance: Low → High
Colin Watson (cjwatson) wrote :

I suspect that the exact causes of this have shifted over time. The two relevant cases in precise (at least assuming that my test case is sufficient) seem to be:

  InRelease renamed to Release despite signature failure
  IndexDiff files moved to /var/lib/apt/lists/ despite parse failure

The latter is easily fixed by reordering pkgAcqDiffIndex::Done, I guess, but I'm puzzled by the former. In pkgAcqMetaIndex::Failed it appears to be deliberate:

   /* Always move the meta index, even if gpgv failed. This ensures
    * that PackageFile objects are correctly filled in */

So if an HTTP proxy returns some junk for anything you ask for, including an InRelease file that wouldn't exist if we were actually talking to the real archive, we'll save that as Release? This seems bizarre. Can we deal with the problem alluded to in that comment some other way?

David Kalnischkies (donkult) wrote :

The idea is that even if the signature can't be checked (= key is not in the keyring) that we still use the Release file to decide which files to download (e.g. pdiffs/translations available?) and use the Hashsums for checking. The later doesn't provide a good trust path, but playing man-in-the-middle is a bit harder this way and we can detect download failures. The commits adding this should have some more reasons for it included (i don't have the source handy currently for quoting)

So what we should do is discard the (In)Release file in some cases (bad signature) and keep it in others (key not in keyring).

Barry Warsaw (barry) on 2012-01-13
Changed in apt (Ubuntu Precise):
status: Triaged → In Progress
tags: added: rls-mgr-p-tracking

open your terminal and do this

sudo rm -rf /var/lib/apt/lists/*
sudo apt-get update

Changed in apt (Ubuntu Precise):
assignee: nobody → RajaSekharReddy Genupula (genupulas)
assignee: RajaSekharReddy Genupula (genupulas) → nobody
Barry Warsaw (barry) on 2012-04-13
Changed in apt (Ubuntu Precise):
status: In Progress → Triaged
Changed in apt (Ubuntu Precise):
status: Triaged → Fix Committed
Andrew Cooks (acooks) wrote :

People who added to this bug report had a number of different issues.
1. Some people did not import the relevant keys. For them, something like "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DB141E2302FDF932" solved their problem.
2. Some people had bad files on the local box (through proxy or direct download) and for them the fix was "sudo mv /var/lib/apt/lists /var/lib/apt/lists.old ; sudo mkdir -p /var/lib/apt/lists/partial"
3. Some had bad cached content on a normal, by-passable proxy. For them, the fix is "sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update"
4. Some had transparent Proxy authentication problems, which cannot be fixed in ubuntu. (authenticating fixed it for the user)
5. Some had transparent proxy problems with bad cached content on the proxy, which can't be fixed in ubuntu. (changing the mirror, so that the url did not match what the proxy had cached, fixed this.

It's a long bug report. I might have missed a different kind of problem or two, but for everyone the symptoms looked the same (that's how they got here).

I don't see how this bug could possibly be fixed for all the different root causes listed here and if you close this bug, the information for some of these problems will essentially be lost.

Is there a better place to document this and help people find their specific problem?

Changed in apt (Ubuntu Precise):
status: Fix Committed → Triaged

I am on a university network that fake DNS responses to re-direct you to a login page before you are allowed to access the external network. This is a pretty common setup for wifi on e.g. airports, restaurants, hotels, etc.

I hit this bug reliably if an apt-get update is run while I am connected to the network but not logged in. Presumably apt-get thinks it is fetching index files, but gets copies of the login page instead, which breaks the cache. It is possible that a lot of these bug reports are caused by Ubuntu's automatic update of the apt cache running while the user is on such a network.

Apart from the annoyance, isn't this a security issue? Since Ubuntu default is to automatically update the package index without user request, one cannot be sure what kind of network the user is on when it happens. If it is an untrusted network there is obviously the risk of denial-of-service (breakage of the user's apt cache), if not worse (feed user fake data?). Isn't some kind of key-signature thing needed before any changes happens in the apt cache?

Paul Perkins (catmatist) wrote :

My DSL modem, when the network is down, responds to anything http with a page redirecting to an error page on the modem. I found some examples of this in some of the *Release files in my /var/lib/apt/lists. Hard to imagine why apt-get prefers a local copy that it has PROVED to be bogus over re-fetching the file from the server.

security vulnerability: no → yes
description: updated
René Lara (rlla-personal) wrote :

WORKAROUND:
----------
Run the following commands(saves a backup of the old lists and creates a new lists folder) and the BADSIG error does not occur :

$ cd /var/lib/apt
$ sudo mv lists lists.old
$ sudo mkdir -p lists/partial
$ sudo apt-get update

Worked just fine

Andrew Cooks (acooks) wrote :

The proposed workaround does not work if the connection is still being intercepted and returning invalid responses. It addresses point 2 of comment #70, but not the other four causes.

I suggest that a challenge-response mechanism could help to detect intercepting proxies and provide better feedback to the user. Any feedback on the idea would be appreciated.

When a BADSIG error occurs....
1. Send a random string to a specific Ubuntu Web service.
2. Calculate a hash of the same string.
3. Compare the server response to the calculated hash. If a non-error response is received without the hash occuring anywhere in the response, the connection has been intercepted.
4. If it has been determined that the connection is being intercepted, the user can be alerted of the potential reason for the BADSIG error. If using a gui tool, the user can be guided to determine if the problem is an authentication issue (by opening a page in a browser) and given the opportunity to cancel the update or confirm the cause of the problem and retry.
5. If the same, or very similar response is received in future, we can discard the response and abort and optionally remind the user of the previous cause of the problem.

Paul Perkins (catmatist) wrote :

The specific bug I am interested in is case 2 from comment 70: 2. Some people had bad files on the local box (through proxy or direct download) and for them the fix was "sudo mv /var/lib/apt/lists /var/lib/apt/lists.old ; sudo mkdir -p /var/lib/apt/lists/partial".

This can happen because of common, transient network errors and I'm sure the black hats have ways of inducing or simulating such errors as well. The bug is NOT that Ubuntu doesn't notice that the files are bad. The bug is that when it notices that the files are bad, it responds only by rather quietly suspending updates from the repositories corresponding to the bad files. The BAD SIG error message does not even go anywhere that the user is going to see until they start investigating and try running command line tools instead of the GUI stuff. To me the obvious first step in fixing this is for the update manager to automatically apply the manual "fix" of clobbering the bad files in /var/lib/apt/lists, and if that doesn't work, wave a red flag at the user.

The security implication that I see is that this bug represents a way for bad guys to block security updates to selected machines, possibly forever.

Steve Langasek (vorlon) on 2012-10-10
Changed in apt (Ubuntu):
assignee: nobody → Brian Murray (brian-murray)
Brian Murray (brian-murray) wrote :

Regarding point #2 in comment #70:

2. Some people had bad files on the local box (through proxy or direct download) and for them the fix was "sudo mv /var/lib/apt/lists /var/lib/apt/lists.old ; sudo mkdir -p /var/lib/apt/lists/partial"

The issue of apt creating bad files on disk in /var/lib/apt/lists/ has been fixed in the quantal release of Ubuntu which will become Ubuntu 12.10. Details regarding the fix appear in this changelog:

apt (0.9.7.5ubuntu2) quantal; urgency=low

  Merged from lp:~donkult/apt/experimental:

  [ David Kalnischkies ]
  * apt-pkg/contrib/strutl.cc:
    - support \n and \r\n line endings in ReadMessages

  [ Michael Vogt ]
  * lp:~mvo/apt/webserver-simulate-broken-with-fix346386:
    - merge fix for LP: #346386

I've tested that version of apt with the dummy-proxy provided by Colin Watson and I received the following message in a terminal after running apt-get update:

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://archive.ubuntu.com precise Release: The following signatures were invalid: NODATA 1 NODATA 2
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/precise/Release
W: Some index files failed to download. They have been ignored, or old ones used instead.

After this I was able to use apt-get update again without having to clear the files in /var/lib/apt/lists. You may find some further information about this bug in bug 346386.

We are currently working on getting this fix into the -proposed repository for 12.04 and a comment will be added to bug 346386 indicating when it is available and how to test it.

I'll do some further research into update-manager's behavior if there are bad files in /var/lib/apt/lists and open a new bug as needed. There are likely some user interface improvements that should be made if index files are corrupt or fail to download.

Changed in apt (Ubuntu Quantal):
status: Triaged → Fix Released
Brian Murray (brian-murray) wrote :

Bug 997200 has some details about improvements that could be made to update-manager.

The fix for apt is now available in precise-proposed and details regarding testing can be found in bug 346386. I'm going to set the Precise task to Fix Released rather than risk forgetting to close this bug when apt moves to precise-updates.

Changed in apt (Ubuntu Precise):
status: Triaged → Fix Released
Tiago Neiva (tneiva) wrote :

I'm running Quantal and on Wifi captive portals the issue still happens apt broken

I know how to fix, but less tech savy users get lost...

ValeryK (valerykononenko) wrote :

Last week I try to update my kubuntu 12.04x64, but with mistakes, today I do:
sudo rm -rf /var/lib/apt/lists/partial
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get clean
sudo apt-get update
and then I see again and again:
Не удалось загрузить (failing to load?) gpgv:/var/lib/apt/lists/partial/extras.ubuntu.com_ubuntu_dists_precise_Release.gpg

Just ran into this problem on 13.10. If a fix was released 12 months ago why is it still happening?

My situation seems similar to all the rest, rather than a 404 my satellite ISP returns nonstandard error messages about link outage if it does not return results in time and apt-get got permanently screwed up from it.

John A Meinel (jameinel) wrote :

FWIW, I do see this occasionally, but I'm guessing my ISP is doing transparent proxy caching. However,
 sudo apt-get update -o Acquire::http::No-Cache=true
Did fix it for me.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.