Hi Alexander, Sorry for the late reply.
On Sat, Dec 26, 2020 at 08:16:28PM +0300, Alexander Gerasiov wrote: > On Thu, 24 Dec 2020 06:31:31 +0100 > Salvatore Bonaccorso <car...@debian.org> wrote: > > > Hi Alexander, > > > > On Tue, Dec 22, 2020 at 07:57:15PM +0300, Alexander Gerasiov wrote: > > > On Sun, 20 Dec 2020 11:50:42 +0200 > > > Adrian Bunk <b...@debian.org> wrote: > > > > this is a regression in 1.2.1+dfsg-2 that is currently in both > > > > buster-security (which was done on top of 1.2.1+dfsg-2 that > > > > introduced the regression, not on top of 1.2.1+dfsg-1 in buster) > > > > and in unstable/testing (which currently misses the CVE fixes). > > > > > > > > It would be good if you could make an upload to unstable with this > > > > bug fixed on top of 1.2.1+dfsg-2+deb10u1, and then backport that > > > > change to buster. > > > > > > > > Please coordinate with the security team whether this would > > > > warrant a regression update to the DSA or should be done through > > > > the next point release. > > > > > > Hi, Team. > > > > > > Does anyone mind against uploading fix to stable-proposed-update? > > > The fix is here: > > > https://salsa.debian.org/debian/minidlna/-/commits/buster-security/ > > > Or should it go to buster-security? > > > > Fixing it via buster-proposed-updates in the next point release works. > > > > As regression from the last DSA, given we all have not spotted it was > > based on the testing version, I think we can as well release it via a > > regression update via buster-security. > > > > This will be only an issue if someone decides to purge the package in > > stable. > > > > The other issue: As the update was based on -2 rather than -1 it > > contains several more (packaging) changes as well and wonder if > > current stable users might have any issue with those (I suspect not > > because systemd service addition is probably ok, the move of > > logdiretory might be though suprising in a stable update and the fix > > for #941410 is probably just a benefit). > > > > Do you anticipate any problems which would arise from this that we did > > release it on top of the "wrong" version? > You get it absolutely right. The only notable changes in -2 are: > 1. systemd unit > 2. logdir location > > Others are packaging improvements and bugfixes we tested in testing for > months, so I don't expect any regression here. > > > So I have two open questions: > 1. which version to upload? (I could upload version equal to > 1.2.1+dfsg-1 + CVE fixes on top (rollback all accident changes). Or I > can only fix #975372 in current buster-security version as I did in > testing.). Uplaoding 1.2.1+dfsg-1 + CVE fix cannot work. We have already released 1.2.1+dfsg-2+deb10u1 in the security archives, so any version we pick to fix issues need to be highter, no matter if we do several rollbacks or only the #975372 fix. So we need in any case 1.2.1+dfsg-2+deb10u2 (no matter if "complete" rollback, or just the bugfix). Given the move of the logdir and systemd unit has now been done with the DSA, I think my preference would be to only just address the "fallout" from the logdir move and so adress #975372. Adam D. Barratt is Cc'ed in this message, who is a stable release managers in case he would like to indicate a preference. Adam would that be fine with you with your SRM hat on, to let all the -2 changes pass to stable (agreeing that that would usually not be stable material under normal cicumstances) and so just address the introduced #975372? > 2. where to upload? (buster-security of buster-proposed-updates) Personally I would have said fixing it in the upcoming point release is enough evne though the issue was introduced via a DSA. But the point release date is not settled yet, and Moritz indicated offlist as well that a regression update via a DSA is fine. So in short: let's try to adress this with a regression update via a DSA. > > Please help me with the decision =) Regards, Salvatore
