message "The repository is insufficiently signed by key (weak digest)" is poorly worded
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt (Ubuntu) |
Fix Released
|
High
|
Unassigned |

Launchpad Janitor (janitor) wrote : | #1 |
Changed in apt (Ubuntu): | |
status: | New → Confirmed |

Gérard Bigot (gerard-bigot) wrote : | #2 |
google chrome repositories is one of the other.
It looks like SHA1 signing keys has been deprecated : https:/
Please at least add SHA2 in PPAs.

dino99 (9d9) wrote : | #3 |
Explanations about the 1.2.7 changelog:
https:/
Indeed that message is now uselessly worrying users. Please silence that "104 warning message"; it will only scared the community.
tags: | added: xenial |

Michael Marley (mamarley) wrote : | #4 |
Hmm, it looks like the combination of the warnings and errors may be especially confusing. I have several PPAs and the Google Chrome repository on my system. The PPAs have the packages themselves signed with SHA256, but the GPG key is only SHA1. These repositories should work, but display an error message after an "aptitude update". The packages in the Chrome repository are signed only with SHA1, so those won't work at all, producing an error message. However, Synaptic displays all the warnings and errors together and says that it is an Error, which tricked me into thinking that none of the repositories would work.
Obviously, the PPAs need to be updated to use a stronger key. I can't see any way to do this manually though.

dino99 (9d9) wrote : | #5 |
@ Michael
i've not tried your ppas, but canonical-x one, and the upgraded packages can be loaded as expected, even if the error is shown (as explained into #3 link).
On your side, to upgrade your ppas, i suppose you need to: 1) purge the actual key(s), 2) build new one(s) with sha2 to please the new apt.

dino99 (9d9) wrote : | #6 |
@Michael
i've activated your 'staging' ppa , and i confirm the pachage (plasma) is not loaded as it should (synaptic used)

Michael Marley (mamarley) wrote : | #7 |
I know that the PPAs need new keys, but it is not obvious how to do that. After extensive searching, I still cannot figure out how to do that.

Colin Watson (cjwatson) wrote : | #8 |
No, the PPAs don't need new keys - we just need to upgrade the digest algorithm used for signing. See the bug of which I've just marked this as a duplicate.

Colin Watson (cjwatson) wrote : | #9 |
Actually, I guess this may not be a duplicate because there may be other third-party repositories that need to do similar things (signing with --digest-algo SHA512 or the equivalent). But see bug 1556666 for the PPA case.

Trent Lloyd (lathiat) wrote : | #10 |
I have 6 external repos configured, and all 6 fire the warning.
If nothing else, the warning really needs to be re-worded. "insufficiently signed" and then (weak digest) at the end is not very straight forward.
W: gpgv:/var/
deb http://
deb [arch=amd64] http://
deb http://
deb http://
deb http://
deb http://

Lonnie Lee Best (launchpad-startport) wrote : | #11 |
I'm having the same issue with the google talk plugin, remmina, shutter, and variety:
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: Failed to fetch http://
E: Some index files failed to download. They have been ignored, or old ones used instead.

Lonnie Lee Best (launchpad-startport) wrote : | #12 |
Can someone please set this bug to the highest reasonable importance?
summary: |
- After upgrading to apt 1.2.7 in Xenial, PPAs and most other third-party - repositories become unusable with "The repository is insufficiently - signed by key (weak digest)" + message "The repository is insufficiently signed by key (weak digest)" + is poorly worded |
Changed in apt (Ubuntu): | |
importance: | Undecided → High |

Rich Bos (rb-i) wrote : | #13 |
Confirming the bug here, I have the following on my server -
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

heiko (heikosch) wrote : | #14 |
Confirming the bug here, I have the following on my machine:
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

Julian Andres Klode (juliank) wrote : | #15 |
For further information on the topic, take a look at the upstream wiki page tracking broken repositories and explaining the two levels of brokenness:
https:/
Feel free to add other repositories there.
@heiko: The PPAs are pending, but WRT Google Earth: There was no new release in the repository since Thu, 19 May 2011 16:50:30 +0000 (6.0.3.2197-r0 is the most recent in there) - it might be a good idea to delete the source.

