[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#820910: apt no longer verifies repositories using sha1 hash



Control: severity -1 wishlist

On Wed, Apr 13, 2016 at 05:27:21PM +0200, Michal Suchanek wrote:
> Package: apt
> Version: 1.2.10
> Severity: important
> 
> Hello,
> 
> I tried to install a compiler from emdebian because there is no
> corresponding version in debian main archives and
> 
>  - apt warns that the source uses SHA1 hash
>  - the package is shown as untrusted

There are three types of failure:

001. Release file signed with GPG signature using SHA1
010. Release file containing no SHA256/SHA512 field for an index
100. Packages file containing no SHA256/SHA512 field for a package

And what happens is:
  001 => warns about repository/release file
  010 => errors about repository/release file
  100 => gives a hash sum mismatch AFAIUI

So you have both issues 001 and 100 with that repository, or what
do you mean by package is untrusted?

> 
> Since no exploit is known for sha1 apt (and aptitude) should show
> warning about weak hash but not show the packages as untrusted.

For the vast majority of SHA1 issues, that's the case. Only a small
minority of repositories is affected by the change in a strong way.

> 
> I canot tell totally unsigned packages from packages which use hash that
> Debian maintainers somehow dislike.

Yes, you can. Unsigned packages can be installed due to "reasons".

It's not about dislike. It's about having SHA1 repositories for 5 years
if we don't deprecate it now (due to Ubuntu LTS shipping that APT for 5
years).

We need to do some more work to get weakly signed repositories
treated as some form of untrusted, I'd expect that to arrive in the
next months.

We also need to generally rethink untrusted repository handling,
currently we have some magic flags like --allow-unauthenticated
and (--no)-allow-insecure-repositories; it would be much better
to make those configurable per source instead, and I'd like
the following behavior:

 Turn related errors into warnings

Following the slogan: Complain as hard as possible, even if the user
tells us it's OK. Maybe we can have some

I-Really-Know-What-I-Am-Doing-Do-Not-Warn-Me-About-Security

field for people to really disable even the warnings. If we do, it
should be unreasonable long, a pain to write, and convey what it is
doing in a very loud way, so users get the message. Otherwise people
write guides like:

""
Please add
   deb [trusted=yes] http://example.com/debian stable main
to your sources.list
""

If it says:

""
Please add
   deb [trusted=yes,ireallytrustthisevenifitisinsecuredonotwarnmeabout it=true] http://example.com/debian stable main
to your sources.list 
""

people are less likely to just do it...

> 
> This is unacceptable with many archives around using these hashes.

s/many/small minority of/

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.


Reply to: