How to fix the Ubuntu GPG Error BADSIG

If you are seeing Ubuntu GPG Error BADSIG use the one of the following methods to fix

Error Message

W: GPG error: http://archive.canonical.com intrepid Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key

Method 1

Try to run the following comamnds from terminal

$ sudo -i

# apt-get clean

# cd /var/lib/apt

# mv lists lists.old

# mkdir -p lists/partial

# apt-get clean

# apt-get update

Method 2

Try to run the following comamnds from terminal

sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update

sudo apt-get update

Credit goes here

Sponsored Link

Incoming search terms:

Related posts

35 thoughts on “How to fix the Ubuntu GPG Error BADSIG

  1. Hi guys,
    I’ve tried both methods and sadly neither of them seems to work, I am still having the same error. What should I do?
    Cheers

    [Reply]

  2. Well, I tried the 2nd method first, as it looked a little less like a hammer to crack a nut.

    I’d really like to know what the problem is before doing the first.

    [Reply]

  3. worked 4 me without doing the cleans, YMMV.
    It looks like there’s been some failing in downloading package lists in an atomic way, or at least checking what’s downloaded is good / complete and if not fetching a clean version.

    Maybe it’s just doing a date comparison and not a size, or size is zero in http headers when (tries to remember HTTP protocol without looking it up) INFO request has been made, or a checksum issue. I have no idea how (or apparently how not) apt updates it’s package lists.

    According to kdiff3 (finally in ubuntu, but not installed by default… grr I even used in back in the day with tourtisesvn on windows, cos it’s the best GUI diff.!)

    archive.canonical.com lucid Release failed 4 me.
    archive.canonical.com_ubuntu_dists_lucid_Release and
    archive.canonical.com_ubuntu_dists_lucid_Release.gpg
    are sitting in the partial directory on my backed up lists.

    archive.canonical.com_ubuntu_dists_lucid_Release is also in the backed up lists directory (one above the partial)

    it’s also in the ‘fresh’ fetched lists
    and so is
    archive.canonical.com_ubuntu_dists_lucid_Release.gpg

    but neither are in the fresh fetch partial.

    So I’m thinking that it borked on downloading a gpg key, which has got stuck in partial and fur some odd reason it won’t fetch a new one cos it reacons the one in partial is good as, even though is shouldn’t be in partial is should be in lists if it’s complete.

    So to test that theory.
    delta the gpg key in lists vs lists.old/partial

    Delta says they are identical.
    so now delta lists.old and lists.old/partial none gpg file. (I’m hoping that the lists belonging to the Release ppa doesn’t change, cos it’s fixed to what was released not any updates etc….

    Ok when I do that I find the following:
    In the partial list.old vs list.old there’s a difference in the ‘header’ section of the file (PRE MD%Sum)

    one has some html from the landing page for my mobile broadband and the other has something a bit like a HTTP header:
    Origin: Canonical
    Label: Partner archive
    Suite: lucid
    Version: 10.04
    Codename: lucid
    Date: Tue, 19 Oct 2010 3:05:20 UTC
    Architectures: amd64 armel i386 ia64 powerpc sparc
    Components: partner
    Description: Ubuntu Lucid 10.04

    So I’m guessing that the file is fetched in two parts. apt thinks it’s downloaded it properly (without verify that) and more over it then just does a date check on the file in partial and for some crazy reason the files made up of two separate requests, and no basic validation is performed.
    It then doesn’t bother to fetch a new one, cos it things the one in partial is ok, but it ain’t.

    Either that or the one in lists.old is good and there’s some weirdo conflict going on between partial and lists or it really did fetch the update, but left one in partial with the same name (very odd) and didn’t check the real one, but the one in partial.

    [Reply]

  4. So I’m going to look at the dates on the files to see if they are good or not.

    Ok dates are the same:
    19/10/2004 04:05.

    date in header for file in lists.old differs:
    Date: Tue, 19 Oct 2010 3:05:20 UTC

    but file in lists.old and lists are identical.

    So hypothesis is now either:
    headers are fetched for the list and then compared against either the date in the list (which seems to be wrong, or may be [meaningless to apt-get update] author time stamp and the file didn’t get saved for an hour or was touched later for some reason ) or the timestamp of the file, which seems a far better idea.

    timestamps where different (due to may landing page or whatever),
    then two separate HTTP requests where made to fetch the header section (which would redirect to the landing page) and then the body section of the lists file.

    The file timestamp was then set to something other than my landing page reported, or another request was made to get it(since my landing page works by redirecting the first request)

    No validation was performed on the file [opps, not exactly a secure way to update part of the system management data, on typo missed and released and your only one badly formed list away from a root-kit. ],
    Surely the file actually get read by something at some point, so there’s a chunk of code already in apt that parses and validates the file already.

    So I’m going to copy the ‘not validated’ one from lists.old/partial over to list/partial, but not the corrisponding .gpg file and see what happens when I run an update.
    Then if that works, repeat but with switcharoo on the .gpg files.

    Ok oats blown on first try.
    Ahh and interestingly .gpg no longer in lists but now in partial, so that’s been re-fetched by the looks of things (or possibly just moved)

    Now to remove the ones from lists and leave the one in partial and see what happens.

    ok, same problem.
    So the one that stays in lists is the one reffered to as the ‘old’ list or something like that.

    now put good one in partial and see what:
    That’s all good now.
    files no longer in partial but in lists

    so backdate m time
    sudo touch -t 200910231320 -a archive.canonical.com_ubuntu_dists_lucid_Release*

    apt-get update, and new version is fetched. So date time in header in file is ignored.

    [Reply]

  5. so I recon you can get away with the following:

    sudo rm /var/lib/lists/partial

    with no worries (unless you really care about junk left in partial)

    no need to refetch all the lists in /var/lib/lists again either.

    I’m going to see if someone has actually bothered to fix this… umm… it’s the packaging system for crying out loud! I’ve still got the issue in 10.04, so I’ll see if it’s rectified in 10.10.

    my faith in ubuntu dwindles by the, well it’s got a lot better lately, but, come on lads, broken kde back port repositors that won’t do a clean migrated update without removing some old version packages that are now in new version packages with different names etc….
    apt-get update failing because there are some mangled files in partial, that even when it barfs because their mangled they get left for eternity (or the file date on the server changes)
    and list files being multi-part fetches but there appears to be no check to make sure their from the same place, let along actually belong together.

    been lurking since (at least date of first mentioned workaround)
    November 5th, 2009, 10:35 PM

    But it seems that no investigation has been done, is there even a bug report!

    a quick one liner to rm /var/lib/apt/partial prior to doing an update, would go someway. but the real fix is to check that file is actually a real file that will parse properly and if it fails the checksum or whatever’s in the gpg key to tell the user and give them a command they can run to purge all the old ones. (or uder one of the many existing switches and overload it to either force-all or purge the old partials)

    so apt-get is in the apt package.
    claims front end for dpkg, but dpkg not a direct dependancy.

    [Reply]

  6. so 1hr to find out what the real problem is (including installing some stuff, and writing a log of crap and a rant about why the hell is this bug still in the package managements system)

    [Reply]

  7. Thanks the instructions in method 1 worked for me in Maverick.

    BTW, if you were messing around and did something like sudo apt-key del 12345 while trying to fix it and it now says NO_PUBKEY you can restore it:

    sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 12345

    [Reply]

  8. I concur with some of the others here, sadly, neither method worked for me.

    at the end of it all, I still got:

    W: GPG error: http://ftp.cse.yzu.edu.tw natty InRelease: File /var/lib/apt/lists/partial/ftp.cse.yzu.edu.tw_pub_Linux_Ubuntu_ubuntu_dists_natty_InRelease doesn’t start with a clearsigned message
    W: GPG error: http://ftp.cse.yzu.edu.tw natty-security InRelease: File /var/lib/apt/lists/partial/ftp.cse.yzu.edu.tw_pub_Linux_Ubuntu_ubuntu_dists_natty-security_InRelease doesn’t start with a clearsigned message
    W: GPG error: http://ftp.cse.yzu.edu.tw natty-updates InRelease: File /var/lib/apt/lists/partial/ftp.cse.yzu.edu.tw_pub_Linux_Ubuntu_ubuntu_dists_natty-updates_InRelease doesn’t start with a clearsigned message
    W: GPG error: http://ftp.cse.yzu.edu.tw natty-backports InRelease: File /var/lib/apt/lists/partial/ftp.cse.yzu.edu.tw_pub_Linux_Ubuntu_ubuntu_dists_natty-backports_InRelease doesn’t start with a clearsigned message
    W: GPG error: http://ftp.cse.yzu.edu.tw natty-proposed InRelease: File /var/lib/apt/lists/partial/ftp.cse.yzu.edu.tw_pub_Linux_Ubuntu_ubuntu_dists_natty-proposed_InRelease doesn’t start with a clearsigned message
    W: GPG error: http://packages.medibuntu.org natty InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 2EBC26B60C5A2783
    W: GPG error: http://ppa.launchpad.net natty Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY C5D7718106438B87
    W: GPG error: http://dl.google.com stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY A040830F7FAC5991

    [Reply]

  9. I get this issue so frequently in Lucid. I’ve fixed it in the past with the first method. Only thing you have to do if it’s been fixed this way before is to remove the previous lists.old directory first: “# rm -r /var/lib/apt/lists.old”

    [Reply]

  10. Right after a clean install of Precise Pangolin “apt-get update” gave me this error. (Although I’ve enabled the partner repo too before even trying the APT update.) Neither method described here worked for me. :-(

    [Reply]

    müzso Reply:

    Removing the partner repo (in “Software Center” go to “Edit” / “Software Sources” and click on the “Other Software” tab, then clear both “Canonical Partners” checkboxes) fixed the problem. None of the methods described here were necessary after the repo was removed from the software sources configuration.

    [Reply]

  11. I love u¡¡¡¡ I finally can solve this problem with your help¡¡¡ I was frustrated already :D

    Thank you so much.

    [Reply]

Leave a comment

Your email address will not be published. Required fields are marked *