Bug#859122: about 500 DLAs missing from the website
On 2019-02-09 03:55:44, Laura Arjona Reina wrote:
> Hello all
> Holger Levsen merged the generated DLAs and I've worked to create the
> /lts tree to show them separated from the DSA. I have moved to this new
> /lts folder the DLAs from years 2014, 2015 and 2016 that we had already,
> and remove them from the /security tree and removed references to DLAs
> in the Makefiles/indexes in /security.
> I think it's mostly done, I've closed all the related MR except one, but
> there are some small tasks left, that I hope we can solve together:
> * I have initially copied the content of /security/ to /lts/security,
> removed subfolders that I think are not needed (audit, key-rollover,
> oval, undated) and some other files that I think they were not needed
> too. Then I did a search and replace DSA -> DLA, dsa- -> dla- in the
> scripts, makefiles and indexes, and fixed the paths, and built locally
> (with "make) and I couldn't spot errors, but I don't trust every file
> that is currently in /lts/security is needed or has been used with my
> "make" command, so a review of the folder (comparing it with /security)
> done by an LTS or security team member, is welcome.
It's true there's a lot of junk in there... I suspect most of the `.pl`
scripts in there could actually be symlink to the main secteam scripts,
because they are basically the same.
I also suspect most of the stuff is unused, even from the secteam's
point of view. For example, `check-cve-refs.pl` assumes there's a
`security/data` directory in the website, which is not the case
(anymore?). I would suggest removing those from at least the LTS
section and have done so in the following MR:
> * The README needs to be reviewed and adapted (I just did the search and
> replace dsa -> dla and DSA -> DLA).
Done as well in the same MR.
> * I guess that parse-advisory.pl (and maybe others) can be removed, but
> I was not confident to do it without advice.
Done as well in the same MR.
> * I didn't check the results of the generated RSS feeds. If anybody uses
> RSS readers, a review is welcome too.
It looks good to me here.
> * The /lts/security/YYYY/index.*.html files show the last advisory for
> the cases where there are several files with the same beginning (e.g.
> for DSA-nnnn and DSA-nnnn-2, both html files are generated, but the
> index only points to the -2 file). If this is not the intended
> behaviour, changes in index.wml and Makefiles are needed.
Ideally, we'd show both, is that possible?
> * Please review the content (text, links) of these files:
> I've tried to be short (for the case translators are fast and then you
> decide to heavy rewrite, to not to loose much work).
That makes sense to me. I wonder if we should link to the
crossreferences.wml content, which is also relevant here.
> * Translations have been handled, but I've left the *title* of these
> files unchanged:
> All those files have title "LTS Security Advisories from YYYY" (being
> YYYY the year: 2014, or 2015, or 2016). I guess translators can do a
> quick search and replace with the correct sentence and they don't need
> to update the commit hash, that's already done. I'll contact translators
> and point them to this message.
> * This new /lts section of the website is not referenced yet in other
> places of the Debian website. I'm not sure if it should be referenced in
> /security, in /releases/XXXX, or in both. There is also the temptation
> of creating a link in the homepage but there is also the suggestion of
> reducing the links in the homepage, so... For now, I'll try to add it to
> the sitemap and see how many references to the LTS wiki page we have
> currently, to see if any of them can be replaced with link to this
> section in the website. But I'll wait some days to do it because it's
> not clear for me if you want to populate the section to cover all the
> aspects of LTS, or keep it only/mainly for security stuff.
I would avoid putting the LTS work too proeminently on the website at
this point, to be honest. The goal of publishing those advisories there,
for me, is coherence: they were already partly present and I wanted to
have them *all* available *somewhere* with a predictable URL and RSS
feeds (as opposed to, say the mailing list).
We shouldn't get into the slippery debate of how much we want LTS
content on the website, in my opinion.
> * We still need the Apache redirects, so the people that try the old
> URLs (wether directly because they knew, or via the security tracker),
> find the files they need. What we need to do is send a patch to
> that sets the redirect from
> https://www.debian.org/security/any_year/dla-whatever to
I'll work on this.
> * Adaptation in the security tracker so the new URL paths are used from
> now on is also needed.
Ironically, I don't believe the URLs are linked from the security
tracker right now. This was originally what I wanted to fix but stopped
when I realized it wouldn't actually work for LTS...
The most prudent course for any society is to start from the
assumption that the Internet should be fundamentally outside the
domain of capital.
- The Internet's Unholy Marriage to Capitalism