[washadjeffmad]

Isn't that still assuming that the information that pkg provides is generally trustworthy?

I assume their consideration is that the list might not be trustworthy, so knee jerk updating based on a potentially faulty list is itself a vulnerability. Would a 24h delayed updated list of security updates be worse than an incorrect one?

[msbarnett]

The fact that pkg isn't least-privileged in its operations sucks, but the idea that this somehow makes the contents of a cryptographically signed vulnerability list, fetched via SSL with chain-of-trust verification "untrustworthy" is nonsensical.

[MBCook]

Since it runs as scripts as root what happens when through malice, mistake, or odd configuration a script gets through standard review and trashes a system? What if one of the official maintainers doesn't exercise due diligence?

You're protected from MITM and hacked repos, but what if the problem is in the official repo?

Defensive programming is useful.

[msbarnett]

Yeah, but that's not the argument. I'm specifically responding to the parent's assertion that you wouldn't want to run audit because the list might just lie to you.

That's separate from the idea that the list might be maliciously crafted to exploit an overflow and gain root privileges (which presumably could bypass signing checks) -- if your threat model involves loss of control of FreeBSD's signing keys, pkg running as root is irrelevant. You can't ever trust anything outside the box, or update at all. No binary is trustable and even if you heavily audit the source you're in trusting-trust territory.

(also the only key that matters is the Security Officer's key for vuln disclosures -- not any random maintainer has signing authority)

[geofft]

No operating system, anywhere, has or can have protections against an official maintainer of their security update system screwing up and releasing a bad security update that has gone through all review and other checks.

The only possible defense is to turn off security updates entirely, and empirically, that is much higher risk. I can think of cases where signed and approved security updates have introduced regressions to valid use cases (e.g., LP #1058343 bit me badly at my previous job), not fixed a problem (e.g., the day after Shellshock came out), etc.... But I cannot think of a single case where a signed and approved security update, by an OS making even minimal attempts to have a decent process around updates (so, anyone better than Linux Mint), has been actively harmful.

Given that an operating system security update, by definition, is capable of changing the most privileged code on your system, there's no way to program it defensively. It needs to have the ability to make arbitrary changes your system (and thus the theoretical ability to trash your system) in order to be able to fix unforeseen bugs.