On 23/03/17 08:52, Samuli Seppänen wrote: > Hi, > > On 23/03/2017 05:11, Antonio Quartulli wrote: >> On Wed, Mar 22, 2017 at 02:11:56PM +0100, David Sommerseth wrote: [...snip...] >>> Currently we do not have anything providing a guaranteed match between >>> openvpn-install-2.x.y-I60z and a particular git commit. This helps >>> understanding what a release really contains, especially if you have >>> more commits in a release. Then you just do: >>> >>> $ git shortlog v2.4.0-I601..v2.4.0-I602 >> >> I like this too - makes it really easy to revise what was changed between two >> releases/tarballs. It's basically one little step more to perform when >> creating >> the tarball. > > The git shortlog command will show us how openvpn-build's parameters in > "generic/build.vars" and "windows-nsis/build-complete.vars" have > changed. That is generally enough to know what openvpn-build has > downloaded and from where. > > One shortcoming is the tarball version numbering scheme in openvpn-gui: > > openvpn-gui-11.tar.gz
It's become fairly popular these days to skip the minor/patch level numbers and just have a single revision number (firefox, chrome, systemd are those instantly coming to my mind, but there are many more). Perhaps the OpenVPN GUI can see a benefit of that too? > So just the major number, not the full version number (e.g. 11.5.0.0). > It would be good to have the full version in the tarball name, so that > all the components combined by openvpn-build would be identifiable > exactly from git diff. Another concrete benefit would be that old minor > version tarballs would remain available on the download servers; right > now they get overwritten on every openvpn-gui release. All good points! >>> Another aspect is when you do signed commits (git tag -s), then the tag >>> is "cryptographically bound" to a particular git commit. That is >>> incredibly hard to manipulate. If the branch itself is modified the >>> committish will change, thus there will be a mismatch between the branch >>> committis and the commit the tag points at. In fact, if you do a git >>> checkout using the tag name, you will most likely get the correct commit >>> checked out and not the manipulated one. >>> >> >> +1 on signing the tags - this increases the confidence in the code somebody >> is >> downloading. Manipulations are found immediately (unless done voluntarily by >> the committer). > > With the current build setup I can easily do signed tags for openvpn-gui. > > Openvpn-build would require some additional work, as the build computer > is a shared EC2 VM which other OpenVPN Tech people can access. I don't > want to have my private GPG key lying around on such a VM. That said, > nobody else is using the EC2 VM, so I can fairly easily switch to using > something in my own intranet. There is nothing that mandates using a personal signing key if you have some kind of automation behind it - as long as the signing key is is signed by physical persons we trust. So the shared VM could have its own private key used for this and other package signing tasks. If you're tempted going for full automation and still keep things fairly more secure, have a look at the Tang project [1]. There is a video [2] of a talk from devconf.cz the conference in January which describes the challenge and how Tang fills the gap [1] <https://github.com/latchset/tang> [2] "Securing automated decryption" <https://www.youtube.com/watch?v=CM_IOaBUJo0> -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
