Proven packager help request: DCMTK (and dependent packages) require update in F29/F30

[Ankur Sinha]

Hello,

A CVE[1] in dcmtk was fixed in 3.6.4 which is in F31+. F29 and F30 are
still at 3.6.2 however, and need updating. This includes a soname bump
([2] vs [3]), though, so dependent packages will also need to be rebuilt
and pushed as updates all at once.

sudo dnf repoquery --source --whatrequires 'libdcm*(64bit)'
[sudo] password for asinha:
Last metadata expiration check: 0:53:07 ago on Fri 13 Sep 2019 14:07:55 BST.
OpenImageIO-2.0.7-1.fc30.src.rpm
OpenImageIO-2.0.9-1.fc30.src.rpm
aeskulap-0.2.2-0.37.beta2.fc30.src.rpm
ctk-0.1-0.10.20171224git71799c2.fc29.src.rpm
dcmtk-3.6.2-4.fc29.src.rpm
gtatool-2.2.0-11.fc28.src.rpm
gtatool-2.2.3-1.fc30.src.rpm
orthanc-1.5.4-1.fc30.src.rpm


They all build correctly in F31 with the new version, so I do not expect
any build failures. Could I please solicit the help of a proven-packager
to rebuild them all in F29/F30 and push combined updates please?

If you maintain any of these packages and have any concerns, please let
us know.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1732222
[2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=14644638
[3] https://koji.fedoraproject.org/koji/rpminfo?rpmID=18968192

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Mamoru TASAKA]

Ankur Sinha wrote on 2019/09/13 23:07:
>  Hello,
>  
>  A CVE[1] in dcmtk was fixed in 3.6.4 which is in F31+. F29 and F30 are
>  still at 3.6.2 however, and need updating. This includes a soname bump
>  ([2] vs [3]), though, so dependent packages will also need to be rebuilt
>  and pushed as updates all at once.
>  
>  sudo dnf repoquery --source --whatrequires 'libdcm*(64bit)'
>  [sudo] password for asinha:
>  Last metadata expiration check: 0:53:07 ago on Fri 13 Sep 2019 14:07:55 BST.
>  OpenImageIO-2.0.7-1.fc30.src.rpm
>  OpenImageIO-2.0.9-1.fc30.src.rpm
>  aeskulap-0.2.2-0.37.beta2.fc30.src.rpm
>  ctk-0.1-0.10.20171224git71799c2.fc29.src.rpm
>  dcmtk-3.6.2-4.fc29.src.rpm
>  gtatool-2.2.0-11.fc28.src.rpm
>  gtatool-2.2.3-1.fc30.src.rpm
>  orthanc-1.5.4-1.fc30.src.rpm
>  
>  
>  They all build correctly in F31 with the new version, so I do not expect
>  any build failures. Could I please solicit the help of a proven-packager
>  to rebuild them all in F29/F30 and push combined updates please?
>  
>  If you maintain any of these packages and have any concerns, please let
>  us know.
>  
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1732222
>  [2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=14644638
>  [3] https://koji.fedoraproject.org/koji/rpminfo?rpmID=18968192 
Well, actually some google search result is that the actual fix seems
https://github.com/commontk/DCMTK/commit/40917614e
and the tracker is
https://support.dcmtk.org/redmine/issues/858

ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228

So it seems if the above patch only can be applied, no rebuild is
needed.

Regards,
Mamoru

[Ankur Sinha]

On Fri, Sep 13, 2019 23:20:50 +0900, Mamoru TASAKA wrote:
>  Ankur Sinha wrote on 2019/09/13 23:07:
>  Well, actually some google search result is that the actual fix seems
>  https://github.com/commontk/DCMTK/commit/40917614e
>  and the tracker is
>  https://support.dcmtk.org/redmine/issues/858
>  
>  ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228
>  
>  So it seems if the above patch only can be applied, no rebuild is
>  needed. 
Sure, I could do that---would that be the suggested thing to do?

Given that we have evidence that the dependent tools build properly,
this is a low risk update. So, I was hoping to update to the current
version to also give users the advantage of other fixes/enhancements
than carry a patch for the one fix---especially for F30 which still has
quite a life to live.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Mamoru TASAKA]

