Comment 10 for bug 1553121

Hi all,

to clarify somthing that might be missunderstood in my previous post.

Of course the hpe stuff is OT. What I meant to say with this, is that the list on https://wiki.debian.org/Teams/Apt/Sha1Removal is still incompletely reflecting the repositories affected, and will probably always be.

There are plenty of additional repositories. Workaround in some cases might be to inherit the repository by adding it after installation. "apt-get update" only displays a warning. We were already doing this because, not all our servers were from HPE, and this works so far with the mentioned warning. ;-)

But in some cases such workarrounds aren't wanted. Or people are simply deploying the repository URL via preseed and get weired errors, now.

At least the last case *should* be fixed, since this will burn a lot of time. IMHO for nothing!

As far as I can see, neither apt-setup and base-installer are dealing with the keys themselves the verification done in debootstrap (used by base-installer) doesn't look like there is anything done with the HASH-Algorithm. Both are dealing with apt-get, but:
| root@xenial-test2:/home/kollstedt# apt-get -o APT::Get::List-Cleanup=false update; echo "return code = $?"
[...]
| Ign:7 http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu trusty/current InRelease
| Hit:8 http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu trusty/current Release
| Reading package lists... Done
| W: http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu/dists/trusty/current/Release.gpg: Signature by key
| 882F7199B20F94BD7E3E690EFADD8D64B1275EA3 uses weak digest algorithm (SHA1)
| return code = 0
Used the HPE for test, since our internal reposiory has a SHA-2-256 now.

I don't see them dealing with any output. ;-)

Any ideas so far?

Kind regards
   Lars