Hi László On Mon, Jul 17, 2023 at 06:36:37PM +0200, László Böszörményi (GCS) wrote: > Hi Salvatore, > > On Thu, Jul 13, 2023 at 8:42 PM Salvatore Bonaccorso <[email protected]> > wrote: > > On Wed, Jul 12, 2023 at 10:12:50PM +0200, László Böszörményi wrote: > > > In short, it seems: > > > - it's a non-dsa as only a crash in a CLI tool (which has end of life > > > now), > > > - doesn't affect the library, > > > - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable, > > > 4.5.1-1 fixed this issue. > > > > > > But you may find it otherwise, I do not alter this report in the BTS. > [...] > > For about having the issue fixed: The problem I have is that upstream > > has not yet closed the issue. Is it completely fixed and what is the > > fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is > > slight unhelpful on that front. > Reason is simple. Upstream was fixing issues and probably was doing > as they wanted. That is, there's another SIGSEGV issue [1] and it's in > tiffcrop as well. Upstream fixed it and was going on with other fixes. > Then maybe they couldn't reproduce the mentioned CVE issue and went on > releasing v4.5.1 with several other CVE fixes [2]. There Timothy > Lyanguzov commented that bug#529 probably will get a CVE id too, but > he couldn't reproduce it with that Git HEAD. > Answer is simple, the other SIGSEGV issue [1] fix solved this issue as > well. As upstream probably didn't recognize and couldn't reproduce > this SIGSEGV (anymore), it remained open. > > > Are you able to identify the fixing commit confirming it is done in > > 4.5.1-1? > Indeed, it is fixed for 4.5.1 and the fixing commit is > b5c7d4c4e03333ac16b5cfb11acaaeaa493334f8 [3].
Many thanks, this outline was quite helpful. I have updated the security-trcker metadata. Regards, Salvatore
