Re: signing release files
On 17 June 2014 07:37, Nick Holland wrote: > 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. > Nick once more hits the nail on the head. Driving it fully into the wood one can only hope. As, to the best of my recollection, the originator of the MD* variables I can say that they were intended - nay, forced upon us - to support differences between the needs of different architectures. Not to provide knobs to allow site customization. The ideal would be to completely eliminate them and the install.md files. Ken
Re: signing release files
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.
Re: signing release files
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. Technically, how does verification of siteXX.tgz work? IIUC it does not. I don't see what's the problem to provide one variable. Why are there MD* variables and override functions one could use but are not used by default (override/add into install.md)? j.
Re: signing release files
On 06/16/14 15:56, Jiri B wrote: On Sun, Jun 15, 2014 at 05:09:20PM -0400, Ted Unangst wrote: On Sun, Jun 15, 2014 at 14:12, Aaron Gomez wrote: I looked at the signify command but I can't figure out how to check all the files and then create the SHA256.sig. I tried "signify -S -s myprivatekey.sec -m SHA256 -x SHA256.sig" but that just created a file SHA256.sig with the following contents: untrusted comment: signature from signify secret key RWQ/YLxjYycyl9yO0Qz8OyKSG9NnreWqIqIvMrJ64hJ2XqsXcElZB8BW8h/tGfvR44cRyAlIk10pUntzg9R0Z1p5+e+1tHFzkAs= You need the -e flag to embed the message into the signature. I then ran sha256 against all of the files and copied the output to the SHA256.sig file, created a new install cd and tried again. This time it failed telling me that I used the incorrect key. The main problem is that the CD will attempt to verify against a key named openbsd-55-base.pub, which we ship. That's not going to match the private key you generated and are using. What do I need to do to make it so the installer can verify my newly created release files? The best approach, but it's more work, would be to change install.sh to look for a key like aaron-55-base.pub and add that to the ramdisk. The shortcut would be to replace the openbsd key, but that will only cause confusion later, so I'd try not to. That said, you probably don't need to sign releases you're building for yourself, unless they are travelling over untrusted links. We sign releases because they go from OpenBSD servers to you over the scary internet. If you control distribution, that's less scary. Wouldn't something like below make life easier? [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.
Re: signing release files
On Sun, Jun 15, 2014 at 05:09:20PM -0400, Ted Unangst wrote:
> On Sun, Jun 15, 2014 at 14:12, Aaron Gomez wrote:
> > I looked at the signify command but I can't figure out how to check all
> > the files and then create the SHA256.sig.
> >
> > I tried "signify -S -s myprivatekey.sec -m SHA256 -x SHA256.sig" but
> > that just created a file SHA256.sig with the following contents:
> >
> > untrusted comment: signature from signify secret key
> > RWQ/YLxjYycyl9yO0Qz8OyKSG9NnreWqIqIvMrJ64hJ2XqsXcElZB8BW8h/tGfvR44cRyAlIk10pUntzg9R0Z1p5+e+1tHFzkAs=
>
> You need the -e flag to embed the message into the signature.
>
> > I then ran sha256 against all of the files and copied the output to the
> > SHA256.sig file, created a new install cd and tried again. This time it
> > failed telling me that I used the incorrect key.
>
> The main problem is that the CD will attempt to verify against a key
> named openbsd-55-base.pub, which we ship. That's not going to match
> the private key you generated and are using.
>
> > What do I need to do to make it so the installer can verify my newly
> > created release files?
>
> The best approach, but it's more work, would be to change install.sh
> to look for a key like aaron-55-base.pub and add that to the ramdisk.
> The shortcut would be to replace the openbsd key, but that will only
> cause confusion later, so I'd try not to.
>
> That said, you probably don't need to sign releases you're building
> for yourself, unless they are travelling over untrusted links. We sign
> releases because they go from OpenBSD servers to you over the scary
> internet. If you control distribution, that's less scary.
Wouldn't something like below make life easier?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.775
diff -u -p -r1.775 install.sub
--- install.sub 9 Jun 2014 18:05:55 - 1.775
+++ install.sub 16 Jun 2014 19:55:49 -
@@ -86,6 +86,7 @@ shift $((OPTIND-1))
# MDCDDEVS- '/^cd[0-9][0-9]* /s/ .*//p'assumed if not provided
# MDMTDEVS- '/^[cms]t[0-9][0-9]* /s/ .*//p'
# MDXAPERTURE - set machdep.allowaperture=value in sysctl.conf
+# MDSIGNKEY - path to signify public key
# NCPU- the number of cpus for mp capable arches
. install.md
@@ -1158,6 +1159,7 @@ install_files() {
local _src=$1 _files=$2 _f _sets _get_sets _n _col=$COLUMNS \
_tmpfs _tmpsrc _cfile _fsrc _unver _t _issue _srclocal
+ export
SIGNKEY=${SIGNKEY:-${MDSIGNKEY:-/etc/signify/openbsd-${VERSION}-base.pub}}
# Initialize _sets to the list of sets found in _src, and initialize
# _get_sets to the intersection of _sets and DEFAULTSETS.
#
@@ -1244,7 +1246,7 @@ install_files() {
_issue="Cannot fetch SHA256.sig" && break
# Verify signature file with public keys
- ! signify -Vep /etc/signify/openbsd-${VERSION}-base.pub \
+ ! signify -Vep ${SIGNKEY} \
-x "$_cfile.sig" -m "$_cfile" &&
_issue="Signature check of SHA256.sig failed" && break
Re: signing release files
previously on this list Aaron Gomez contributed: > What do I need to do to make it so the installer can verify my newly > created release files? You can check the iso and type no or simply copy the SHA256.sig from the mirror into the same folder as the sets. If you choose http method it will work without doing anything as the SHA256.sig will be there on the mirror. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: signing release files
On Sun, Jun 15, 2014 at 14:12, Aaron Gomez wrote: > I looked at the signify command but I can't figure out how to check all > the files and then create the SHA256.sig. > > I tried "signify -S -s myprivatekey.sec -m SHA256 -x SHA256.sig" but > that just created a file SHA256.sig with the following contents: > > untrusted comment: signature from signify secret key > RWQ/YLxjYycyl9yO0Qz8OyKSG9NnreWqIqIvMrJ64hJ2XqsXcElZB8BW8h/tGfvR44cRyAlIk10pUntzg9R0Z1p5+e+1tHFzkAs= You need the -e flag to embed the message into the signature. > I then ran sha256 against all of the files and copied the output to the > SHA256.sig file, created a new install cd and tried again. This time it > failed telling me that I used the incorrect key. The main problem is that the CD will attempt to verify against a key named openbsd-55-base.pub, which we ship. That's not going to match the private key you generated and are using. > What do I need to do to make it so the installer can verify my newly > created release files? The best approach, but it's more work, would be to change install.sh to look for a key like aaron-55-base.pub and add that to the ramdisk. The shortcut would be to replace the openbsd key, but that will only cause confusion later, so I'd try not to. That said, you probably don't need to sign releases you're building for yourself, unless they are travelling over untrusted links. We sign releases because they go from OpenBSD servers to you over the scary internet. If you control distribution, that's less scary.
