Bug#878958: marked as done (apt: let admins decide security matters not the apt team)
Your message dated Wed, 18 Oct 2017 10:33:37 +0200
with message-id <20171018101313.GA8411@debian.org>
and subject line Re: Bug#878958: apt: let admins decide security matters not the apt team
has caused the Debian Bug report #878958,
regarding apt: let admins decide security matters not the apt team
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
878958: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878958
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 1.4.8
Severity: wishlist
Dear Maintainer,
Aptitude developers have taken the liberty of deciding for everyone
subjectively what quality of cryptographic signature is adequate for
everyone in a single sweeping decision, without knowing the individual
threat models and assets that the decision is trying to protect. This
decision is in the wrong hands. Sys admins are accountable for the
security of the systems they control, and so responsibility and
control should go to the same people who have accountability.
Specifically, consider the SHA1 removal, documented here:
https://wiki.debian.org/Teams/Apt/Sha1Removal
If the apt team must decide on everyones security standards, blocking
SHA1 was a good move. But that's not the case. The apt suite of
tools could have some sensible defaults as far as which signing
algorithms are accepted or not, but ultimately the admin should be in
control of her own system. Maybe an admin finds SHA256 insufficient,
and requires an even higher standard. Who is the apt team to tell her
which algorithm she may and may not trust?
There is a hack to say trust all, which can even be used on a per
repository basis or all repositories, but this is the wrong mechanism
as it disables validity checking entirely. The sys admin should
control which algorithms are fit for purpose, and the apt tool should
check validity on admin-permitted algorithms.
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (no /etc/apt/preferences.d/* present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- (/etc/apt/sources.list.d/gc2latex.list present, but not submitted) --
-- (/etc/apt/sources.list.d/gc2latex.list.save present, but not submitted) --
-- (/etc/apt/sources.list.d/gc2latex.list~ present, but not submitted) --
-- (/etc/apt/sources.list.d/ring-nightly-main.list present, but not submitted) --
-- (/etc/apt/sources.list.d/ring-nightly-main.list.save present, but not submitted) --
-- System Information:
Debian Release: 9.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508228706 WARNING torsocks[12992]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508228706 WARNING torsocks[12994]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages apt depends on:
ii adduser 3.115
ii debian-archive-keyring 2017.5
ii gpgv 2.1.18-8~deb9u1
ii init-system-helpers 1.48
ii libapt-pkg5.0 1.4.8
ii libc6 2.24-11+deb9u1
ii libgcc1 1:6.3.0-18
ii libstdc++6 6.3.0-18
Versions of packages apt recommends:
ii gnupg 2.1.18-8~deb9u1
Versions of packages apt suggests:
pn apt-doc <none>
ii aptitude 0.8.7-1
ii dpkg-dev 1.18.24
ii powermgmt-base 1.31+nmu1
pn python-apt <none>
ii synaptic 0.84.2
-- debconf information excluded
--- End Message ---
--- Begin Message ---
On Wed, Oct 18, 2017 at 04:24:10AM +0200, Nomen Nescio wrote:
> Package: apt
> Version: 1.4.8
> Severity: wishlist
>
> Dear Maintainer,
>
> Aptitude developers have taken the liberty of deciding for everyone
> subjectively what quality of cryptographic signature is adequate for
> everyone in a single sweeping decision, without knowing the individual
> threat models and assets that the decision is trying to protect. This
> decision is in the wrong hands. Sys admins are accountable for the
> security of the systems they control, and so responsibility and
> control should go to the same people who have accountability.
Not disabling SHA1 until after 2021 (the end of the 1.2 life cycle) did
not seem a reasonable way to go considering recent improvements in
breaking it.
>
> Specifically, consider the SHA1 removal, documented here:
>
> https://wiki.debian.org/Teams/Apt/Sha1Removal
>
> If the apt team must decide on everyones security standards, blocking
> SHA1 was a good move. But that's not the case. The apt suite of
> tools could have some sensible defaults as far as which signing
> algorithms are accepted or not, but ultimately the admin should be in
> control of her own system. Maybe an admin finds SHA256 insufficient,
> and requires an even higher standard. Who is the apt team to tell her
> which algorithm she may and may not trust?
We _will_ continue to decide on a _minimum_ level of security, which is
currently SHA2. The maximum level of security is configurable, though,
so a system can be configured to reject any algorithm by setting
APT::Hashes::<algorithm>::Untrusted "yes";
for example:
APT::Hashes::SHA256::Untrusted "yes";
Someone has to pick sensible minimum standards, and the GPG people
are not interested in it.
This option can be considered stable - I don't plan to remove it.
>
> There is a hack to say trust all, which can even be used on a per
> repository basis or all repositories, but this is the wrong mechanism
> as it disables validity checking entirely. The sys admin should
> control which algorithms are fit for purpose, and the apt tool should
> check validity on admin-permitted algorithms.
You can toggle GPG signature validation to also allow (and warn instead)
SHA1 and RIPEMD/160 by setting
APT::Hashes::SHA1::Weak "yes";
APT::Hashes::RIPEMD/160::Weak "yes";
Since we don't have a way to warn about weak hashes inside Release
and Packages files and so on, this only works for GPG signatures
at the moment. If we ever get a way to warn about these, we can
change that.
There will be no way to get rid of _warnings_, as warnings are
essential to ensure you don't get downgraded essentially.
These options are internal and undocumented, and might change at
random points to -piss of users- ensure re-evaluation of source
security (so it might become I-Really-Want-to-mark-this-as-weak-only
for example). Using them is _extremely_ discouraged, and should be
done for non-critical systems interfacing with legacy data only.
This only works as long as gpgv considers SHA1 as trusted - I'm
not sure if it does anymore?
Anyhow, we already did all that is possible to do at the moment, so
I'm closing this bug.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
--- End Message ---
Reply to: