Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Chris Lamb]

Dear all.

> > The attached patch allows that script to also print author information when
> > using a local copy of the security-tracker repo with the --list option.

This is extremely useful, thank you.

> > ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)

Looking at my Git history, I created DLA 2083's webwml files at the
time and even pushed it to salsa… but I must have neglected to submit
a merge request. I how now done so:

  https://salsa.debian.org/webmaster-team/webwml/merge_requests/366

… and it has been merged.


Best wishes,


-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Re: phppgadmin / CVE-2019-10784

[Ben Hutchings]

On Thu, 2020-02-20 at 21:17 +0100, Ola Lundqvist wrote:
> Hi fellow LTS contributors
> 
> I have started to look into CVE-2019-10784 for phppgadmin.
> 
> After some thinking on how it would be possible to protect against this I'm
> starting to think about whether we really want to protect against this, and
> whether it is in fact possible at all?
> 
> I have ideas on how we can reduce the attack possibilities but I cannot
> find any perfect solution to this.
> 
> What we can do is to check that the User Agent provided Referrer string
> points to the location where it is installed. There are however a few
> disadvantages with this.
> 1) It relies on that the user agent always provide the referrer string. A
> problem is that it is an optional header.
> 2) I think there are situations where "-" is used as the referrer string
> and if we allow that the check is quite pointless.
> I do not think this is a way forward.
[...]

My understanding is that the Referer field is normally provided when
navigating within the same site, though some proxies may remove it.  It
is common practice to use the Referer field to protect against CSRF,
though it's not the most effective mitigation:
.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.



signature.asc
Description: This is a digitally signed message part

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Holger Levsen]

Hi Emilio,

On Wed, Feb 19, 2020 at 10:45:36AM +0100, Emilio Pozuelo Monfort wrote:
> > cd ~/Projects/security-tracker
> > git pull
> > cd ~/Projects/debian-www/webwml 
> > git pull
> > ../cron/parts/10-check-advisories --mode DLA  2>&1
> > 
> > where ~/Projects/debian-www/cron is on the branch mr-origin-1...
> 
> The attached patch allows that script to also print author information when
> using a local copy of the security-tracker repo with the --list option.

cool, many thanks! but it t doesn't work for me, maybe I'm doing it wrong:

~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA 
--list ../../security-tracker/data/DLA/list 
ERROR: .data or .wml file missing for DLA 2103-1 
ERROR: .data or .wml file missing for DLA 2101-1 
ERROR: .data or .wml file missing for DLA 2083-1 
[...]

> Otherwise it should fall back to the status quo. The current output is:
> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg)
[...]

very nice!

> btw I wonder if that script shouldn't leave elsewhere, such as in the webwml
> repo or in the security-tracker.

yeah, very probably...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


signature.asc
Description: PGP signature

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Holger Levsen]

On Thu, Feb 20, 2020 at 07:50:30PM +0100, Markus Koschany wrote:
> > So we should add it to security-support-ended for those releases, and
> > let it be supported in buster.
> 
> We currently also mention it here:
> https://wiki.debian.org/LTS/Jessie
 
oh, ic, I wasn't aware of this page (which exists since 2018) and I'm not sure
I'm in favor of storing information in different places.

I'm considering replacing the words about unsupported packages (in the 
supported packages paragraph of that page) with a link to the 
security-support-ended.deb8 file in debian-security-support.git...

But I'll sleep over it first... :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

phppgadmin / CVE-2019-10784

[Ola Lundqvist]

Hi fellow LTS contributors

I have started to look into CVE-2019-10784 for phppgadmin.

After some thinking on how it would be possible to protect against this I'm
starting to think about whether we really want to protect against this, and
whether it is in fact possible at all?

I have ideas on how we can reduce the attack possibilities but I cannot
find any perfect solution to this.

What we can do is to check that the User Agent provided Referrer string
points to the location where it is installed. There are however a few
disadvantages with this.
1) It relies on that the user agent always provide the referrer string. A
problem is that it is an optional header.
2) I think there are situations where "-" is used as the referrer string
and if we allow that the check is quite pointless.
I do not think this is a way forward.

An alternative way is to generate some temporary approval code that needs
to be provided in the next request. But there are disadvantages with that
too.
1) We may end up in the situation where the admin can just have one browser
tab open. That is highly inconvenient.
2) We cannot use cookies (since it would survive being passed through the
attacker trick site) making it a little more fault prone.
3) They need to be limited in life time to not waste too much database
space, making it less practical.

I think the idea of some kind of temporary approval code is the way to go,
but we probably need to accept quite a few of them and will quite likely
require quite some changes to the software.

Do we think it is worth the effort to do this in oldoldstable?

I would say that it is a stretch that someone can actually make use of this
in practice. There are quite a few things that must be in place at the same
time.

1) The target admin must be logged in to the target service.
2) The attacker must know the target service and know that the target admin.
3) The attacker must trick the target admin to visit some page that (using
some javascript) post to the target service.

This is really a targeted attack. Sure possible, but it is not the most
likely attack either.

I checked phpmyadmin. It has checks against direct call from command prompt
but I could not find any such prevention code for this case. So I guess it
is just as vulnerable.
I guess other site software is also vulnerable.

Is it worth fixing?

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Markus Koschany]

Am 20.02.20 um 18:08 schrieb Emilio Pozuelo Monfort:
...]
> Yes, this was mentioned in the release notes for jessie and stretch:
> 
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8
> https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#libv8
> 
> So we should add it to security-support-ended for those releases, and
> let it be supported in buster.

We currently also mention it here:

https://wiki.debian.org/LTS/Jessie

Markus



signature.asc
Description: OpenPGP digital signature

Re: closing bugs in security uploads and the BTS

[Adam D. Barratt]

On Thu, 2020-02-20 at 17:43 +, Ben Hutchings wrote:
> On Thu, 2020-02-20 at 17:09 +, Holger Levsen wrote:
> [...]
> > sec-master doesn't send mail to the bts. So currently one has to
> > close bugs manually. Or maybe we can change the archive software to
> > do something else.
> > 
> > as this is also the case for stable-security, where such bugs only
> > get closed at pointreleases,
> 
> Is it though?  The packages are copied to -proposed-updates
> immediately after they're released to -security, and I think that
> closes bugs.

Basically. They're copied to stable-new and the bugs get closed when
the package is accepted to p-u by SRM.

However, the BTS doesn't know about packages in p-u, so much of the
state there is only really useful once the packages are actually in
stable.

Regards,

Adam

Re: closing bugs in security uploads and the BTS

[Holger Levsen]

On Thu, Feb 20, 2020 at 11:39:35PM +0530, Utkarsh Gupta wrote:
> Call it stupid but I wouldn't like the Debian bugs to be closed with
> just oldoldstable/Jessie being fixed.
> 
> I'd, however, like something like "Fixed in $version in
> oldoldstable/Jessie" but with the bug being open!
 
yes, this is how version tracking in the BTS works:

#950618 is closed and only fixed in experimental, so #950618 is still open in 
unstable, testing, stable, oldstable and oldstable (in the BTS, as it is closed
in reality for oldoldstable, which prompted this thread).


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: closing bugs in security uploads and the BTS

[Utkarsh Gupta]

Hiya,

On Thu, Feb 20, 2020 at 10:41 PM Holger Levsen  wrote:
> This is because the BTS cannot handle closes of bugs in jessie, even if the
> .changes file contains aa bug closer, because packages ever only land on
> security.d.o but not on ftp-master as there will be not point releases
> containing them.
>
> sec-master doesn't send mail to the bts. So currently one has to close bugs
> manually. Or maybe we can change the archive software to do something else.

Call it stupid but I wouldn't like the Debian bugs to be closed with
just oldoldstable/Jessie being fixed.

I'd, however, like something like "Fixed in $version in
oldoldstable/Jessie" but with the bug being open!


Best,
Utkarsh

Re: closing bugs in security uploads and the BTS

[Holger Levsen]

On Thu, Feb 20, 2020 at 05:43:27PM +, Ben Hutchings wrote:
> Is it though?  The packages are copied to -proposed-updates immediately
> after they're released to -security, and I think that closes bugs.
 
oh, I see, thanks for correcting me!

so this is "just" an issue for LTS then.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Holger Levsen]

On Thu, Feb 20, 2020 at 06:08:52PM +0100, Emilio Pozuelo Monfort wrote:
> So we should add it to security-support-ended for those releases, and
> let it be supported in buster.

done in 
https://salsa.debian.org/debian/debian-security-support/commit/c9b3de34947bc13cad9f18a53d0fb7b512bff0e1


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: closing bugs in security uploads and the BTS

[Ben Hutchings]

On Thu, 2020-02-20 at 17:09 +, Holger Levsen wrote:
[...]
> sec-master doesn't send mail to the bts. So currently one has to close bugs
> manually. Or maybe we can change the archive software to do something else.
> 
> as this is also the case for stable-security, where such bugs only get closed 
> at pointreleases,

Is it though?  The packages are copied to -proposed-updates immediately
after they're released to -security, and I think that closes bugs.

Ben.

> maybe this is something where we can use LTS ressources to
> improve the situation both for LTS and normal security support?

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




signature.asc
Description: This is a digitally signed message part

closing bugs in security uploads and the BTS

[Holger Levsen]

hi,

I just noticed that *via irc* that #950618 "ppp: CVE-2020-8597: Fix bounds
check in EAP code" is fixed in jessie, while https://bugs.debian.org/950618
has no indication of this whatsoever.

This is because the BTS cannot handle closes of bugs in jessie, even if the
.changes file contains aa bug closer, because packages ever only land on
security.d.o but not on ftp-master as there will be not point releases
containing them.

sec-master doesn't send mail to the bts. So currently one has to close bugs
manually. Or maybe we can change the archive software to do something else.

as this is also the case for stable-security, where such bugs only get closed 
at pointreleases, maybe this is something where we can use LTS ressources to
improve the situation both for LTS and normal security support?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Emilio Pozuelo Monfort]

On 20/02/2020 18:00, Salvatore Bonaccorso wrote:
> Hi Holger,
> 
> On Thu, Feb 20, 2020 at 04:49:09PM +, Holger Levsen wrote:
>>> Does LTS provide updates for nodejs/nodejs-*, and is there a place where
>>> we can document this decision?
>>  
>> I'd lean to call it unsupported and document this in 
>> src:debian-security-support.
> 
> I guess you will need to add it to the ended file instead, that is
> declare it end-of-life because not supportable by backporting fixes --
> unsupported covers all suites, and this as you noticed was the reason
> to remove it again from there as we tentatively want to be able to
> support nodejs in buster.

Yes, this was mentioned in the release notes for jessie and stretch:

https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#libv8

So we should add it to security-support-ended for those releases, and
let it be supported in buster.

Cheers,
Emilio

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Salvatore Bonaccorso]

Hi Holger,

On Thu, Feb 20, 2020 at 04:49:09PM +, Holger Levsen wrote:
> > Does LTS provide updates for nodejs/nodejs-*, and is there a place where
> > we can document this decision?
>  
> I'd lean to call it unsupported and document this in 
> src:debian-security-support.

I guess you will need to add it to the ended file instead, that is
declare it end-of-life because not supportable by backporting fixes --
unsupported covers all suites, and this as you noticed was the reason
to remove it again from there as we tentatively want to be able to
support nodejs in buster.

Regards,
Salvatore

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Holger Levsen]

On Thu, Feb 20, 2020 at 04:40:39PM +0100, Sylvain Beucler wrote:
> I see nodejs was added to "security-support-limited", then removed again
> because it is supported in buster.

yes, because at first it referred to the situation in stretch, now it refers
to buster.
 
> However there is no information about whether we support this package in
> jessie (and soon stretch).

the debian security team considered nodejs unsupportable in stretch because:

- the version was really old
- nodejs used not to have LTS releases and was very fast moving, only recently 
  upstreams supports older releases
- the modules are also unsupportable, so all issues there are still marked 
no-dsa.

> Also nodejs was recently added to dla-needed.txt.

that "just" means it has issues, not that those issues are fixable with 
reasonable effords/

> Does LTS provide updates for nodejs/nodejs-*, and is there a place where
> we can document this decision?
 
I'd lean to call it unsupported and document this in 
src:debian-security-support.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money.


signature.asc
Description: PGP signature

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Sylvain Beucler]

Hi,

On 03/07/2019 15:44, Holger Levsen wrote:
> package: debian-security-support
> x-debbugs-cc: debian-lts@lists.debian.org
>
> On Wed, Jul 03, 2019 at 02:59:39PM +0200, Sylvain Beucler wrote:
>> I just discovered this while triaging node-fstream:
>> https://www.debian.org/releases/oldstable/amd64/release-notes/ch-information.en.html#libv8
>> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#libv8
>>
>> "Unfortunately, this means that libv8-3.14, nodejs, and the associated
>> node-* package ecosystem should not currently be used with untrusted
>> content, such as unsanitized data from the Internet.
>> In addition, these packages will not receive any security updates during
>> the lifetime of the Jessie release."
> ouch.
>
>> I'm surprised that `grep -ir node` doesn't find any match in the
>> 'debian-security-support' repo.
>> Did I miss something or is it something we should do?
> see above & thanks! :)

I see nodejs was added to "security-support-limited", then removed again
because it is supported in buster.

However there is no information about whether we support this package in
jessie (and soon stretch).
Also nodejs was recently added to dla-needed.txt.

Does LTS provide updates for nodejs/nodejs-*, and is there a place where
we can document this decision?

Cheers!
Sylvain

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Sylvain Beucler]

On 20/02/2020 14:32, Emilio Pozuelo Monfort wrote:
> I still see this in 2019/dla-1993.wml:
>
> # do not modify the following line
> #include "$(ENGLISHDIR)/lts/security/2020/dla-1993.data"
> # $Id: $
>
> Looks like you actually need to modify it :p
>
> Btw if you parse a file with a Date: header, parse-dla.pl will read that and
> place the files in the appropriate dir, so you don't need to do any fixups
> afterwards.
Thanks. I had changed the .data date but not the .wml template.
(and had imported my plain-text dla)

Cheers!
Sylvain

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Emilio Pozuelo Monfort]

On 20/02/2020 13:56, Sylvain Beucler wrote:
> Hi,
> 
> On 20/02/2020 13:35, Emilio Pozuelo Monfort wrote:
>> On 20/02/2020 12:40, Abhijith PA wrote:
>>> Holger,
>>>
>>> On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote:
>>>
>>>
 The attached patch allows that script to also print author information when
 using a local copy of the security-tracker repo with the --list option.
 Otherwise it should fall back to the status quo. The current output is:

 ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. 
 Sánchez)
 ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph 
 Berg)
 ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger 
 Levsen)
 ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian 
 Blank)
 ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
 ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
 ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)
>>> DLA 2053-1 pushed to webmaster-team repo a month ago.
>>>
>>> https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d
>> data/DLA/list says:
>>
>> [31 Dec 2019] DLA-2053-1 otrs2 - security update
>>
>> i.e. this was reserved in 2019. Thus the script that generates this report is
>> looking in the 2019/ folder of the website, but it is actually living in the
>> 2020/ folder, most likely due to parse-dla.pl placing it there because of the
>> Date header of your email (which was sent in 2020).
>>
>> Normally reserving a DLA and sending it a few hours later wouldn't cause
>> significant trouble (except for out of order announcements), but it did here 
>> due
>> to the year offset and how things are archived in the website. Note how also 
>> the
>> source link in [1] is broken.
>>
>> [1] https://security-tracker.debian.org/tracker/DLA-2053-1
>>
>> We have three options here:
>> - move the files in the website to 2019/, breaking the current link
>> - change the date in data/DLA/list to Jan 1 2020
>> - keep the status quo (with the broken link in the tracker) and change the
>>   script to find the files even if they are in another year
>>
>> Given that commit dafc13ef in the security-tracker hasn't broken anything, 
>> I'll
>> just update the date in data/DLA/list to fix the tracker link and getting 
>> that
>> DLA off the report.
> I committed DLA-1993-1 manually in the 2019 folder, fixed the date in
> the .data file, but it looks like this wasn't enough, this is 404:
> https://www.debian.org/lts/security/2019/dla-1993
> https://security-tracker.debian.org/tracker/DLA-1993-1
> https://salsa.debian.org/webmaster-team/webwml/commit/2f79c83e9dac20596a24f6b404cfa2ce1954e3d1
> 
> I guess the web build system has a limitation. Do the webmasters need to
> intervene ?

I still see this in 2019/dla-1993.wml:

# do not modify the following line
#include "$(ENGLISHDIR)/lts/security/2020/dla-1993.data"
# $Id: $

Looks like you actually need to modify it :p

Btw if you parse a file with a Date: header, parse-dla.pl will read that and
place the files in the appropriate dir, so you don't need to do any fixups
afterwards.

Cheers,
Emilio

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Sylvain Beucler]

Hi,

On 20/02/2020 13:35, Emilio Pozuelo Monfort wrote:
> On 20/02/2020 12:40, Abhijith PA wrote:
>> Holger,
>>
>> On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote:
>>
>>
>>> The attached patch allows that script to also print author information when
>>> using a local copy of the security-tracker repo with the --list option.
>>> Otherwise it should fall back to the status quo. The current output is:
>>>
>>> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. 
>>> Sánchez)
>>> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph 
>>> Berg)
>>> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen)
>>> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank)
>>> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
>>> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
>>> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)
>> DLA 2053-1 pushed to webmaster-team repo a month ago.
>>
>> https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d
> data/DLA/list says:
>
> [31 Dec 2019] DLA-2053-1 otrs2 - security update
>
> i.e. this was reserved in 2019. Thus the script that generates this report is
> looking in the 2019/ folder of the website, but it is actually living in the
> 2020/ folder, most likely due to parse-dla.pl placing it there because of the
> Date header of your email (which was sent in 2020).
>
> Normally reserving a DLA and sending it a few hours later wouldn't cause
> significant trouble (except for out of order announcements), but it did here 
> due
> to the year offset and how things are archived in the website. Note how also 
> the
> source link in [1] is broken.
>
> [1] https://security-tracker.debian.org/tracker/DLA-2053-1
>
> We have three options here:
> - move the files in the website to 2019/, breaking the current link
> - change the date in data/DLA/list to Jan 1 2020
> - keep the status quo (with the broken link in the tracker) and change the
>   script to find the files even if they are in another year
>
> Given that commit dafc13ef in the security-tracker hasn't broken anything, 
> I'll
> just update the date in data/DLA/list to fix the tracker link and getting that
> DLA off the report.
I committed DLA-1993-1 manually in the 2019 folder, fixed the date in
the .data file, but it looks like this wasn't enough, this is 404:
https://www.debian.org/lts/security/2019/dla-1993
https://security-tracker.debian.org/tracker/DLA-1993-1
https://salsa.debian.org/webmaster-team/webwml/commit/2f79c83e9dac20596a24f6b404cfa2ce1954e3d1

I guess the web build system has a limitation. Do the webmasters need to
intervene ?

Cheers!
Sylvain

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Emilio Pozuelo Monfort]

On 20/02/2020 12:40, Abhijith PA wrote:
> Holger,
> 
> On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote:
> 
> 
>> The attached patch allows that script to also print author information when
>> using a local copy of the security-tracker repo with the --list option.
>> Otherwise it should fall back to the status quo. The current output is:
>>
>> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. 
>> Sánchez)
>> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg)
>> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen)
>> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank)
>> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
>> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
>> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)
> 
> DLA 2053-1 pushed to webmaster-team repo a month ago.
> 
> https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d

data/DLA/list says:

[31 Dec 2019] DLA-2053-1 otrs2 - security update

i.e. this was reserved in 2019. Thus the script that generates this report is
looking in the 2019/ folder of the website, but it is actually living in the
2020/ folder, most likely due to parse-dla.pl placing it there because of the
Date header of your email (which was sent in 2020).

Normally reserving a DLA and sending it a few hours later wouldn't cause
significant trouble (except for out of order announcements), but it did here due
to the year offset and how things are archived in the website. Note how also the
source link in [1] is broken.

[1] https://security-tracker.debian.org/tracker/DLA-2053-1

We have three options here:
- move the files in the website to 2019/, breaking the current link
- change the date in data/DLA/list to Jan 1 2020
- keep the status quo (with the broken link in the tracker) and change the
  script to find the files even if they are in another year

Given that commit dafc13ef in the security-tracker hasn't broken anything, I'll
just update the date in data/DLA/list to fix the tracker link and getting that
DLA off the report.

Cheers,
Emilio

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Abhijith PA]

Holger,

On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote:


> The attached patch allows that script to also print author information when
> using a local copy of the security-tracker repo with the --list option.
> Otherwise it should fall back to the status quo. The current output is:
> 
> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. 
> Sánchez)
> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg)
> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen)
> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank)
> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)

DLA 2053-1 pushed to webmaster-team repo a month ago.

https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d


--abhijith