Hi Salvatore! >> This bug was fixed in 19.3 upstream, and the sid/bookworm version is not >> vulnerable. > >Yes you are right, that was an error on my side, checking the source, >upstream commit and where the fix was included, thanks for correcting, >and apologies for the bad tracking at first. I double checked what >happened, and it was defintively that I got confused about the >inclusion from the upstream commit and not realizing it is in 19.3 >already.
No worries! I knew about this bug and patch because I am a Kodi team member and I did an assessment of that issue. I am still learning the art of interaction with Debian BTS though :) >I'm not yet sure the issue would warrant a security update per se, but >the question can be answered for both DSA and update via a point >release: 2:19.3+dfsg1-1 could not enter directly bullseye. If you do a >rebase to the 19.3 upstream then this would be either a "rebuild" >approach 2:19.3+dfsg1-1~deb11u1 (if no other changes to packaging to >be done) or if you import 19.3 on top of the current bullseye >packaging because there were other changes not suitable in meanwhile, >then 2:19.3+dfsg1-0+deb11u1 to have it sorting before 2:19.3+dfsg1-1. Right now 2:19.3+dfsg1-0+deb11u1 can be rebuilt from 2:19.3+dfsg1-1 with no changes (i.e only d/changelog entry). Because off #995823, I do keep component tarballs from bullseye release to keep debdiff as clean as possible. >If you are discussing this already with SRM then this is indeed the >way to go to see if they agree on your proposal to follow the 19.x >series for kodi for bullseye. I really hope Adam will resolve this issue soon. But even SRMs are uncomfortable with Kodi series in stable, I have already prepared 2:19.1+dfsg2-3 with a cherry-picked fix. I Cc'ed you in that bug, too. -- Vasyl Gello ================================================== Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: [email protected] Skype: vasek.gello ================================================== 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
