Sun 21 May 2017 09:30:19 AM UTC, comment #10:
The fix has been released in 2.8.4. Thanks again for reporting.
|
Fri 19 May 2017 03:31:54 PM UTC, comment #9:
A hash is easier for checking integrity, yes. But... can you change a byte of a gzipped tarball and still decompress to something valid? And of an xz compressed tarball? And how about lzipped? Won't these decompressors flag an error in most cases?
Anyway, integrity of the tarball doesn't tell you much -- if someone breaks into the server and replaces the tarball, they can also replace the hash. But the signature they cannot replace (at least, that's the theory). So the signature is much stronger: when it verifies okay, it not only tells you that the data is intact, but also that the tarball comes from me (or at least: from the same person that also made the last ten or so tarballs).
So, if people are worried about integrity, I'd rather push them to using gpg to verify the signature. And for a build tool, easiness or quickness should not be an argument: the highest possible amount of confidence should have priority there.
|
Fri 19 May 2017 10:16:26 AM UTC, comment #8:
Thanks for pushing the fix.
Regarding the sha256, is not that is better or worse. Is just easier for checking the tarball integrity.
Is not the same just running "sha256sum nano-2.8.4.tar.gz" and compare the output to a published sha256 hash, than having to download and import a public key, download the signature, and then check the tarball integrity using the signature.
For normal users who download the tarball manually and want to check its integrity, is slightly easier the first method. But for automatic tools or package managers, is much easier just having the public hashes in a plain text file and simply compare them after downloading the tarball. You don't need the automatic tool or package manager to download any key, import it, then download a signature file, do the checks, and then clean everything.
|
Fri 19 May 2017 10:09:49 AM UTC, comment #7:
Hm... How is a sha256 hash better than a gpg signature?
A fix for the wrong logic has been pushed: a32d21c7.
|
Fri 19 May 2017 09:35:19 AM UTC, comment #6:
<off topic>
While we are at it, could a sha256 hash be published when a new tarball is released? :P
</off topic>
|
Fri 19 May 2017 09:31:03 AM UTC, comment #5:
True, Buildroot (the environment where I'm building nano) passes --disable-nanorc to the configure script. Sorry for omitting that information.
Regarding the Reported-by tag, yes, why not:
Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Thanks.
|
Fri 19 May 2017 09:27:33 AM UTC, comment #4:
But I have GNU Make 4.2.1 too, and after unpacking the 2.8.3 tarball and running './configure && make && make install', there was nothing wrong... Ah, but you configured with --disable-nanorc...! That was essential information. :)
Fixed in git (not pushed yet). Do you wish to see your imgtec or your gentoo address in the Reported-by tag?
|
Fri 19 May 2017 08:02:53 AM UTC, comment #3:
Hello Benno,
yes, the doc/nanorc.5 file is missing :-)
My make is GNU make 4.2.1, from Gentoo. Nothing weird here ¯\_(ツ)_/¯
Regards,
Vincent
|
Thu 18 May 2017 05:38:27 PM UTC, comment #2:
Ouch! Forget my questions. The doc/nanorc.5 file is not in the tarball... During the conversion from DISABLE to ENABLE I have overlooked something, apparently. There will be a 2.8.4 soon.
You have a strange make, though. It shouldn't /need/ to make nanorc.5.html, because it already exists. Hmm... or maybe your make considers an absent file to infinitely new whereas GNU make considers it be infinitely old? Seen that way, I think your make is better.
|
Thu 18 May 2017 05:25:02 PM UTC, comment #1:
Thanks for reporting. Please attach the produced doc/Makefile (without any extension). What configure options did you use? Was this during 'make' or during 'make install'?
|
Thu 18 May 2017 04:08:24 PM UTC, original submission:
[...]
Making all in doc
make[3]: Entering directory '/br/output/build/nano-2.8.3/doc'
make[3]: *** No rule to make target 'nanorc.5', needed by 'nanorc.5.html'. Stop.
|