Created attachment 245967 [details] Patch for optipng Unmaintained upstream, known security issues (#1) Redirect users to graphics/oxipng 1: https://sourceforge.net/p/optipng/bugs/87/
I've submitted a vuxml record: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274794 Not keen on the wording here - one person's "Abandonware" is another's "Completed Project", of which there are plenty of other examples in the ports system, not least most of the other PNG optimizers - pngcrush and pngrewrite are even older. And upstream is an active libpng developer, I'd rather hope they're not *dead*, even if they're not quite as responsive as we might like. It's also quite a tight deadline for such an ubiquitous tool - people will need to update website asset pipelines, and dependent ports graphics/curtail, deskutils/py-paperless, and x11-themes/xfce-icons-elementary will need updating. I also note www/onlyoffice-documentserver has its own copy of optipng for some reason. The given CVE is concerning but not particularly scary - requiring a specially-crafted GIF, allegedly requiring vanishingly unlikely arguments (I have my doubts there) and with no evidence the issue is actually exploitable. It could be argued it suggests people are still examining this code closely and not finding very much. graphics/oxipng is probably a better choice for most users, but Rust is an absolutely massive dependency for some people for one little tool, and the C alternatives in the tree are not necessarily better choices.
Thanks! Given https://sourceforge.net/p/optipng/bugs/ and https://sourceforge.net/p/optipng/patches/10/ it does seem like abandonware or that upstream is "dead" at least. Ideally we should consolidate if possible but that's another project for another day. We can extend it to 2023-12-31 however we already have a quite a bit of ports scheduled for removal which is why I wanted to offload portmgr a bit. Is that okay? Curtail appears to define dependencies incorrectly, at least by looking at upstream's release notes. https://github.com/Huluti/Curtail/releases/tag/1.7.0 Rust is only a build dep not a run dep and we offer both Rust as a prebuilt package which also can be utilized using Poudriere. I don't mind "old/feature complete" software as long as it runs as expected, do not have known security issues, dont encourage bad practices and we dont have to maintain for it to build. That being said, we now have both webp and heif/heic so its also time to move on eventually but that's another discussion. Best regards, Daniel
To not bury the lede, I have a fix for the CVE: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274822 > Given https://sourceforge.net/p/optipng/bugs/ and https://sourceforge.net/p/optipng/patches/10/ it does seem like abandonware or that upstream is "dead" at least. However the associated account remains active on a major dependency. They're not dead, they just haven't updated it in ages. I have similar projects I haven't touched in years, but they're (mostly) neither abandoned nor dead. Just "Upstream is inactive" is fine. Though if upstream does release a 0.7.8... > Ideally we should consolidate if possible but that's another project for another day. We can extend it to 2023-12-31 however we already have a quite a bit of ports scheduled for removal which is why I wanted to offload portmgr a bit. Is that okay? Could you clarify what you mean? Are there are lot of expired ports scheduled for the new year so you'd rather get this in beforehand? Would a longer expiry be acceptable? Gives people time to switch, and should still avoid such a busy period for portmgr? > Rust is only a build dep not a run dep and we offer both Rust as a prebuilt package which also can be utilized using Poudriere. I didn't realise this had landed in poudriere-devel. Sadly not in a stable release yet, but already turned out useful when I built security/afl++ and needed (another!) LLVM. > That being said, we now have both webp and heif/heic so its also time to move on eventually but that's another discussion. Not sure WebP's a great example given the very recent client side CVE with specially-crafted lossless files!
Yes, it would be preferable if we could get it in before 2024Q1 I'm taking about formats in terms of capatility and efficientcy, it's not like png have a rock solid history if that's what you're trying to imply. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libpng
PNG is a widespread file format and OptiPNG is a very useful tool to deal with it. Hard disagree with the removal. Port is maintained and the security issue has been fixed (cf bug #274822). I propose we close this issue and do not deprecate the port.
Thanks for everyone's input. I'm going to reject this for now. The reasons for the suggested deprecation seem to have been resolved - the CVE is patched, upstream has a new release with both the security fix and other improvements, and has also declared an intention to perform more substantial maintenance of the code in question to help head off further issues.