Hi Enrico, On Mon, Jun 6, 2022 at 3:24 PM Enrico Zini <enr...@enricozini.org> wrote: > last month as part of Freexian onboarding I tried to work on pdns: > https://security-tracker.debian.org/tracker/source-package/pdns > > I backported patches for CVE-2020-17482 and CVE-2019-10203 > to https://salsa.debian.org/enrico/pdns/-/tree/stretch > > For CVE-2022-27227, available patches touch code that mostly didn't > exist in 4.0.3, and zeha commented on IRC: > > > do you have actual users on 4.0.x which are -actually- affected by the > > IXFR things? i think if one uses 4.0.x to run a domain on the public > > internet, you'll have other problems > > It looks like a case for tagging as no-dsa: would you agree?
I wonder if the stretch version is even vulnerable in the first place? It looks like it's not? Or am I missing something? I mean, I just took a quick glance at the source (w/o patches applied) and the relevant code is not there. But I understand that it's not enough to say that it's not vulnerable. Perhaps having a reproducer might help to be certain here? > That leaves CVE-2020-17482 and CVE-2019-10203 pending. pdns has no test > suite, and I'm unable to smoke test it manually, so it feels > irresponsible for me to make a DLA without testing. > > I left a note of this in dla-needed.txt: is that enough, or would you > like me to do something else not to leave this work unfinished? If you're _fairly_ confident that nothing's going to break and that the patches were straightforward, I'd say go ahead. Otherwise, POCs are the best way to ensure what you backported is correct and that it works, indeed. Getting hold of a POC is some work (if it's not mentioned in the initial advisory) - ask the sec team, ask the upstream sec team, coordinate with them, et al, et al. Or ask Christian how he smokes test them or if we can help. Let me know if any of what I said works, if it doesn't, we'll take another look at this again. Hope that helps? - u