Ankur Sinha wrote on 2019/09/14 2:58:
>  On Fri, Sep 13, 2019 23:20:50 +0900, Mamoru TASAKA wrote:
> > Ankur Sinha wrote on 2019/09/13 23:07:
> > Well, actually some google search result is that the actual fix seems
> > https://github.com/commontk/DCMTK/commit/40917614e
> > and the tracker is
> > https://support.dcmtk.org/redmine/issues/858
> >
> > ref: https://nvd.nist.gov/vuln/detail/CVE-2019-1010228
> >
> > So it seems if the above patch only can be applied, no rebuild is
> > needed.
>  
>  Sure, I could do that---would that be the suggested thing to do?
>  
>  Given that we have evidence that the dependent tools build properly,
>  this is a low risk update. So, I was hoping to update to the current
>  version to also give users the advantage of other fixes/enhancements
>  than carry a patch for the one fix---especially for F30 which still has
>  quite a life to live. 

As written on https://fedoraproject.org/wiki/Updates_Policy#Philosophy
updates should aim to fix bugs and not to introduce features. And changing
ABI is discouraged unless avoided.

Regards,
Mamoru

[Kevin Kofler]

Mamoru TASAKA wrote:
>  As written on
> https://fedoraproject.org/wiki/Updates_Policy#Philosophy
>  updates should aim to fix bugs and not to introduce features. And changing
>  ABI is discouraged unless avoided. 
Here, we have a library with only 6 packages using it, and the source-level 
API appears to be compatible, so I think a grouped update of all 7 packages 
(the library + the 6 dependent packages) may well make sense, depending on 
what the other changes are.

But yes, backporting security fixes should always be considered, it would 
also get the fix out sooner than coordinating a grouped update.

I do not know the details well enough to be able to decide which is the 
better way here. Both should be doable in principle.

        Kevin Kofler

[Richard Shaw]

On Sat, Sep 14, 2019 at 4:50 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  I do not know the details well enough to be able to decide which is the
>  better way here. Both should be doable in principle.
>  
As the maintainer of OpenImageIO I agree with Kevin, I'm OK with either,
but one thing I would ask upstream is why they bumped soname on a patch
level version increase...

With my packages I would typically update all released Fedora versions for
patch level updates, but I also frequently build the package myself and run
abi-compliance-checker or fedabipkgdiff on it to make sure things like
soname bumps don't sneak in...

Thanks,
Richard

[Ankur Sinha]

On Sat, Sep 14, 2019 07:28:37 -0500, Richard Shaw wrote:
>  On Sat, Sep 14, 2019 at 4:50 AM Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  
>  
>      I do not know the details well enough to be able to decide which is the
>      better way here. Both should be doable in principle.
>  
>  
>  As the maintainer of OpenImageIO I agree with Kevin, I'm OK with either, but
>  one thing I would ask upstream is why they bumped soname on a patch level
>  version increase... 
Yes---confused me too. I'll ask them this when I e-mail them next.

>  With my packages I would typically update all released Fedora
> versions for
>  patch level updates, but I also frequently build the package myself and run
>  abi-compliance-checker or fedabipkgdiff on it to make sure things like soname
>  bumps don't sneak in... 
The changes from 3.6.2 to 3.6.4 do mention a few API changes, not too
clearly though, in their release announcements/changelogs:
https://github.com/DCMTK/dcmtk/tree/master/docs

There is no mention of ABI changes there.

I did run abipkgdiff, and this is what it gave me:
https://ankursinha.fedorapeople.org/misc/dcmtk-3.6.2-3.6.4-abipkgdiff.txt

It doesn't pick up any changes in the shared objects (can it, if the
version has been changed?). I'm not experienced enough with these
reports. Does that look OK?

For the time being I'm going to backport the patch and push an update as
Mamoru suggested, simply because it's less work and quicker.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London