--- Begin Message ---
Package: apt
Version: 2.9.25
Severity: normal
Hello,
In my unstable chroot, I'm now getting
Notice: Missing Signed-By in the sources.list(5) entry for 'http://ftp.fr.debian.org/debian'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://ftp.fr.debian.org/debian'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://deb.debian.org/debian'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://deb.debian.org/debian'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://incoming.debian.org/debian-buildd'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://incoming.debian.org/debian-buildd'
Notice: Consider migrating all sources.list(5) entries to the deb822 .sources format
Notice: The deb822 .sources format supports both embedded as well as external OpenPGP keys
Notice: See apt-secure(7) for best practices in configuring repository signing.
(note: apparently it shouldn't be apt-secure(7), but apt-secure(8) )
These sources:
deb http://ftp.fr.debian.org/debian/ sid main contrib non-free
deb http://ftp.fr.debian.org/debian/ experimental main contrib non-free
deb http://deb.debian.org/debian/ sid main contrib non-free
deb http://deb.debian.org/debian/ experimental main contrib non-free
deb http://incoming.debian.org/debian-buildd buildd-sid main contrib non-free
deb http://incoming.debian.org/debian-buildd buildd-experimental main contrib non-free
Are all just plain official Debian archive sources. It's not even
clear which Signed-by I would be supposed to use. Apparently giving
signed-by=/usr/share/keyrings/debian-archive-keyring.gpg does avoid
the warning, but shouldn't that already be some default? As it is now,
upgrading apt will make all users have to add that on *all* their
systems to fix the warning, do we really want that?
Samuel
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.13.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt depends on:
ii adduser 3.137
ii base-passwd 3.6.6
ii debian-archive-keyring 2023.4
ii libapt-pkg6.0t64 2.9.23
ii libc6 2.40-5
ii libgcc-s1 15-20241220-1
ii libseccomp2 2.5.5-2
ii libssl3t64 3.4.0-2
ii libstdc++6 15-20241220-1
ii libsystemd0 257.2-1
ii sqv 1.2.1-5
Versions of packages apt recommends:
ii ca-certificates 20241223
Versions of packages apt suggests:
pn apt-doc <none>
ii aptitude 0.8.13-6.1
ii dpkg-dev 1.22.11
ii gnupg 2.2.46-1
ii gnupg1 1.4.23-3
ii gnupg2 2.2.46-1
ii powermgmt-base 1.38
ii synaptic 0.91.4
-- no debconf information
--
Samuel
mdiym42: note to self
mdiym42: make sure your cat is not sleeping in the bass drum before you start playing them
--- End Message ---
--- Begin Message ---
On Mon, Jan 27, 2025 at 08:36:21PM +0100, Samuel Thibault wrote:
> Control: reopen -1
Regarding your action:
1. I have asserted that what you are asking for does not
make sense. By reopening your bug and asking the same
thing again, you are questioning my integrity.
2. I have just spent about 9 hours non-stop without any
food implementing a command to simplify the transition
for users, to the point of total exhaustion. Pulling me
back in with the reopen after that marathon is bringing
me to the edge.
That being said, I will, to the complete detriment of my
ability to sleep tonight, reply to your email and both
reiterate the previous points made, provide more context,
and provide the - I believe, but can't be sure of, because,
again, exhausted - complete analysis of the issue.
To understand the issue, we first must understand the
context of what has happened so far, so let's start
with a reasonably complete timeline:
0. The new .sources format was introduced almost 10 years
ago in APT 1.1 in 2015, with the explicit statement of
deprecatind the legacy format:
> It is intended to make this format gradually the default format and
> deprecating the previously described one line style format as it is
> easier to create, extend and modify by humans and machines alike
> specially if a lot of sources and/or options are involve.
The support for embedded ASCII keys was added in the APT 2.3.10
upload in October 2021.
1. The DebConf 22 talk explicitly gives a timeline for
signing changes:
- 2022/12 Notices for missing Signed-By in .sources files
- 2023/06 Warnings for missing Signed-By in any files
2. The new .sources format has been in use by docker images
since I believe 2022 and we have heavily advocated that
people finally switch now. A debian-installer bug was
filed around the same time to migrate, which has not
been acted upon so far.
3. Leading up to the Ubuntu 23.10 and 24.04 releases,
Canonical and community people have invested significant
resources into adapting tools for deb822 support, both
in Debian directly as well as in downstream-only tools.
4. In contrast to the announced timeline in 1., only in
2025/01 did we enable Notices (and not warnings) for
non-deb822 sources lacking Signed-By, we are trailing
significantly behind.
This means that right now, only users interacting with
the interactive apt(8) command on a tty receive any
messages about sources whatsoever.
After 10 years, I believe we are at the point where
telling people that *still* have not migrated is right,
and we can't be held accountable for the inaction of
other maintainers. We have tried for years to get them
moving, but eventually enough _must_ be enough, and we
must use the only means remaining: technical means.
I believe that the reaction here is over-proportional,
it's the classic "hate mob" mentality of trying to
shove your opinion down by relentlessly attacking
the other side until they burn out and cave in or
leave. I do not think this is healthy for me, or
the project as a whole.
But I admit that the messages in APT are somewhat
verbose. I believe the reduction to a single notice
pointing users at a chance to "modernize their sources"
rather than a notice complaining about missing signed-by
will substantially alleviate concerns.
> A discussion on #debian-devel produced the same idea: can't Signed-By
> just default to /usr/share/keyrings/debian-archive-keyring.asc?
> (+trusted for the moment, and without it when we want to kill it)
>
> (or another path on another distro based on Debian)
>
> That way *most* entries will just continue working, pure debian
> systems won't get a worrysome warning about signatures, and only extra
> repositories will need something (which I agree is a good thing).
>
> What would be the drawback, when the benefit would be so huge?
This is not correct.
As you are well aware, APT maintains rigorous backwards compatibility,
therefore we do not simply want to disable trusted.gpg.d support.
## Theorem: Implicit signed-by requires breaking repositories
If we wanted an implicit default Signed-By, we would no
longer be able to have that fallback, any third-party repositories
would break immediately.
The fallback would/should still cause notices, and we can expect
that most systems have third-party sources, so the benefit is not
clear.
Proof. This doesn't take an expert to consider: If we automatically
fell back from an implicit Signed-By to the globak keyring,
still any key in the global keyring can sign the repository
- we do not gain any security/safety.
## Theorem: Impliced Signed-By must be hardcoded in APT code.
An implicit Signed-By value would need to be hardcoded in APT
based on the distro it is built for. This creates an undue burden
on both the APT maintainers to include all possible downstreams
and on downstream distributions to always rebuild their APT
to pick up the new default keyring.
Proof. Consider the implicit Signed-By value was not hardcoded,
and therefore configurable; keyring packages and end users could
just configure additional keyrings via etc. apt.conf.d snippets
- this is just an obfuscation of the trusted.gpg.d method.
## Uniformity
Please also consider the implementers of tools working with APT
sources, as well as end users. Having to special-case some repositories
rather than having a uniform handling is detrimental to their
experience, as they need to implement/consider the same logic.
> I fear that otherwise we will just see plenty of “bah, add
> trusted=yes” "tooltips" florish on the web, thus the contrary of the
> expected result.
I have specifically considered that today while working on
the modernize-sources branch, and the result is that 'trusted=yes'
must *NOT* remove the notice.
I believe that the work I poured my heart and soul into today,
to total exhaustion and the detriment of my health, to introduce
the `apt modernize-sources` command will significantly reduce
the friction of the transition.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
--- End Message ---