> > I was wondering if packages for -release would be fixed if a security > > issue is found in one of these third party programs, which could be > > updated with pkg_add -u. > > It's a good question. I was quite amused to notice the juxtaposition of: > > ] Our aspiration is to be NUMBER ONE in the industry for security (if we > ] are not already there). > > ] The ports tree is meant for advanced users. Everyone is encouraged to > ] use the pre-compiled binary packages. > > ] When serious bugs or security flaws are discovered in third party > ] software, they are fixed in the -stable branch of the ports tree. Note > ] that binary packages for -release and -stable are not updated. > > I am guessing that your fear is correct but it's a matter of resource > availability given the effort it takes to keep the core system great. If > we want security updates for binary packages then I'd hope that people > agree it to be a good idea in the abstract but we probably need to > volunteer actual work (or donate more!) if it is to actually happen.
There is no juxtaposition. You are expecting a bunch of volunteers to do the massive job of upgrading last-month's software -- and do it better than Google with Android, or car manufacturers, or basically anything which contains software. You are labelling "security" as purely "dealing with yesterday's bugs" essentially for "customers" -- and we don't have customers. When we talk about security, we mean a development mindset for security-related innovation which get designed, proven, adopted, and reduce risk of software having bugs. Then slowly as a whole we try to drag everyone in the world forward - some of the things listed at http://www.openbsd.org/innovations.html are relevant to that. The juxtaposition I observe is someone I never heard of before in regards to investment & work in this community, arriving on a list to make a judgement. You even come to the conclusion that such work isn't going to happen for free, but leave the result dangling. Especially since OpenBSD isn't a PRODUCT. If product-servicing is a requirement, first of all choose something which is a PRODUCT, then choose a PRODUCT VENDOR who actually does SERVICING. It's doubly hard, without having to hold a non-product non-vendor responsible for a servicing requirement, which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE IS THE PONY. Perhaps the distictions are too subtle for you, and doesn't roll off the keyboard well enough as a snipe. It's ok, my cats cannot read and interpret such complexities either.
