Thread: [brlcad-devel] Checksums for released packages
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: Tom B. <tom...@gm...> - 2011-01-27 17:03:56
|
Are there any checksums published for the stable release packages? If not, it should be easy to generate one easily with something like "shasum -p -a 256 release_archive > release_archive.sha256sum" and then make it a released file also. Best, -Tom Thomas M. Browder, Jr. Niceville, Florida USA |
From: Christopher S. M. <br...@ma...> - 2011-01-27 18:37:46
|
On Jan 27, 2011, at 12:03 PM, Tom Browder wrote: > Are there any checksums published for the stable release packages? > > If not, it should be easy to generate one easily with something like > "shasum -p -a 256 release_archive > release_archive.sha256sum" and > then make it a released file also. Hey Tom, You're welcome to generate and post checksums, if you're so inclined. I must admit, though, that I haven't seen a compelling need for BRL-CAD. What benefits do you think it will provide? At least ever since we went unencrypted and open source, there's minimal incentive until/unless there are forked distributions. I think at best it'll just tell you whether the download was clean and complete, which tar will also report already if it wasn't. Some of the binary distributions have built-in integrity checks too (e.g., Mac disk images). Security-wise, if someone tried to hijack a distribution, then they could just update the checksum too. That said, don't let me stop you! :) Cheers! Sean |
From: Tom B. <tom...@gm...> - 2011-01-27 19:13:55
|
On Thu, Jan 27, 2011 at 12:36, Christopher Sean Morrison <br...@ma...> wrote: > On Jan 27, 2011, at 12:03 PM, Tom Browder wrote: > >> Are there any checksums published for the stable release packages? ... > You're welcome to generate and post checksums, if you're so inclined. > > I must admit, though, that I haven't seen a compelling need for BRL-CAD. What benefits do you think it will provide? As usual, many of my use cases come from work. I'm putting a BRL-CAD release archive in an open source bundle, openly available through Dropbox, and I would like my users to be able to independently verify the contents of the package that comes from other sources. So wouldn't a checksum on Sourceforge be a step in that direction? It would be the definitive checksum, wouldn't it. > That said, don't let me stop you! :) I will, but only if you think my argument is valid. Cheers, -Tom |
From: Christopher S. M. <br...@ma...> - 2011-01-28 14:34:42
|
On Jan 27, 2011, at 2:13 PM, Tom Browder wrote: > As usual, many of my use cases come from work. I'm putting a BRL-CAD > release archive in an open source bundle, openly available through > Dropbox, and I would like my users to be able to independently verify > the contents of the package that comes from other sources. > > So wouldn't a checksum on Sourceforge be a step in that direction? It > would be the definitive checksum, wouldn't it. It certainly would. That's basically what I was referring to when I said "until/unless there are forked distributions." By 'forked' I really meant 'other' distributions, which a release bundle on Dropbox would qualify. >> That said, don't let me stop you! :) > > I will, but only if you think my argument is valid. Sounds reasonable enough to me. The various sh/make_*.sh scritpts that are used could even have a shasum line added to make generation of the checksum file automatic too. (Though a couple of them need updating.) Cheers! Sean |
From: Tom B. <tom...@gm...> - 2011-01-30 12:59:48
|
On Fri, Jan 28, 2011 at 08:34, Christopher Sean Morrison <br...@ma...> wrote: > On Jan 27, 2011, at 2:13 PM, Tom Browder wrote: >> So wouldn't a checksum on Sourceforge be a step in that direction? It >> would be the definitive checksum, wouldn't it. > > It certainly would. That's basically what I was referring to when I said "until/unless there are forked distributions." By 'forked' I really meant 'other' distributions, which a release bundle on Dropbox would qualify. > Sounds reasonable enough to me. The various sh/make_*.sh scritpts that are used could even have a shasum line added to make generation of the checksum file automatic too. (Though a couple of them need updating.) I'm working on this now. A couple of questions: 1. Should there be a per-file checck sum file, or can we combine into one (a little more awkward to automate I think but my choice)? 2. What is the preferred name for such file(s)? Apache has names ending in the algorithm (my choice) so we could have: brlcad-999.tgz.sha256 or, a combined list: all_files.sha256 3. I notice many GNU projects now use signed files rather than check sums. That is the best way to go for the paranoid, IMHO, then we could do both. GNU typically uses ".sig" for a binary sig file but I would use the ascii sig file so use ".sig.asc" or just ".asc". Cheers! -Tom |
From: Christopher S. M. <br...@ma...> - 2011-02-02 01:24:45
|
On Jan 30, 2011, at 7:59 AM, Tom Browder wrote: > I'm working on this now. A couple of questions: I presume these were all overcome by events given the tracker closing. I should have remembered that Sourceforge automatically calculates checksums. I knew that. Cheers! Sean |
From: Tom B. <tom...@gm...> - 2011-02-02 02:23:41
|
On Tue, Feb 1, 2011 at 19:24, Christopher Sean Morrison <br...@ma...> wrote: > > On Jan 30, 2011, at 7:59 AM, Tom Browder wrote: > >> I'm working on this now. A couple of questions: > > I presume these were all overcome by events given the tracker closing. I should have remembered that Sourceforge automatically calculates checksums. I knew that. Yes, I should have closed this thread. However, I do believe that the information is obscured and I have filed a ticket with SF regarding that. In the meantime, we might mention that in the release notes or some other place (INSTALL?). Cheers! -Tom Thomas M. Browder, Jr. Niceville, Florida USA |
From: Christopher S. M. <br...@ma...> - 2011-02-02 02:42:46
|
On Feb 1, 2011, at 9:23 PM, Tom Browder wrote: > In the meantime, we might mention that in the release notes or some > other place (INSTALL?). Yeah, the instruction details for a binary install would be a good place to mention checksum verification. Cheers! Sean |
From: Tom B. <tom...@gm...> - 2011-02-02 03:05:07
|
On Tue, Feb 1, 2011 at 20:42, Christopher Sean Morrison <br...@ma...> wrote: > > On Feb 1, 2011, at 9:23 PM, Tom Browder wrote: > >> In the meantime, we might mention that in the release notes or some >> other place (INSTALL?). > > Yeah, the instruction details for a binary install would be a good place to mention checksum verification. And also for the source packages. Here's a proposed new paragraph leading the QUICK INSTALLATION section: QUICK INSTALLATION ------------------ Note that the downloaded files have two check sums calculated automatically by the Source Forge file release system. The values are used to verify the integrity of the files as distributed. Get those data by clicking on the 'i' button at the end of each file's name. You should ensure those data are retained and passed with the files if you re-distribute them. Cheers! -Tom |