FreeBSD devs ponder changes to security processes

What's the problem?

Does the author have an issue with the way the FreeBSD is addressing this? Not commenting on security problems for which there is no patch is common procedure for all vendors.

This particular situation — where a proof of concept for the attack has been released but for which a suitable patch is not yet available — is certainly uncomfortable. But, let's see who and what is affected:

To be exposed, a user would need to be under an active Man-In-The-Middle attack when fetching patches.

In other words: a compromised update process is probably the least of the worries!

Rushing out an untested patch could, as Microsoft and others can testify, cause more problems than it solves: the proverbial swallowing a spider to catch the fly. Security has often as much to do with procedure as it does with code and the advisory provides detailed information for admins on how to mitigate the threat until a patch can be made available. This isn't perfect but is good practice.

Perhaps the most surprising thing is why signed packages aren't already a requirement of the process. But I'm not familiar with the details. The update toolchain is obviously a vulnerability for any system, as once it has been compromised the whole system is effectively compromised. But hardening the toolchain is easier said than done: you have the repositories, transport and code to worry about.