While investigating a checksum mismatch error today, DSA and me
would have had a much easier time if APT would print the received
HTTP headers on such an error.

IOW:

When printing...

 E: Failed to fetch http://deb.debian.org/debian/pool/main/p/pyjwt/pyjwt_2.10.1-2.dsc  File has unexpected size (24636 != 2390). Mirror sync in progress? [IP: 199.232.18.132 80]
    Hashes of expected file:
     - SHA256:18c7ac34d689629fef29f06a3de41a4c998c2a4ee42f9c36d7ebcaa12e051e8c
     - Filesize:2390 [weak]
     - MD5Sum:1dd7eb9413a1831538d87c7a1627d266 [weak]

..., please also print all received HTTP headers (including values),
for example (but not limited to) X-Served-By, X-Cache, X-Cache-Hits,
Age, Via, Last-Modified, Content-Length, Date.

Thanks,
Chris

Control: tag -1 wontfix
the user experience, and carries significant security concerns as
well. All the headers need to have unsafe characters removed, etc.

We have many many years ago implemented a hook system for mirror
failure reports that nobody actually started using, but that would
be the appropriate infrastructure to use.

We should rather go in the opposite direction: Error messages should
include actionable information for the user. Neither the hashes nor
the sizes are relevant in the error message, and we should not show
them; the correct error would be:

E: Failed to fetch http://deb.debian.org/debian/pool/main/p/pyjwt/pyjwt_2.10.1-2.dsc; mirror seems damaged.

That's all they need to know, and adding more information just confuses
them into wondering what _they_ should do about it.

Hello Julian,

* Julian Andres Klode <jak@debian.org> [250227 11:35]:

How does that work and how would that tie into the existing
infrastructure?

How do you propose we debug these seldomly but occuring problems?

Enabling debug flags that print debug messages regardless if there
is an error or not is not an option for these jobs.

Chris

Verbose errors also is some option.

But basically this is a use case for automatic telemetry and not a good
thing to shaft on users. The existing mirror failure code isn't exactly
optimal, it simply runs

/usr/lib/apt//apt-report-mirror-failure <mirror> <uri> <failure code> <error message>

But this is what should be extended and made to work with plain
non-mirror sources.

Then you can install some "apt-report-mirror-failure" package that
automatically sends mirror failures to some DSA https endpoint or
something, rather than force users to figure out how to contact
the mirror operator.

APT's method only speaks GET so you need to add POST support to it
or urlencode it all in parameters, or use sendmail on DSA
infrastructure - if deb.debian.org downloads fail on debian.org
machines, automatic emails just work.

Or add that into APT natively, but anyway, the point stands, details
for mirror operators are not relevant to end users.

Hi,

This is conceptually different from "the mirror is broken because it has
a signature that we no longer consider secure". What you are suggesting
will cause a DDoS (or require a CDN to handle with edge compute) if the
archive's origin data is broken, that we then have no way of stopping.

What we are asking for here is a way to get sufficient information from
the original request to ease debugging. This information is already
printed fine when Debug::Acquire::http(s) is turned on - but you cannot
identify retroactively what went wrong. I'm fine if this is filtered for
printable characters only.

I am with you that the existing information is not useful, especially
because you also get no information whatsoever about the file you
actually got - beyond the size, which is far from unique. I don't think
the addition of debug information is a problem UX-wise, the existing
setup is. Debugging information does not need to be actionable by
itself, the error message needs to be sensible. Context can then be used
to debug. So I'm also fine if you reword the error message, as long as
we can get more debug info - just like you'd normally get a stack trace.

Kind regards
Philipp Kern