Re: limits of automatic unclaiming (Re: pdns/pdns-recursor)

2019-01-11 Thread Holger Levsen
Hi,

it's been a while but I still want to comment on this...

On Thu, Dec 27, 2018 at 05:45:56PM -0500, Antoine Beaupré wrote:
> > Antoine, this is an example were automatic unclaim might be problematic,
> > as it would have unclaimed pdns/pdns-recursor which is not ideal. (For
> > now, just ment as a data point.)
> I'm not sure it would be that problematic. I think Abhijith could
> (should?) have posted a note in dla-needed.txt summarizing this
> situation or adding a pointer to the above email.

FWIW, I do agree with that now, after some thinking. (No, it didnt take
me two weeks :)

> The idea, anyways, is that worst case the issue gets unclaimed and
> reclaimed by someone else. In the above case, Abhijith specifically
> identified that as a *desirable* outcome, so I'm not sure it's really a
> problem.

right.

> Personally, I believe the general case of unexpected unclaims will be
> the package will be unclaimed and *not* claimed by anyone else. At least
> that's my experience of unclaiming "hard" packages that I couldn't
> finish within a month.

sounds likely indeed. 

I guess we just need to get more used to (semi-)automatic unclaims...!


-- 
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: limits of automatic unclaiming (Re: pdns/pdns-recursor)

2018-12-27 Thread Antoine Beaupré
On 2018-12-27 14:16:22, Holger Levsen wrote:
> Hi Abhijith, Antoine,
>
> I just ran "./bin/review-update-needed --lts --unclaim 1814400 --exclude
> linux linux-4.9" today and it unclaimed pdns/pdns-recursor as the last
> NOTE entries were more than 3 weeks ago. However Abhijith wrote here:
>
> On Sat, Dec 22, 2018 at 01:02:06PM +0530, Abhijith PA wrote:
>> I am currently working on pdns[1] and pdns-recursor's[2] security issues
>> and which are marked as no-DSA, postponed. Last month I picked it up as
>> I had some time remaining. Upstream patch is available for the remaining
>> issues(CVE-2018-10851, CVE-2018-14644). Both patches contain C++11
>> specific code and I was only able to port CVE-2018-14644. In
>> CVE-2018-10851 I used 'boost' library's smart pointers to deal with the
>> default C++11 smart pointers, but I am not quite there. I was wondering
>> whether anyone here can _help_ me with it. I don't want to spend anymore
>
> Abhijith, thanks for this update! Just please also update the notes for
> these packages in data/dla-needed.txt.
>
> Antoine, this is an example were automatic unclaim might be problematic,
> as it would have unclaimed pdns/pdns-recursor which is not ideal. (For
> now, just ment as a data point.)

I'm not sure it would be that problematic. I think Abhijith could
(should?) have posted a note in dla-needed.txt summarizing this
situation or adding a pointer to the above email.

The idea, anyways, is that worst case the issue gets unclaimed and
reclaimed by someone else. In the above case, Abhijith specifically
identified that as a *desirable* outcome, so I'm not sure it's really a
problem.

Personally, I believe the general case of unexpected unclaims will be
the package will be unclaimed and *not* claimed by anyone else. At least
that's my experience of unclaiming "hard" packages that I couldn't
finish within a month.

A.

-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.- Lucius Annaeus Seneca (65 AD)



Re: limits of automatic unclaiming (Re: pdns/pdns-recursor)

2018-12-27 Thread Holger Levsen
Hi Abhijith,

On Thu, Dec 27, 2018 at 09:01:32PM +0530, Abhijith PA wrote:
> > Abhijith, thanks for this update! Just please also update the notes for
> > these packages in data/dla-needed.txt.
> I will.

Thank you.

> >> time in it as it is not so popular one and it has no-DSA postponed
> >> priority.
> > pdnsd is used by our sponsors so we should support it as best as we can.
> pdnsd is a different package.

thanks for correcting me. Then adopting 'no-DSA' is probably ok.


-- 
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: limits of automatic unclaiming (Re: pdns/pdns-recursor)

2018-12-27 Thread Abhijith PA


Hi, Holger..

On Thursday 27 December 2018 07:46 PM, Holger Levsen wrote:
> Hi Abhijith, Antoine,
> 
> I just ran "./bin/review-update-needed --lts --unclaim 1814400 --exclude
> linux linux-4.9" today and it unclaimed pdns/pdns-recursor as the last
> NOTE entries were more than 3 weeks ago. However Abhijith wrote here:
> 
> On Sat, Dec 22, 2018 at 01:02:06PM +0530, Abhijith PA wrote:
>> I am currently working on pdns[1] and pdns-recursor's[2] security issues
>> and which are marked as no-DSA, postponed. Last month I picked it up as
>> I had some time remaining. Upstream patch is available for the remaining
>> issues(CVE-2018-10851, CVE-2018-14644). Both patches contain C++11
>> specific code and I was only able to port CVE-2018-14644. In
>> CVE-2018-10851 I used 'boost' library's smart pointers to deal with the
>> default C++11 smart pointers, but I am not quite there. I was wondering
>> whether anyone here can _help_ me with it. I don't want to spend anymore
> 
> Abhijith, thanks for this update! Just please also update the notes for
> these packages in data/dla-needed.txt.

I will.

> Antoine, this is an example were automatic unclaim might be problematic,
> as it would have unclaimed pdns/pdns-recursor which is not ideal. (For
> now, just ment as a data point.)
> 
>> time in it as it is not so popular one and it has no-DSA postponed
>> priority.
> 
> pdnsd is used by our sponsors so we should support it as best as we can.

pdnsd is a different package.


--a