On Wed, 5 Sep 2012 23:12:37 +0800 Rowdy OpenBSD wrote: > > To the OP. When checking I choose a source mirror or two and download > > just the SHA256. There is no sha256 for src.tgz and sys.tgz but you can > > use ssh for the source code by getting the fingerprint once like for > > signatures but tied to servers and not devs. > > Thanks for trying to help, Kevin, but there are significant weaknesses > in your process. > > How do you upgrade packages?
It really irks me when people use my name when there is no need but I'll assume you just wanted to make clear you were responding to my quote (above) and also assume you are not a troll this once. 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. 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. > I have PKG_PATH set for root and use > "pkg_add -ui". I wouldn't use root myself, like linux does. > The packages that OpenBSD provides are not signed, so > if the mirror from which I get my packages is compromised, so is my > computer. If the packages that OpenBSD provides were signed by the > OpenBSD project, then I could at least be reasonably confident that > the packages were not compromised between their signing and my > obtaining them. > Assuming the keys are on secure machines, yes. > 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. > 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? > 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. > If the distribution sets and packages that OpenBSD provides were > signed by the OpenBSD project, then we could at least be reasonably > confident that the packages and distribution sets were not compromised > between their signing and our obtaining them. > No, it would save us a couple of checks and allow us to be more confident going forward. > It's true that signatures may create a "false sense of security" > whereby people think they are safer than they actually are because > they misunderstand which threats signatures do and do not protect > against. However, this is true of any security measure, and is not a > reason to avoid it. For example, W^X may create a false sense of > security whereby people think that unsafe programming practices are > not a problem, but that's not a reason to avoid W^X. > > 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! 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. The false sense of security is far smaller because of the more secure infrastructure and ports design. Checksums can be checked individually with sources whereas signing has no relation to the content unless you sign the checksum file.