[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Working with gbp and older releases



Am Dienstag, den 18.02.2014, 21:12 +0100 schrieb Dariusz Dwornikowski:
> > > 
> > > ACK. (Reading the upstreams' homepage, you should definitly go for the
> > > latest version. The latest upstream fixes a local DoS.
> > > As a side, please add all CVE-# which closes the new version into the
> > > changelog, please follow the procedure as in [1]))
> > 
> > Thank you, I will do it. 
> 
> Ok the last time I responded I lied that I understood :). I just want
> to confirm, when I release I will close CVE bugs I found here [1] ?
> Correct ? But they do not have a corresponding bugs.d.o bug, so I just
> do: Closes CVE-foo-bar in a changelog, as written in your link ?

Never had a CVE myself, but I think this is the way to go:
technically you don't need a debian bug, you could just write (random
example here [1]) 

maradns (version-1) unstable; urgency=high

 * new upstream release
    - fixes CVE-xxxx-xxxx, CVE-xxxx-xxxx ...

but I would file one "cover" bugs smth like "Serveral security bugs" and
listing alls CVE's in the bug's text and just add a Closes: # to the new
upstream release line. For simplicity, I would just add all CVE's since
which are marked as fixed upstream since 1.4.12. (see below)
For the one without a CVE-Number, maybe just describe the problem and
say that there is no CVE Number.
For the CVE's already fixed by a older version than 1.4.12, it is
allowed to modify the old changelog entries, when the fix was actually
added. At least that's how I read 5.1 in the developer reference:
 
"When closing security bugs include CVE numbers as well as the Closes:
#nnnnn. This is useful for the security team to track vulnerabilities.
If an upload is made to fix the bug before the advisory ID is known, it
is encouraged to modify the historical changelog entry with the next
upload. Even in this case, please include all available pointers to
background information in the original changelog entry."

> > 
> > > 
> > > You should also to file a bug against maradns to document that the
> > > current version has secuirty problemss with the CVE's
> > > http://maradns.samiam.org/security.html has the list.
> > 
> > Ok. 

> I can see that they are documented there. Or I miss something. Number
> 19 is the CVE-None that is fixed in the most current version. Or again
> I did not understand. 

You should consider all since version 1.4.12: #15, #16, #18, #19

> 
> [1] https://security-tracker.debian.org/tracker/source-package/maradns
> 
> -- 
> Pozdrawiam,
> Dariusz Dwornikowski, Assistant
> Institute of Computing Science, Poznań University of Technology
> www.cs.put.poznan.pl/ddwornikowski/
> room 2.7.2 BTiCW | tel. +48 61 665 29 41
> 
> 
> 
> 
[1] https://svn.xiph.org/trunk/vorbis/debian/changelog


Reply to: