Bug#715216: qa.debian.org: collab-qa/upload-history: Software trusts "Date" headers which are sometimes set wrong
Package: qa.debian.org
Severity: normal
User: qa.debian.org@packages.debian.org
Usertags: udd
I've found (and reproduced) an issue in the collab-qa/upload-history code.
(By that, I mean the stuff you can get from here:
svn+ssh://paulproteus@svn.debian.org/svn/collab-qa/upload-history )
I was reading the upload_history table, and noticed that one package was
supposedly uploaded on 2019-02-07. Further research indicates that the
file with the bad data is "debian-devel-changes.199902.gz".
Looking at
https://lists.debian.org/debian-devel-changes/1999/02/msg00707.html you
can see one such offending email -- the "Date" header claims the email was
sent in 2019.
I can reproduce this bad data getting output by upload_history by running
collab-qa/upload-history/munge_ddc.py on a one-message sample file that
represents that email.
Given that, we have a few options.
1. Declare "garbage in, garbage out" and make no attempt to clean up the
data.
2. Do something very rigid to, instead of looking at the "Date:" header
which is user-specifyable, look at the mbox file envelope, which says when
the mail system received the message. (Downside: This can be different
based on if people are using email data from master.debian.org's archives
vs. other archives, since it amounts to the eit is
3. Do something like (2) but look at the first "Received" header involving
debian.org. (This can be spoofed if people try, but I think that in
general we are only addressing misconfiguration, not intentional aims to
mislead.)
4. Use the Date header that is in the changes file itself -- for example,
that is "Date: Tue, 24 Nov 1998 12:28:30 -0500" on
https://lists.debian.org/debian-devel-changes/1999/02/msg00707.html ,
which is sane, even though the 2019 date appears in the email message's
"Date:" header
Of these, I like option (4) the best. I will implement that and submit a
patch here. If there is strong disagreement, later on I can redo the work
with a different error-correction strategy.
-- Asheesh.
Reply to: