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

2020-02-10 Thread Holger Levsen
hi, today I unclaimed for LTS: - xerces-c (Hugo Lefeuvre) and none for eLTS. Then, the monthly reports for January are due today. Please publish yours, if you haven't already. And, the following DLAs are missing on www.debian.org: ERROR: .data or .wml file missing for DLA 1713-2 ERROR: .da

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

2020-02-10 Thread Emilio Pozuelo Monfort
On 10/02/2020 03:25, Holger Levsen wrote: > hi, > > today I unclaimed > > for LTS: > > - xerces-c (Hugo Lefeuvre) > > and none for eLTS. > > Then, the monthly reports for January are due today. Please publish yours, if > you haven't already. > > > And, the following DLAs are missing on www.

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

2020-02-10 Thread Holger Levsen
On Mon, Feb 10, 2020 at 11:23:08AM +0100, Emilio Pozuelo Monfort wrote: [...] > > ERROR: .data or .wml file missing for DLA 2098-1 > It would be useful if this info came with the person who reserved that DLA. sure. it's just not that easy to get that information programmatically... > If > one of

January LTS Report

2020-02-10 Thread Hugo Lefeuvre
Hi, Here is my LTS report for January 2020. I was allocated 12 hours. I have spent 5.5 of them in the following tasks: libexif: + investigate the issue, and come to the conclusion that a fix will be hard to obtain without access to the reproducer. Contact Ray Essick from Google on behalf

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

2020-02-10 Thread Emilio Pozuelo Monfort
On 10/02/2020 12:07, Holger Levsen wrote: > On Mon, Feb 10, 2020 at 11:23:08AM +0100, Emilio Pozuelo Monfort wrote: > [...] >>> ERROR: .data or .wml file missing for DLA 2098-1 >> It would be useful if this info came with the person who reserved that DLA. > > sure. it's just not that easy to get t

Re: Issues regarding ruby-rack/CVE-2019-16782

2020-02-10 Thread Ola Lundqvist
Hi I have looked into this some but I have not been able to determine how long the session ids were before the fix. Do anyone have that information? Based on that we can rather easily determine how long time a timing attack would take. My guess is a really long time. Best regards // Ola On Mon,

Re: Issues regarding ruby-rack/CVE-2019-16782

2020-02-10 Thread Brian May
Ola Lundqvist writes: > I have looked into this some but I have not been able to determine how long > the session ids were before the fix. Do anyone have that information? > Based on that we can rather easily determine how long time a timing attack > would take. My guess is a really long time. M