> There are significant weaknesses in any process, the majority of which > occur between the build infrastructure and source providers which > OpenBSD does a very nice job of.
I'm not sure why you think that's where the majority of problems occur, but in any case, my point is that using signatures would alleviate many (but not all) significant problems. > You don't need to install straight away and can check those packages > before you install and then install them on all your machines from a > local source. That's much less convenient, and also means that I have to manually account for dependencies (or run pkg_add repeatedly and see which dependencies are missing each time). If the OpenBSD project signed its packages, "pkg_add -ui" would work as it does now, and I could be reasonably confident that the packages were not compromised between being signed and me installing them. >> You say that you download SHA256 from a couple of mirrors to check it. >> Depending on which mirrors you use and from where they mirror, this >> does not necessarily provide independent verification. > > No, I said 'source mirror' (aka high tier) and I said 'download just the > SHA256' as these mirrors are meant only for syncing. This tedious, manual process is vulnerable to man-in-the-middle attacks. If the OpenBSD project signed its packages and disribution sets, you could, with almost no extra effort, be reasonably confident that they were not compromised between being signed and you downloading them. >> You say that you use SSH for the source code, which is great, except >> that you need to somehow verify the server's fingerprint the first >> time. > > So how do you verify anything the first time like an iso that comes > with keys? If you purchase OpenBSD CDs, you could get the public keys from those; otherwise, you could get them via HTTPS from https://www.openbsd.org/ and be reasonably confident that the keys were genuine. I understand that certification authorities are not perfect. My point is that this would make some attacks much more difficult. Also, long-time OpenBSD users would be able to see that the same signing keys were used for new releases/snapshots as were used for several previous releases/snapshots, meaning that they could reason that no NEW man-in-the-middle attack was taking place when they obtained the new release/snapshot. Again, I understand that this is not perfect. My point is that it would make some attacks much more difficult. >> The OpenBSD website doesn't use HTTPS, so again you're >> vulnerable to a man-in-the-middle attack. Moreover, OpenBSD does not >> support building ports on systems without X, so if you run OpenBSD on >> a server without X, then you can't build your own ports from source. > > You don't need to run X, just install the sets or even particularly > required files and you can close off any security risk with the machdep > sysctl, again which linux cannot do without patching the kernel. OpenBSD does not support building ports on systems without X, so if you run OpenBSD on a server without X, then you can't build your own ports from source. You could build them on another system that has X and then transfer them (is that what you were proposing?), but that requires a lot of extra effort. If the OpenBSD project provided signed packages, then we could, with no extra effort, be reasonably confident that the packages were not compromised between being signed and our downloading them. I'm not sure why you mentioned Linux. I want OpenBSD to be as good as possible, regardless of what Linux can or cannot do. >> It's true that the OpenBSD project would need to keep their keys >> secure and that building the distribution sets and packages would >> involve an extra step, but surely this is a trade-off that "the most >> secure operating system" would be happy to make. Practically every >> other operating system already does. > > And have had rogue code in their repos whereas OpenBSD nearly has! Again, I'm not claiming that signatures would magically solve every problem. I'm claiming that they would make many attacks significantly harder and that the extra security they provide makes them worthwhile. Also, other operating systems have sometimes detected compromises precisely because they used signatures. > As I suggested, they could keep one key secure to sign the SHA256 just > to save everyone checking on completely insecure slow phones etc. and > also reduce the attack window to the first time but you should consider > three things. > > If the key is compromised, how does anyone you know. If the compromise is detected, the OpenBSD project can announce it via its mailing lists and website, and generate a revocation message. If the compromise is not detected, then, by definition, we don't know. Signatures offer no protection against this. However, we should not make the mistake of thinking that a security measure is not worthwhile merely because it does not protect against every conceivable problem. > The false sense of security is far smaller because of the more secure > infrastructure and ports design. I am proposing additional security measures, not abandoning the existing infrastructure, so what I'm proposing would be more secure. Moreover, I've described several threats to which your current process is vulnerable. Perhaps you have a false sense of security already? If the OpenBSD project signed its packages and distribution sets, we could reasonably assume that they were not compromised between being signed and our downloading them. Your current processes do not provide the same degree of assurance, and they require more time and effort. > Checksums can be checked individually with sources whereas signing has > no relation to the content unless you sign the checksum file. ??? Obviously, the OpenBSD project would sign the checksum file (and packages).
