> On 10/04/14 14:42, Samuli Seppänen wrote:
>
> >> On 10/04/14 13:06, Joe Patterson wrote:
> >>> Not so much a "confidentiality" benefit as an "integrity"
> >>> benefit, to make sure you really are getting your software from
> >>> who you think you're getting it from.
> >>
> >> The only way to truly get that confirmation is by using the
> >> signature files, or other signature mechanism (preferably via
> >> another channel)
> >>
> >> Samuli: Maybe our release announcements should be PGP signed,
> >> with sha256sums of the files we're releasing? And maybe we
> >> should consider a possibility to host at least a copy of the PGP
> >> signatures of our files on an external server too? (That should
> >> *not* be a mirrored setup, but somehow distributed outside of a
> >> public HTTP{,S})
> >>
> >> <paranoid mode="off"/>
> >>
>
> > What if we'd put the sha256sums to Git? That would be distributed,
> > so any meddling could be detected easily.
>
> Not sure I follow this one. How would that work out? To which git
> tree should this information be committed? Or did you mean to have a
> separate git tree with PGP/GPG signatures published for each of the
> released files? That could actually work, and wouldn't require us to
> setup another server anywhere.
Maybe just a text file in Git "master"? Once the Git tree has been
cloned by a number of people, we could easily detect tampering of the
master Git repo (at SF.net/GitHub).
That said, signing the release announcement emails works as well.
Samuli
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
