Hi,
On 2025-02-27 12:14, Julian Andres Klode wrote:
On Thu, Feb 27, 2025 at 12:02:13PM +0100, Chris Hofstaedtler wrote:
Hello Julian,
* Julian Andres Klode <j...@debian.org> [250227 11:35]:
> Control: tag -1 wontfix
>
> On Thu, Feb 27, 2025 at 11:21:21AM +0100, Chris Hofstaedtler wrote:
> > Package: apt
> > Version: 2.9.30
> >
> > 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.
>
> I am going to say no; because this is a significant detriment to
> 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.
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.
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.
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
