[00:03] Unit193: any idea why it leaks? [00:04] Bug in wolfssl's compat layer? Or something? I tried the latest release and even git HEAD, still issues. [00:04] I'm not aware that "Deiban dooesn't seem to care about that any more" and I'm fairly sure that the position of at least one archive admin is that if Icecast upstream doesn't provide an OpenSSL linking exception then you can't link it. [00:06] I don't think I can give you a +1 without checking with the Ubuntu archive admins and the wider SRU team. [00:08] http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html Well, ideally re-link to openssl instead, but no TLS support would be better than leaky TLS (then they can just use upstream's OBS repo to get TLS support, because browsers are rejecting non-TLS connections nowdays..) [00:14] Thank you for the link! I didn't know about that. [00:15] So just SRU team consultation needed then. [00:15] Sure thing, they never got around to announcing it so it's a bit in limbo, but...I'd really like the feature here for that. :3 [00:15] Are you going to upload a new icecast2 to Debian that switches back to OpenSSL? [00:15] Yeah. [00:17] Unit193: I suggest you get an SRU bug ready [00:17] Then I can ask the SRU team about it [00:18] OK, I must confess I'm not very good at that. I presume I basically just file an issue for the package and it can be adapted. [00:21] Roughly yes. Use a bug title of "Memory leak when using SSL" or something [00:21] See what you can do with https://wiki.ubuntu.com/StableReleaseUpdates#Procedure [00:22] Try to explain why switching to OpenSSL is the most suitable way of fixing the issue [00:23] Don't worry about section headings too much if that bothers you. The important thing is that the required information is discernable from what you wrote, not how you write it. [00:23] HTH [00:38] Just pushed the fixed icecast2 to Debian.