Use sha256sum instead of md5sum for verifying file integrity about makeself HOT 21 CLOSED

@megastep, to put a very fine point on this, which supported platforms do not have sha1sum in the $PATH?

from makeself.

@tuxmaster, agreed, but it's better than md5. @megastep, I'm not sure how to interpret your silence as of late. You're busy, I'm sure, but does my previous comment do anything to further the argument for a better digest command?

from makeself.

makeself already has options like —xz for compression which are incompatible with most legacy systems, so why not introduce options like —sha1 or —sha256 to let the user decide of the main checksum in the same way he can decide for compression while keeping the CRC as backup ?

from makeself.

@koutcher, seconded; that seems like a perfectly reasonable compromise. It makes sense to have the digest functionality follow the precedent set by the compression functionality; i.e., a (very) backward-compatible default overrideable via command line option.

from makeself.

I guess I'd be OK with a command line option, this seems like a fine compromise.

from makeself.

+1 I'll take SHA1 :-)

from makeself.

I take this under consideration, my main concern though is the availability of the sha256sum command across all supported platforms so that this would keep working. I'll have to check about that first.

If that is not the case then maybe we should keep the MD5 alongside the SHA, as a backup. By the way we still already use a CRC as a backup, so maybe it's time to switch it over. :)

from makeself.

i take sha1 anytime :)

from makeself.

@megastep Any progress on this?

from makeself.

If that is not the case then maybe we should keep the MD5 alongside the SHA, as a backup. By the way we still already use a CRC as a backup, so maybe it's time to switch it over. :)

It's not uncommon for e.g. package managers to provide multiple hashes, not only for redundancy (in case one hash fails, another hash won't) but also for compatibility. For example, gentoo's package manager (portage/ebuild) uses WHIRLPOOL, SHA512 and SHA256.

from makeself.

I'm not sure off the top of my head, but I would venture a guess that many of the standard UNIX installations (say early Solaris, HP-UX, etc) do not come with this command.

from makeself.

@megastep, the Solaris 10 digest command supports sha1, md5, sha256, sha385, and sha512. The HP-UX shasum supports sha1, sha224, sha256, sha384, and sha512.

References:

• https://docs.oracle.com/cd/E19253-01/816-5165/6mbb0m9dn/index.html
• http://www.polarhome.com/service/man/?qf=SHASUM&tf=2&of=HP-UX&sf=1

from makeself.

Don't use sha-1 for security reasons.
Only use one of the the sha-2 family(sha-256, sha-384 or sha-512)

from makeself.

I understand your concerns and pretty much agree with them. My main concern though is always that I need to maintain cross-platform compatibility as much as possible, which means relying on the lowest common denominator in a lot of ways. So ideally I'd like to have a way to handle all the various cases as best as possible in the most restricted scenario.

For example, I'd love that an archive built on a recent Linux distribution with all the needed checksum commands can be extracted (and ideally verified first) on something like a minimal stock HP-UX installation.

from makeself.

@megastep can you prove that a minimal stock HP-UX installation does not support, for example, sha512 ? Because my research suggests that you cannot.

from makeself.

I wasn't really referring to HP-UX specifically, though I have handled plenty of older Unix systems that barely had anything but the cksum or md5sum commands (not to get into specifics at the moment). Think even outdated systems like SCO or IRIX.

from makeself.

@megastep, okay let's get very general: What is your support schedule for the operating systems you mention? How long will makeself support the systems you yourself call "outdated"? At what point does the cost (to the security of modern systems) become more important than running on a Unix that may not have seen a release in the last decade?

If my tone seems overly aggressive, I apologize. I have a personal and professional interest in securing the makeself archives I create and I can't do that without modern digest tools. If there are old systems that require insecure tools, then I can understand --- but I do want to know exactly when (or if) the situation is likely to change.

from makeself.

@rubicks That is a fair point. The truth is I have been using Makeself in some commercial projects that have their own minimal system requirements (the main one for me is BrightQ). So the baseline for these as far as I am concerned is what is available on the targeted OS I have to support with this software (namely Solaris 10, AIX 4.3, FreeBSD 8, etc).

Believe me I would be in favor of dropping support for dinosaurs like SCO since nobody is using those anymore. But at the same time I am always reluctant to actively disable support for an old OS if leaving it in place doesn't cost me anything.

from makeself.

So I just added a new --sha256 option which uses shasum or sha256sum to compute and verify the archive, in addition to the other MD5 and CRC methods. You can also still get rid of the legacy checksums by using --nomd5 in addition.

Please test it and let me know if this works well for you.

from makeself.

@megastep, I'm happy to report that this new feature is working splendidly for me. Thanks very much, for both your receptiveness to our requests and your time in implementing this feature.

from makeself.

from makeself.