Hi Simon, On Mon, July 7, 2008 19:55, Simon Paillard wrote: > Indeed, the current solution doesn't handle DSA-nnnn-x with x > 1. > That is due to the workflow (we try to parse a mail without any strong > structure, while the data are structured in dak / security-tracker, as far > as I understood from Nico Golde). > > That's why I consider this script as a very dirty solution. If you have > the data somewhere and parsable with a known and real structure, that would > be much easier and reliable to prepare wml files.
Yes and no. The current DSA mails are somewhat free-form (this is a quality: special issues sometimes require special text formatting). We do have the security-tracker that has structured information on DSA's, but this information is somewhat limited: it has DSA number, package, CVE refs, related packages and fixed version in etch. You could reconstruct most of the current web pages out of it, with notable exception the full descriptive text. The entries in the security-tracker are also constructed automatically from the DSA mails[1]. I see the following solutions: 1) Use the current script parse-advisory.pl. It may be ugly but it does the trick in nearly all cases. DSA's are committed automatically and the web team reads the commit diffs and corrects after the fact if needed. 2) A hybrid approach combining parse-advisory with as much structured information as is available. dsa2list could be a good starting point. 3) Only use structured information on the website, and link to the mailinglist for the full text. This has the drawback of missing translatability but should make it fully automated even without need for review. cheers, Thijs [1] http://svn.debian.org/viewsvn/secure-testing/bin/dsa2list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
