"Morgan, Iain (ARC-TN)[InuTeq, LLC]" <iain.morgan%nasa.gov@localhost> writes: > I have to admit that I agree with the general sentiments stated > below. I understnad that a package like Openssl affects a large number > of other packages, and thus warrants a reasonable amount of testing to > avoid adverse impact. That is, impact beyond that due to the > vlunerability itself. I also understand that as we approach the end of > a given releases lifecycle, attention is focused on preparing and > testing the upcoming release. NetBSD proper has hired a release engineer. With funding, TNF could probably hire someone to do this sort of work for pkgsrc. So I would suggest that everyone who cares look at their organizations budget for proprietary licenses and figure out the value they get from pkgsrc and donate. I have no authority to promise any outcomes, but if everybody did it it seems likely things would be better. I arranged a donation once to Free Software, and I can tell you it was harder than paying for Windows licenses. > With regards to this specific issue, the bmake replace after > backporting the OpenSSL update went smoothely for me. As I noted > earlier, I've tested several commands that link against the OpenSSL > libraries and found no issues. As a further test, I removed the > OpenSSL 1.1k build and all of the packages that depended on it from a > separate 2021Q2 install and then rebuilt OpenSSL and all of the > previously removed packages. Again, there was not issue. Great. This makes the implicit point that people seriously using pkgsrc and doing their own builds can use the updated openssl just by choosing it. They aren't gated on pkgsrc applying a pullup. > I've also done a similar test as above, but with the addition of doing > "bmake test" as well. Unfortunately, the results from that seem > inconclusive. I don't generally run "bmake test" so I'm not sure what > are expected failures. It runs the upstream tests, generally, and hard to say.q > Thus far, none of the failures appear to be related to OpenSSL. Most > appear to be due to not finding the soruce tarball -- even though the > tarball should already be present in the distfiles directory. Some > Python 3.9 modules also fail to "project_url" not being supported by > setuptools. > > I'd like to thank those who have contributed to this thread and > offered suggestions. I've certainly got some things to think about > before my next production pkgsrc build. And, thank you for being constructive and willing to adjust in the face of a difficult situation.
Attachment:
signature.asc
Description: PGP signature