Ralf Hildebrandt (ralf-hildebrandt) wrote : | #16 |
Ironically, I tried to install some debug symbols today and also got these messages:
W: gpgv:/var/

Cavsfan (cavsfan) wrote : | #17 |
I can confirm that I've been seeing this the past couple of days too:
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
I do know that these are just warnings, but will confuse some people.
Changed in apt (Ubuntu): | |
assignee: | nobody → trebor271074 (trebor271074) |
Changed in apt (Ubuntu): | |
assignee: | trebor271074 (trebor271074) → nobody |

Springbank (springbank) wrote : | #18 |
Same bug here:
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

BlackMage (blackmage) wrote : | #19 |
Same here:
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

Achim Behrens (k1l) wrote : | #20 |
I dont think this is a bug. The wording says what the issue is. The Key used is only sha1 which is considered too weak. The ones using that old Keys should fix their repos and make proper signing.

Jose Barakat (josebarakat) wrote : | #21 |
Many repositories are affected:
As already reported, Google's repos and:
AppGrid
W: gpgv:/var/
Intel Graphics
W: gpgv:/var/
Dolphin Emulator
W: gpgv:/var/
PCSX2 Emulator
W: gpgv:/var/
Libretro Retroarch
W: gpgv:/var/
Clementine (Media Player)
W: gpgv:/var/
WebUpd8
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
Variety
W: gpgv:/var/
PPSSPP Emulator
W: gpgv:/var/
KODI / XBMC
W: gpgv:/var/
Tony George PPA
W: gpgv:/var/
Freshlight
W: gpgv:/var/
gstreamer0.
W: gpgv:/var/

psamuel (persaudsamuel) wrote : | #22 |
Estoy presentando el mismo inconveniente con estas ppa
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

otto06217 (otto-kesselgulasch) wrote : | #23 |
Hi,
I'm just uploaded new gegl and gimp packages. to my PPA - ppa:otto-
After building I don't had no trouble anymore with apt-get update and apt-get upgrade.
I added
"personal-
cert-digest-algo SHA256
default-
to my gpg.conf before debuild -S -sd
I hope this helps.

Colin Watson (cjwatson) wrote : | #24 |
Yes, see my most recent comment in bug 1556666 for the current state of things with regard to ppa.launchpad.net.

Flávio Oliveira (oliveiradeflavio) wrote : | #25 |
All PPAs I have, on the site launchpad says are compatible with Ubuntu 16.04
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
Only Megasync I downloaded the deb
W: gpgv:/var/

Pavlushka (pavelsayekat) wrote : Re: [Bug 1558331] Re: message "The repository is insufficiently signed by key (weak digest)" is poorly worded | #26 |
Re-add the PPAs.
On Wed, Mar 23, 2016 at 9:15 PM, Flávio Oliveira
<email address hidden> wrote:
> All PPAs I have, on the site launchpad says are compatible with Ubuntu
> 16.04
>
> W:
> gpgv:/var/
> The repository is insufficiently signed by key
> 4CCA1EAF950CEE4
>
> W:
> gpgv:/var/
> The repository is insufficiently signed by key
> 36E81C9267FD138
>
> W: gpgv:/var/
> baert_simplescr
> repository
> is insufficiently signed by key
> 4DEDB3E05F043CA
> (weak digest)
>
> W: gpgv:/var/
> kesselgulasch_
> insufficiently signed by key FB97E9C3A97F85C
> (weak digest)
>
> W: gpgv:/var/
> release_
> insufficiently
> signed by key 6976C1CEB065860
>
> W:
> gpgv:/var/
> The repository is insufficiently signed by key
> 7B2C3B0889BF570
>
> W:
> gpgv:/var/
> The repository is insufficiently signed by key
> 7B2C3B0889BF570
>
>
> Only Megasync I downloaded the deb
>
> W:
> gpgv:/var/
> The repository is insufficiently signed by key
> BF8B66E01192CBA
>
> --
> You received this bug notification because you are subscribed to the
> bug
> report.
> https:/
>
> Title:
> message "The repository is insufficiently signed by key (weak
> digest)" is poorly worded
>
> Status in apt package in Ubuntu:
> Confirmed
>
> Bug description:
> The title pretty much says it all.
>
> To manage notifications about this bug go to:
> https:/

