[04:36] <yurtesen> How does one contact a MOTU who is willing to sponsor a security related debdiff? I have been trying now over a week, and still feeling in the dark.
[04:43] <amurray> hey yurtesen - can you please subscribe ~ubuntu-security-sponsors  to the relevant LP bug? 
[04:44] <amurray> and out of interest - can you point me at the bug in question?
[04:44] <sbeattie> amurray: it's LP: #1915911 and sponsors is already subscribed
[04:44] <ubottu> Launchpad bug 1915911 in tomcat9 (Ubuntu) "Tomcat9 package is old version with many security issues" [Undecided, Confirmed] https://launchpad.net/bugs/1915911
[04:46] <amurray> ah cool - so pfsmorigo any chance you could take a peek at this as you are on community this week? otherwise maybe leosilva could take a look as he is on the community role next week so could get a head start on reviewing it to sponsor it
[05:12] <yurtesen> Hello, and thank you for checking this out. Can the person who is checking this out put a message to bug report, if possible, with some time estimate? I am sorry, but I have been under some pressure. I keep hearing we should stop using Ubuntu because universe packages are not maintained at all and people were skeptical that Ubuntu would even allow outside help. I do not intend to 
[05:12] <yurtesen> sound negative, it is what it is. I understand people are busy. But I would also like to make some other bugfixes (not security related) to make to `tomcat` package on 20.04 and 21.10 and 22.04. To summarize, I need something, a pointer which shows progress and all the time spent is not lost. (and this is not for me personally, it is because our company is using this package and they 
[05:12] <yurtesen> can't let work hours to go waste if nothing is happening)
=== mirespace_ is now known as mirespace
[13:07] <sdeziel> yurtesen: the debdiff looks good to me, thanks for working on it! That said, I'm not a security team member so I can only encourage you to keep doing :)
[14:25] <tomreyn> https://www.openwall.com/lists/oss-security/2022/03/24/1
[14:26] <tomreyn> zlib-1.2.11 https://nvd.nist.gov/vuln/detail/CVE-2018-25032
[14:26] <ubottu> zlib 1.2.11 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25032>
[15:13] <mdeslaur> tomreyn: yep, working on it
[15:13] <mdeslaur> tomreyn: thanks
[15:19] <tomreyn> i assumed it would go into the next round, just wanted to push it a little bit :)
=== Nokaji_ is now known as Nokaji
[22:13] <JanC> how does a library like zlib still have bugs like that...
[22:24] <jjohansen1> you mean how does anything ever work ;)
[22:35] <sarnold> hah yeah :)
[22:42] <JanC> no, seriously, this sounds like a bug that could be found with a formal analysis
[22:44] <JanC> I understand you can't do that on everything, but this is probably the most-used library in IT history
[22:45] <sarnold> I only vaguely skimmed it, but I think it was stuffed behind a rarely-used #ifdef or similar
[22:48] <JanC> if it's rarely used, then how is it a problem?  :)
[22:49] <sarnold> that's why I only vaguely skimmed it :)
[22:52] <mdeslaur> yeah, it's pretty incredible
[22:53] <mdeslaur> I particularly like the "It has lain in wait 13 years before being found!" comment in the commit, and now we're three years later without a new release that includes it
[22:54] <mdeslaur> I guess their waiting another 10 years so they can add the matching "13 years before being released!" comment
[22:54] <mdeslaur> *they're
[22:55] <mdeslaur> (then we can go to "13 years before mitre updated the CVE!")
[23:01] <sarnold> I can't remember now if it was zlib or gzip, but I remember tripping over a fuzzer bug when doing a security update half-dozen years ago
[23:02] <sarnold> it was one of those packages where finding a flaw seems *so* unusual and unlikely that you suspect the build environment first
[23:05] <tomreyn> Apr 20, 2018 to Mar 26, 2022 is more like 4 years, if this matters.
[23:06] <tomreyn> * Mar 23, 2022