I'm not part of the FreeBSD Security Team any more (I stepped down as Security Officer a few years ago because I was no longer able to find time to do both that

I'm not part of the FreeBSD Security Team any more (I stepped down as Security Officer a few years ago because I was no longer able to find time to do both that and Tarsnap, and last year I left the security team entirely when the team was pruned of its not-recently-active members), but some comments based on my experience: 1. If there's an exploit circulating "in the wild" then yes, obviously, an issue should be publicly disclosed. (I did this with an rtld bug in December 2009, circulating a "quick patch" about 48 hours before we had the advisory and binary updates available.) The only exploit I've seen circulating recently was for the issue fixed in FreeBSD-SA-16:25.bspatch. 2. The boilerplate updating instructions in FreeBSD-SA-16:25.bspatch should have been amended to remove the use of bspatch. Unfortunately I didn't see the advisory text until it went out. (For reference: Adding ": > /usr/bin/bspatch" before running freebsd-update would solve this; freebsd-update would fall back to downloading complete files rather than using patches, and one of those files would be the corrected bspatch binary.) 3. I'm sure it was never the intention to leave vulnerabilities unfixed. But we've also learned to be cautious about adopting patches which are "thrown over the wall" at us; one source in particular had roughly equal odds of "doesn't fix the vulnerability", "fixes the vulnerability", "fixes the vulnerability but breaks functionality", and "introduces a new vulnerability which is worse than the one being fixed". So the approach was normally (and I assume still is) to look through a patch and ask "what does this change fix?" and take the changes which we can identify a purpose for.