Søren Holm (sgh) wrote : | #27 |
I tried that already with no luck.

Shuhao (shuhao) wrote : | #28 |
If I have my own ppa, do I need to do anything? It's not 100% clear in this thread.

Colin Watson (cjwatson) wrote : | #29 |
You do not need to do anything if you have your own PPA. Furthermore, people do not need to keep reporting individual PPAs that are signed with weak digests. We'll fix them in bulk, hopefully quite soon (still working on the last bits of code for that).

Julian Andres Klode (juliank) wrote : | #30 |
After a lot of further input, the text was changed in APT 1.2.8 to read:
W: http://
The other message:
W: Failed to fetch http://
now has an E in front of it:
E: Failed to fetch http://
This should hopefully clarify things and be less annoying.

Colin Watson (cjwatson) wrote : | #31 |
On Thu, Mar 24, 2016 at 09:16:22PM -0000, Julian Andres Klode wrote:
> E: Failed to fetch http://
> file /var/lib/
> considered strong enough for security purposes
Could you please drop that comma while you're here? Unlike German, it
modifies the meaning in English in a way that doesn't make sense: it
implies that there is no Hash entry (should that be lower-case instead?)
at all, and that this situation is considered strong enough for security
purposes. That's obviously nonsensical, and removing the comma so that
the relative clause is restrictive rather than non-restrictive fixes the
grammar.

