=== Hash is now known as Enchantertim
=== Enchantertim is now known as EnchanterTim
=== EnchanterTim is now known as OpenSores
=== OpenSores is now known as Hash
[13:46] <hallyn> hey ubu-friends - libcap-ng is a bit stale, and missing capng_get_rootid() which is useful for dealing with namespaced filecaps.  The debian maintainer is not responding to my emails.  I have a working candidate package at https://launchpad.net/~serge-hallyn/+archive/ubuntu/libcap-ng , if anyone cares to take a look and consider it for jammy at least...
[19:04] <sarnold> heya hallyn :) it might be worth following the "You know someone who seems MIA" bit of https://wiki.debian.org/Teams/MIA if the maintainer really appears to be gone :(
[19:19] <hallyn> sarnold: hey - the last person to do an NMU there is actually doing a (forget what it's called) and in 10 days may be picking the package up.  (heard that after i send the msg here this morning)
[19:19] <hallyn> So it's resolving itself, over time
[19:19] <hallyn> phew
[19:21] <sarnold> hallyn: ah nice, glad to hear something is already in progress
[20:18] <hank> The OVAL definition for CVE-2021-33912 has a bogus date
[20:18] <ubottu> libspf2 before 1.2.11 has a four-byte heap-based buffer overflow that might allow remote attackers to execute arbitrary code (via an unauthenticated e-mail message from anywhere on the Internet) with a crafted SPF DNS record, because of incorrect sprintf usage in SPF_record_expand_data in spf_expand.c. The vulnerable code may be part of the supply chain of a site's e-mail infra... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33912>
[20:23] <sarnold> heh they have dates?
[20:25] <sarnold> https://termbin.com/aykc
[20:26] <hank> yeah, they do have dates
[20:27] <hank> and "unknown" isn't a valid datetime format that I'm aware of
[20:27] <sarnold> looks like CVE-2021-33913 is the same thing
[20:27] <ubottu> libspf2 before 1.2.11 has a heap-based buffer overflow that might allow remote attackers to execute arbitrary code (via an unauthenticated e-mail message from anywhere on the Internet) with a crafted SPF DNS record, because of SPF_record_expand_data in spf_expand.c. The amount of overflowed data depends on the relationship between the length of an entire domain name and the len... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33913>
[20:28] <hank> yeah, looks like they're two flaws in the same revision of the software
[20:32] <hank> looks like it's assigned to a pfsmorigo 
[20:34] <jdstrand> hey, I'm curious about the support status of openjdk-8. openjdk-8 technically only received official support in 16.04, which is out of standard support. There have been no updates for ESM in the xenial ESM archive
[20:35] <jdstrand> historically, Ubuntu would copy forward openjdk-8 build to newer Ubuntu releases to universe. If an openjdk-8 update is published to ESM, will that pattern continue? (eg, push to bionic or focal universe)
[20:35] <jdstrand> s/update is published to ESM/update is published to xenial ESM/
[20:41] <sarnold> hank: alright, I've pushed something that I hope will fix up the oval; I'm not sure what the oval schedule is, it's probably a few hours away
[20:42] <sarnold> hank: thanks for letting us know, please holler if you spot anything else, or if it's not better in a bit :)
[20:43] <hank> right on, thanks a lot!
[20:43] <pfsmorigo> hank, hmm, I don't recall why it's assigned to me but I can take a look to see if its feasible
[20:44] <pfsmorigo> jdstrand, I'm honestly don't know how is the process for oepnjdk-8 in xenial but I'll follow-up with the team
[20:45] <jdstrand> pfsmorigo: hey, thanks! :)
[20:46] <pfsmorigo> hello jdstrand, how things are going? :)
[20:47] <jdstrand> pfsmorigo: things are going well. :) how about you?
[20:48] <pfsmorigo> jdstrand, cool, here is good as well