[Nut-upsdev] [nut-commits] svn commit r2832 - in trunk/docs: . website

[Arnaud Quette]

Hey Charles,

2011/2/25 Charles Lepple <clepple at gmail.com>

> On Fri, Feb 25, 2011 at 3:21 AM, Arnaud Quette <aquette.dev at gmail.com>
> wrote:
> >
> >
> > 2011/2/25 Charles Lepple <clepple at gmail.com>
> >>
> >> On Thu, Feb 24, 2011 at 10:36 AM, Arnaud Quette <aquette.dev at gmail.com>
> >> wrote:
> >> > Hi Charles,
> >> >
> >> > 2011/2/18 Charles Lepple <clepple at gmail.com>
> >> >>
> >> >> On Feb 17, 2011, at 8:41 AM, Arnaud Quette wrote:
> >> >>
> >> >> Hi John,
> >> >>
> >> >> 2011/1/17 John Bayly
> >> >>>
> >> >>> On 14/01/2011 20:40, Arnaud Quette wrote:
> >> >>>>
> >> >>>> Author: aquette
> >> >>>> Date: Fri Jan 14 20:40:06 2011
> >> >>>> New Revision: 2832
> >> >>>> URL: http://trac.networkupstools.org/projects/nut/changeset/2832
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> +link:
> http://www.networkupstools.org/source/2.6/nut-2.6.0.tar.gz.sig[signature]
> >> >>>
> >> >>> May I suggest that you also provide checksums for the tarball? I'm
> >> >>> updating the FreeBSD port, and wanted to verify the SHA256 sum. As
> >> >>> it's been
> >> >>> downloaded from the NUT website, I know the odds of the source being
> >> >>> tainted
> >> >>> are astronomical, but if it's for a distribution, I thought I'd be
> >> >>> extra
> >> >>> cautious.
> >> >>> As it is I've verified the GPG sig (never used it before) and used
> the
> >> >>> computed SHA sum.
> >> >>
> >> >> I've added a SHA256 hash, and referenced it in the download section:
> >> >> http://www.networkupstools.org/download.html
> >> >>
> >> >> I've not yet updated the documentation, but it's simple as
> downloading
> >> >> the
> >> >> nut archive and the matching .sha256 file. Then using:
> >> >> $ sha256sum -c nut-2.6.0.tar.gz.sha256
> >> >>
> >> >> Arnaud,
> >> >> I go through a similar set of steps for Fink packages. If there is a
> >> >> GPG
> >> >> signature, I'll verify that, since it provides a little more
> >> >> chain-of-trust
> >> >> information. However, if I am just downloading a single file, it is
> >> >> typically easier to just verify the hash by inspection - that is,
> with
> >> >> the
> >> >> SHA256 on the web page rather than a separate file download.
> >> >> Also, there is a bit more of an audit trail if the hash is in our web
> >> >> pages in SVN.
> >> >
> >> > I may be too far away, in other consideration...
> >> > but, are you saying that it would be better to embed the SHA256 hash
> >> > directly on the web page, or simply that searching for this file may
> be
> >> > too
> >> > hard for the user?
> >> >
> >> > for the former, the web page always need a modification for new
> >> > publication
> >> > (svn commit then push on www.n.o). So changing the stable release
> name,
> >> > and
> >> > at the same time adding the hash would not be a problem.
> >>
> >> I like this because there is a history of the hashes in SVN. The
> >> .sha256 file is not version controlled.
> >
> > nor the root file it's hashing...
> >
> >>
> >> > for the latter, the file is named <release-file>.sha256, so for
> example
> >> > nut-2.6.0.tar.gz.sha256, which allows checking automation.
> >>
> >> I guess I'm not sure I see the advantage of putting it in a separate
> file.
> >
> > I see no problem.
> > can you please do the mod?
> >
> > cheers,
> > Arnaud
>
> Committed as r2910.
>

thanks, I've just 'moved it to prod'.

note that I will however leave the .sha256 file available in the sources/
dir, and will distribute future files too.
Documentation will be using it (ie 'sha256sum -c nut-X.Y.Z.tar.gz.sh256')
since I personally find it more convenient, and automatable.

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110225/840ee581/attachment.htm>