David Kalnischkies (donkult) wrote : | #32 |
We had the intention (#818639) but forgot it then so only zh_CN was fixed in 1.2.8 … I commited the comma-drop now [I would like to claim that this comma makes perfect sense in German but even there it is a bit strange].

Đorđe (djole94hns) wrote : | #33 |
Considering Debian doesn't allow new account creation on it's Wiki, I'll just post it here so someone else can add it to their list:
RAVEfinity PPA
gpgv:/var/

Mark Duncan (eattheapple) wrote : | #34 |
Cannot install Hipchat either
W: Failed to fetch https:/

Mark Duncan (eattheapple) wrote : | #35 |
Is there a way to force my system to accept these keys anyway? I'd much prefer to be warned that this is using a less secure hash rather than being blocked from accessing these repos.

Mathieu Comandon (strycore) wrote : | #36 |
IMO, this verification and error message needs to be removed from Xenial before it ships in April.
Right now, all major external repositories have not made the switch from SHA1, not even PPAs hosted by Canonical itself.
The graphical updater shows a cryptic and unhelpful error message (Check your Internet connection.) because of this and I cannot imagine the amount of confusion that will ensue following Xenial's release if this is not reverted. I've seen *very frequently* people come at LUGs totally confused and thinking their Ubuntu install is broken because of very similar issues.
I personally have an external repository hosted on openSUSE Build Service which is unusable right now on Xenial because of this. I had to find out about the upgrade from SHA1 to SHA2 as a regular user and not as a repository maintainer, and even if I wanted to do something about it, I can't because it's openSUSE's responsibility to do it. The exact same thing is true for everyone using PPAs on Launchpad.
A bunch of warnings should not result in an error (E: Some index files failed to download. They have been ignored, or old ones used instead.) and it should totally NOT tell non technical users to "Check their Internet connection"!
SHA1 was OK for a good number of years amd all of a sudden, it becomes so insecure that it should break user's installs? While it is perfectly valid to switch to the superior, more secure SHA2, this migration should NOT be done in such a brutal way, at the expense of normal users and without any kind of notification to external package maintainers.
If SHA1 isn't accepted alongside SHA2 without any repercussions for normal users for at least the next couple years, the result *will be disastrous*.

Mathieu Comandon (strycore) wrote : | #37 |
Turns out that the issue is not as bad as I thought it was. The error message was due to a single repo and not all the repos showing warnings. Removing it got rid of the error message in both the terminal and the GUI updater. The affected repo was the Google Talk Plugin:
W: Failed to fetch http://
Since these kind of repos will produce an error, wouldn't it be appropriate to raise the severity from Warning to Error?

Paul Loughman (snowhog) wrote : | #38 |
I did a Google search on " " and found this old (2009) article from Debian concerning the algorithm used for signing the package digest: https:/
Is it applicable to this issue?

Paul Loughman (snowhog) wrote : | #39 |
Oops! forgot to include what I Googled on: "The repository is insufficiently signed"

Jen Wilson (jen-m) wrote : | #40 |
This should have been a warning for one release before making it a blocking issue. I know Ubuntu hates Google and doesn't want us to install Chrome, but many of us need it. Telling us what we are allowed or not allowed to install is something Microsoft would do. These are our computers. Please allow us to install software that we need.

Nand0 (ferdinandpc) wrote : | #41 |
The same problem:
http://
W: http://
W: http://
W: http://
W: http://
W: http://
W: http://

Colin Watson (cjwatson) wrote : | #42 |
On Sat, Mar 26, 2016 at 09:54:16PM -0000, Jen Wilson wrote:
> This should have been a warning for one release before making it a
> blocking issue. I know Ubuntu hates Google and doesn't want us to
> install Chrome, but many of us need it.
This doesn't block installing Chrome - it's just a warning.

Julian Andres Klode (juliank) wrote : | #43 |
Since APT 1.2.8, the message has been changed, and the "Hash Entry" error message is now "E" instead of "W", so we can close that now.
1.2.9 in proposed also removes the misleading comma in the hash entry message.
Changed in apt (Ubuntu): | |
status: | Confirmed → Fix Released |
no longer affects: | apt |

Julian Andres Klode (juliank) wrote : | #44 |
Also removed the affects apt thing, as there is no bug in the Debian BTS, and APT does not use Launchpad to track bugs.

Julian Andres Klode (juliank) wrote : | #45 |
Just for the record, with the Google Chrome and Talk repos it looks like this now:
W: http://
N: Skipping acquire of configured file 'main/binary-
W: http://
E: Failed to fetch http://
E: Some index files failed to download. They have been ignored, or old ones used instead.

Oded Arbel (oded-geek) wrote : | #46 |
@juliank:
This is still a problem, at least with some repos:
1. `apt-get update` returns a non-zero exit code and so automated scripts that do `apt-get update && apt-get install ...` will fail to install the required packages.
2. Even if we ignore the error, the index files are not being accepted and packages described in the index cannot be installed.
Here is an example of a trying to install the CUDA driver inside an Ubuntu 16.04 docker container:
Step 4 : RUN dpkg -i cuda-repo-
---> Running in 3034cbd1c6e2
Selecting previously unselected package cuda-repo-
(Reading database ... 10067 files and directories currently installed.)
Preparing to unpack cuda-repo-
Unpacking cuda-repo-
Setting up cuda-repo-
OK
Get:1 http://
Hit:2 http://
Hit:3 http://
Ign:4 http://
Get:5 http://
Get:6 http://
Fetched 116 kB in 1s (82.1 kB/s)
Reading package lists...
W: http://
E: Failed to fetch http://
E: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package cuda
As you can see the package is not being installed.

Julian Andres Klode (juliank) wrote : | #47 |
Which means that everything is working intended now.
Don't even complain about Nvidia, that was broken with 1.1 as well, it only has MD5 checksums.

Krzysztof Kowalewski (krzysztofkow92) wrote : | #48 |
W: http://
W: http://
W: http://
W: http://
W: http://
W: http://
W: http://
W: https:/
W: http://

Jen Wilson (jen-m) wrote : | #49 |
> This doesn't block installing Chrome - it's just a warning.
Colin, it does block installing Chrome:
$ sudo apt-get update ; echo $?
...
E: Some index files failed to download. They have been ignored, or old ones used instead.
100

Jose Barakat (josebarakat) wrote : | #50 |
This update just came up now for Xenial:
Cambios para las versiones de apt:
Versión instalada: 1.2.7
Versión disponible: 1.2.8
Versión 1.2.8:
[ Michael Vogt ]
* Get accurate progress reporting in apt update again
[ Julian Andres Klode ]
* Report non-transient errors as errors, not as warnings
* methods/gpgv: Rewrite error handling and message.
Thanks to Ron Lee for wording suggestions
* Use descriptive URIs in 104 Warning messages
* cachefile: Only set members that were initialized successfully
(Closes: #818628)
* Update symbols file
[ David Kalnischkies ]
* do not strip epochs from state version strings (Closes: 818162)
* properly check for "all good sigs are weak" (Closes: 818910)
* handle gpgv's weak-digests ERRSIG
[ Zhou Mo ]
* zh_CN.po: update simplified Chinese translation. (Closes: #818639)
[ Takuma Yamada ]
* Japanese manpage translation update (Closes: 818950)
So, let's see how it goes.

Julian Andres Klode (juliank) wrote : | #51 |
@Jen: Just because some indexes failed to download does not mean that Chrome failed to download. Please actually *read* the error messages. Those saying "Failed to fetch" failed, the others did not.

Jen Wilson (jen-m) wrote : | #52 |
Julian, installing Chrome is blocked. The line starts with an "E:" so it is an error! The message:
"No Hash entry in Release file /var/lib/
Is there a workaround? My users need Chrome and other third-party software that only has SSH1 keys.

Julian Andres Klode (juliank) wrote : | #53 |
That makes no sense, Jen, the repository was fixed last week, see:
https:/
$ curl -s http://
Date: Thu, 24 Mar 2016 17:24:39 +0000
SHA256:
I know this because I use the freaking repository myself, was affected when I introduced the change, and opened the bug at chromium...

Jen Wilson (jen-m) wrote : | #54 |
OK, so maybe one repository is fixed now. What about the rest that we need?
Is there a workaround for installing from a repo that doesn't use SHA256 yet?

Julian Andres Klode (juliank) wrote : | #55 |
@Krzysztof Kowalewski (krzysztofkow92) (Half-)Broken repositories are tracked at

Julian Andres Klode (juliank) wrote : | #56 |
@Jen There is no workaround. The small number of affected repos should be fixed instead. Even of the reported 20 cases in https:/
I fully expect all broken repositories to be fixed within a few months after xenial's release, if not before. All affected parties are informed about that.
And the others that are being warned about *will* break in 2017. There's no way back. There might be some further issues with uncooperative repository providers, but that's a good thing too: If they don't manage to upgrade their repository security until 2017, can you really trust them?
A workaround might come at a later time, as there are some special use cases that need that (archived repositories), but this needs some careful designing. It will not be part of xenial, and we must make very sure that it's as hard to use as possible and still breaks any normal use, as otherwise users will just override the errors and risk being attacked.
So be happy that the few things do not work now, this gives a better incentive for negligent repository owners to fix their broken repositories and prevents users from allowing themselves to be attacked.

Julian Andres Klode (juliank) wrote : | #57 |
JFTR, I am looking at ways to drop the missing hash entry to a warning before the xenial release. But if I do this, this will be temporarily, and will become an error again starting in January. It will also not apply to the Nvidia repository, as MD5 is too weak to be trusted in any case.
But warnings are always dubious: Most tools do not even show them at all (almost all the graphical ones).

Julian Andres Klode (juliank) wrote : | #58 |
But note that this is off-topic for this bug report. This bug report was about a message string which has been fixed since.
So, please for all our sanity, stop commenting here.

Eugene Crosser (crosser) wrote : | #59 |
I've opened Bug #1562733 about failed updates due to "No Hash entry in Release file ... which is considered strong enough for security purposes"

Edd Juglans (ejgn) wrote : | #60 |
<quote> This bug report was about a message string which has been fixed since. </quote>
Still not fixed..!
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/
W: gpgv:/var/

Julian Andres Klode (juliank) wrote : | #61 |
Stop spamming and update your APT (including libapt-pkg5.0 !!!) to 1.2.8 or 1.2.9.

Alex (normadize) wrote : | #62 |
I did update my apt to 1.2.9 today and I'm still getting this warning ...
W: http://

Alex (normadize) wrote : | #63 |
Apologies, I misread your message.

Edd Juglans (ejgn) wrote : | #64 |
My system is fully updated, but still getting these errors.
Is there anyway that launchpad could please let the people responsible for these repos to 'get their ffing finger out'?

Colin Watson (cjwatson) wrote : | #65 |
Edd, if you read up through this bug log you'll see a reference to bug 1556666, which has status on getting this sorted out for PPAs. Please, everyone, stop telling us about PPAs that are weakly signed; we know about it, we're working on it, and further comments are not going to make it happen any faster.

Colin Watson (cjwatson) wrote : | #66 |
As per my most recent comment on bug 1556666, this is now fixed for all xenial Release files in PPAs. Pre-xenial Release files are less important numerically for this, but we know that some people have them enabled on xenial systems, so we'll be re-signing those too over the coming weeks.

William (williamforte) wrote : | #67 |
I get this same error on Ubuntu 16.04 Desktop Beta 2 amd64 when I run `sudo apt-get update` in reference to one of the official Xenial repos.

Colin Law (colin-law) wrote : | #68 |
@Williamforte which one? Copy/paste the relevant section here from the terminal.

Injigo (injigo) wrote : | #69 |
I'm getting this error in a live session of Ubuntu 16.04 Desktop Beta 2 amd64 when I run "sudo apt-get update". This is a fresh boot running directly from an ISO booted from the hard drive. I've added no PPA's.
ubuntu@ubuntu:~$ sudo apt-get update
Ign:1 cdrom://Ubuntu 16.04 LTS _Xenial Xerus_ - Beta amd64 (20160323) xenial InRelease
Hit:2 cdrom://Ubuntu 16.04 LTS _Xenial Xerus_ - Beta amd64 (20160323) xenial Release
Hit:4 http://
Hit:5 http://
Hit:6 http://
Reading package lists... Done
W: gpgv:/var/

Colin Watson (cjwatson) wrote : | #70 |
Injigo, Beta 2 indeed had this problem, but it's already been fixed in more recent daily builds.

pavel bursa (bursap) wrote : | #71 |
Ubuntu 16.04 LTS xenial beta amd64 (2016 0416) - i have only problem with SHA1 while installing www.webmin.com
W: http://
W: http://

franco_bez (franco-bez) wrote : | #72 |
In my case it's only the Virtualbox Repo
W: http://

Wiktor: Nizio (zap-4) wrote : | #73 |
It is actually correct. Compare with comment #30. The message is supposed to be worded this way.

Albert Cutrona (acutbal) wrote : | #74 |
Hello!! :)
I've installed Ubuntu 16.04, fresh install and I've this problem with Chrome.
W: http://
Best regards!!

Eduardo Medina (edu-rm-85-z) wrote : | #75 |
Same problem here with Google Chrome repository. I hope that Google address it soon.
Changed in apt (Ubuntu): | |
assignee: | nobody → brad (bradmiller200593) |

Nick (nick-power) wrote : | #76 |
Gajim:
W: ftp://ftp.

arthurcamargo (camargo-arthur) wrote : | #77 |
in my terminal apt-get update answered:
W: http://
W: http://
W: http://
Changed in apt (Ubuntu): | |
assignee: | brad (bradmiller200593) → nobody |

Mahmoud F.Elshazly (elshazly5) wrote : | #78 |
Ubuntu 16.04 after upgrading
in my terminal apt-get update answered:
W: http://
W: http://
W: http://
W: http://
W: http://
N: Skipping acquire of configured file 'main/binary-
W: http://
W: http://
Can anyone have a a solution for that?

Colin Law (colin-law) wrote : | #79 |
@Mahmoud F.Elshazly (elshazly5) this bug is about the wording of a message, not about specific repositories.
However, only one of the repositories is an Ubuntu repo, and that one is for trusty not xenial, so it is not appropriate to be using it at all. For the non-ubuntu repos you will have to take up the problem with them, or ask in a more appropriate place.

varlesh (varlesh-l) wrote : | #80 |
apt - 1.2.10ubuntu1
ubuntu xenial amd64
W: http://
W: http://

Wiktor: Nizio (zap-4) wrote : | #81 |
@varlesh the information you provided is incomplete. Please tell the developers why exactly you think that the information is incorrectly worded, or what the correct wording is. Otherwise the input you provided might be missed. This message seems to be consistent for all repositories that are signed with SHA1. Why exactly do you think something is wrong?

Dirk De Schepper (deschepper) wrote : | #82 |
I switched to signing my repository with SHA512 encoded 4096 bit key. I still get the same error (No Hash entry in Release file ... which is considered strong enough ...). This is on Xubuntu Xenial 16.04 (amd64), apt version 1.2.10ubuntu1. I checked with apt-key, and the public version of the signing key is present. I'm drawing a blank here.

Dirk De Schepper (deschepper) wrote : | #83 |
- Archive containing Release, Release.gpg and the public key that should authenticate them Edit (5.5 KiB, application/x-tar)

Julian Andres Klode (juliank) wrote : | #84 |
@Dirk That's a completely different error type. Your release file only contains an MD5Sum field. Look at the broken repositories section in https:/

Dirk De Schepper (deschepper) wrote : | #85 |
Thanks, I see the problem now.

Shriramana Sharma (jamadagni) wrote : | #86 |
I have my own local repo and am getting this error for it whenever I try to do apt-get update. I even recently updated the key I use to sign it to RSA/RSA 2048/2048 and also add the two lines in ~/.gnupg/gpg.conf:
cert-digest-algo SHA256
digest-algo SHA256
as recommended at http://

Shriramana Sharma (jamadagni) wrote : | #87 |
Sorry for the noise due to my previous comment #86. It is unrelated to this bug and it was because I was not generating the appropriate SHA256 lines in the Release file. Sorry again.

S_B (souvikb009cmc) wrote : | #88 |
I have also same problem with Google Earth
http://
http://
Some index files failed to download. They have been ignored, or old ones used instead.

Sorin Sbarnea (ssbarnea) wrote : | #89 |
It seems that MongoDB is also broken due to this https:/
Workarounds?

Angel Granados Gonzalez (gelux) wrote : | #90 |
I have a owncloud 9 with Ubuntu 16.04. Today has started this error when I try to do apt-get update.
I have my own local repo and am getting this error for it whenever I try to do apt-get update. I even recently updated the key I use to sign it to RSA/RSA 2048/2048 and also add the two lines in
I add the two lines in
~/.gnupg/gpg.conf:
cert-digest-algo SHA256
digest-algo SHA256
as recommended at http://
And I have del the key and later add key again.
However I still keep getting this error. Please advise as to what I have to do to stop getting this error.
W: http://

Colin Law (colin-law) wrote : | #91 |
@angel-granados-j This bug is about the wording of the error message, not the fact that the error may appear.
For how to avoid it I suggest you ask elsewhere, the ubuntu-users email list for example.

Tonal (tonal-promsoft) wrote : | #92 |
Also
W: http://
W: http://
W: http://

Tonal (tonal-promsoft) wrote : | #93 |
Changed in apt (Ubuntu): | |
assignee: | nobody → yon (thornyon) |

Julian Andres Klode (juliank) wrote : | #94 |
Don't change the assignment on a (fixed) issue please, yon.
Changed in apt (Ubuntu): | |
assignee: | yon (thornyon) → nobody |
Status changed to 'Confirmed' because the bug affects multiple users.