On 06/17/14 02:40, Jiri B wrote: > On Mon, Jun 16, 2014 at 05:47:03PM -0400, Nick Holland wrote: >> [diff to easily allow different keys] >> >> I think focus has been lost. >> >> What's the point of signing releases? To say "This came from the >> OpenBSD project". >> >> Why? To make sure your release is a pure, untampered with version. >> >> Signed releases is not a goal, the goal is an install that is >> trusted by the installer (you). Signed releases are a way to help >> reach that goal. Don't forget that. >> >> IF your release is from the OpenBSD project, the signing should work >> fine. If your release is from some other souce...I WANT an alert >> saying "This is not signed by OpenBSD"! I don't want to squish the >> alert. It isn't there to hit a checkbox "Code signed by someone". >> >> If your use is such that you DO want to certify that YOU created the >> files in question, that's great, ok, you have got a great >> "mini-fork" -- you can easily build your own release with your own >> keys and manage them appropriately, but a knob to get around the >> very point of release file signing is not really what I want to see. >> >> Nick. > > The problem is political. Does OpenBSD make life easier for people > who want to customize release build/installation by default or > these people should maintain their diffs separately.
OpenBSD is quite different from many open source projects, where they have a fear of offending any one person or group, and thus end up with three different packet filters, several different packing management systems, etc. Internally, one of the biggest insults in the project is to call a suggestion a "usless knob", and great pride is taken in deleting code and options that just shouldn't be there. I think this falls under that category. > Technically, how does verification of siteXX.tgz work? IIUC it does > not. It "works" exactly as intended: your siteXX.tgz file is something YOU generated, OpenBSD has no idea what's in it. If you can't trust your siteXX.tgz file and how it gets from you to you, you have much bigger problems that signing isn't going to fix. Again, you are confusing the goal with the tool used to help achieve the goal. "signing" is NOT the goal. I've had this discussion often. It often goes like this: "We want to implement two factor authentication" (followed by a description that is much more based on convenience than security) me: "Two factor authentication should not be the goal, it should be the means to the goal: security. You are subverting the security of TFA" "Oh, I know." (followed by a return to the subverted two-factor authentication system again) me: "You are undoing the benefits of two-factor authentication" "But two-factor is good!" (at which point, I think about driving a truck for a living) > I don't see what's the problem to provide one variable. much the same reason why we don't have a magic switch to disable stack smash protection or W^X protection. The point of the signing is simple and limited. Having worked with some systems which offer the kind of feature you request and speaking only for myself, I'm happy with this. > Why are > there MD* variables and override functions one could use but are not > used by default (override/add into install.md)? because they add features /the developers desire/ without disabling security? Nick.
