0

I've seen .sha256 files for software such as:

this_is_a_fake_sha256_hash_of_64_characters  file_name.exe

Or:

this_is_a_fake_sha256_hash_of_64_characters  *file_name.exe

Or:

this_is_a_fake_sha256_hash_of_64_characters  file_name.exe*

I know that Unix/Linux has a weird concept of outputting filenames with an asterisk in the end to mean "this is executable". Alright, so I guess that explains that. However, I have been utterly unable to find a single mention anywhere of what it means when the asterisk is in the beginning of the filename.

Also, even if somebody will answer here and tell me why it's sometimes in the beginning instead of the end, I still wonder why you'd confusingly include these asterisks in this "hash format". After all, this is NOT a local file list output, but a file format for verifying file hashes for distributed binaries. Why would you ever include anything but the actual filename in such a context? Just to cause problems when people don't realize that they need to remove those asterisks from both the beginning and the end of the actual filename?

Not every such .sha256 file uses asterisks at all. Some do and some don't. Some have it in the beginning and some in the end.

In my parser, I simply strip both, but it bothers me that I don't understand why this is done or what it means.

0
2

The man page says:

The default mode is to print a line with checksum, a character indicating type ('*' for binary, ' ' for text), and name for each FILE.

Using sha256sum -b ${filename} you can trigger the * before filename behaviour.

This means that the line format is one of: (note, your example is incorrect, invalid or has filenames with stars in)

  • ${hash}${space}${space}${filename}, or
  • ${hash}${space}${star}${filename}

I can't see a way to trigger the * after filename behaviour - even making a file executable doesn't do this for me.

Additionally, feeding one of the following line formats into sha256sum -c causes it to abort, complaining that the file cannot be found - i.e: it's not handling the asterisk prefix/suffix on the filename, and is considering it to be part of the filename.

  • ${hash}${space}${space}${filename}${star}, or
  • ${hash}${space}${space}${star}${filename}
$ sha256sum test.svg | sed -re 's/$/*/' | sha256sum -c
sha256sum: 'test.svg*': No such file or directory
test.svg*: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read
$ sha256sum test.svg | sed -re 's/  /\0*/' | sha256sum -c
sha256sum: '*test.svg': No such file or directory
*test.svg: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

The * after filenames convention comes from ls -F (as do /=>@|), and is likely unrelated here.

Can you re-create this file? If so, how?


Given your examples all have two spaces between the hash and filename, I'd wonder if there are files literally named *file_name.exe and file_name.exe*.

In my parser, I simply strip both, but it bothers me that I don't understand why this is done or what it means.

This is incorrect behaviour (note the 2x space characters, or 1x space and 1x star).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.