Adding SHA256 verifier to TC

[noen]

Please consider adding of SHA256 checksum verifer to TC.
There is increasing number of files eqiped with SHA256 checksum only, and there i do not see way to simply (as simply as md5 in TC) confirm them...
Now I have to use external verifier which is not as nice as md5 in TC. ):

The file structure is similar to this:

SHA256 (cd49.iso) = e5c7e41f033f42cc20c745aa4ebc8bef4f86845e68b75449146b0c5f4a5a37ef
SHA256 (cdboot) = 2d9bf832d3ba178d3596d20c9667a080bb33bd55a2bfee99cebd338661700170

[ghisler(Author)]

SHA256 is already supported, but the format you describe is quite unusual. TC expects files like this:

e5c7e41f033f42cc20c745aa4ebc8bef4f86845e68b75449146b0c5f4a5a37ef *cd49.iso
or
e5c7e41f033f42cc20c745aa4ebc8bef4f86845e68b75449146b0c5f4a5a37ef cd49.iso
or
cd49.iso e5c7e41f033f42cc20c745aa4ebc8bef4f86845e68b75449146b0c5f4a5a37ef

What program creates the above format?

[noen]

Those lines were generated by standard unix tool 'cksum' (in this case under OpenBSD).
The same format is used for md5 and sha256 checksum and also for 'md5' commnad.

I think that this format could be easly implemented and could increase value of TC.

Example:

MD5 (smb.stop) = a95cd2af2b398e0b163490fe0bb3f7e6
or
SHA256 (smb.stop) = 9c7bd270d9a1d0803ba4b3d288c1cf3bc4981032b3d56668de2e57a8c3038fc3

About implemented version...
There mus be a bug in the 3rd format (with filename at the begining).
When I was testing file with name at the end of line (both versions) chcecksum was verified.
When filename was in front there was something strange: errors:0, OK:0 ... ):

Maybe you can add sha256 checksum generator (compatible with this format)?

[MVV]

noen, how your cksum works with files with braces () in names?

[noen]

noen, how your cksum works with files with braces () in names?

Ask OpenBSD developers... (:
For unix cksum is a standard for years...
Handling outside brackets is only matter of good code, and i am sure author of TC can write it without any problems.
(signature at the beginning of line and checksum code length is constant)

Specially for MVV, to explain how it works, below example for file name 'zz(--) = --.s':

MD5 (zz(--) = --.s) = 4ed3bb572a5f3959380a9709f3cdfb41

...and yes, cksum can generate and check it's own checksums... (:

[MVV]

Does it work with filename like this?

Code: Select all

a.txt) = 4ed3bb572a5f3959380a9709f3cdfb41

It is much more clever way to put fixed-size checksum string before filename string which has variable length and contents (like in TC).

BTW, how old is this tool? Is it older than TC?

[noen]

Yes, it does.
MD5 (a.txt)) = ac59f8c465c21938f1be554fcc583867
It works with any name... which part you do not catch? (:

It is not matter of clever way.
cksum uses both methods but the one i presented is more frequently used (old one is for compatibility).
The fact that TC do not know it, makes TC not as usable as it can be.

Dear MVV, I am not an enemy of TC.
I simply want the TC was getting better and better...
...because increasing number of software is distributed with this style of checksum.

The newest version of cksum is from newest version of OpenBSD (4.9 in this case) which was released May, 1st.
Which software (TC or cksum) is newest is not a matter in this case.
This tool it is constantly evolving as TC is. So stop arguing that way.

[HolgerK]

2noen

It would have been better to provide a link to cksum man pages:

http://nixdoc.net/man-pages/openbsd/man1/cksum.1.html#STANDARDS

Looks like cksum can generate a lot of formats which are not recognized by TC...

Regards
Holger

[noen]

Here is OpenBSD cksum manual.

http://www.openbsd.org/cgi-bin/man.cgi?query=cksum&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Yes, cksum and other similar tools can be helpful during TC development.
However i was asking only for new (to TC) data format for known algorithms.
(checksum verifier and generator if possible)
Implementing new algorithms would be nice (:

[MVV]

Yes, it does.
MD5 (a.txt)) = ac59f8c465c21938f1be554fcc583867
It works with any name... which part you do not catch? (:

I was talking about whole code block as filename, not only its beginning.

Code: Select all

a.txt) = 4ed3bb572a5f3959380a9709f3cdfb41

So file line should look like this:

Code: Select all

MD5 (a.txt) = 4ed3bb572a5f3959380a9709f3cdfb41) = 8594565434585734380a9709f3cdfb41

Such a crazy filename.


I've tried to find some manual pages for this tool but none of them describe output format.

Don't forget that we can't integrate all world-existing stuff into TC because we don't need a monster.

[noen]

To MVV:
Yes, it works and generate
SHA256 (a.txt) = 4ed3bb572a5f3959380a9709f3cdfb41) = 247029e0278edaee5bd8f9396663735eb027c5368c9d3c47749540877846ad5d
and yes cksum can verify it without any problem...

It works with any filename! Accept that (:
If you do not belive please go and test it for yourself! (:
If it did not work it would not be used around the world...

I do not want a monster... (:
When increasing number of files has new checksum format, TC should inlcude it (or even switch to).
Small modification but very useful... (and usefulness is a strength of TC)

To all:
Please notice that this format of describing checksum also makes possible
of combining all types of checksum in one file without differentiate to md5, sha1, sha256 etc. during verify.
Easy to read by human, only one extension of checksum to use in TC...

[HolgerK]

To all:
Please notice that this format of describing checksum also makes possible
of combining all types of checksum in one file without differentiate to md5, sha1, sha256 etc. during verify.
Easy to read by human, only one extension of checksum to use in TC...

Which of them should be verified by TC if you double click such a checksum-file?

If the answer is "all": What happens if one of them failed the verification?

errors:0.33, OK:0.66 (huch: 1% is missing.. )

I don't consider it as very useful to create just another standard for checksum files

Regards
Holger

[noen]

Which of them should be verified by TC if you double click such a checksum-file?
If the answer is "all": What happens if one of them failed the verification?
errors:0.33, OK:0.66 (huch: 1% is missing.. )
I don't consider it as very useful to create just another standard for checksum files

You do not have to create new standard.
Just use those which exists... and are popular...

Which to check? All which are in file... (just like it is now)
If one of them failed, message will be exactly the same as you see in TC now.

If i am not clearly readed, for single file containing:
MD5 (file1) = 01234...
SHA1 (file2) = 01234...
SHA256 (file3) = 01234...

message could be for example:
OK: 3, ERR:0
or
OK: 2, ERR:1
and other.

Nothing new, everything simple and logical...

When you create md5 checksum, TC create only md5 items, for sha256 only sha256 items and so on...
Regardles of file origin all fiels will be verified without problems.
Checksums generated by TC will be recognized in different operating system as well.
If you have different checksum you can even merge them ito one file.
TC will manage to verify them all.

Only one thing is to accept description which is used in checksum files...

I see you all the time say "not". Why? "Because..."
It is not an answer. Tell me why not?
Plesae convince me why do not implement this format, but please, use reasonable arguments.

[HolgerK]

If i am not clearly readed, for single file containing:
MD5 (file1) = 01234...
SHA1 (file2) = 01234...
SHA256 (file3) = 01234...

Your notice to all could be read as:

MD5 (file1) = 01234...
SHA1 (file1) = 01234...
SHA256 (file1) = 01234...

Please do not misunderstand my intentions.
It is not to question the usefulness of every request, but rather to ask for details.

Regards
Holger

[noen]

Please do not misunderstand my intentions.
It is not to question the usefulness of every request, but rather to ask for details.

Regards
Holger

Now i catch the point of yor message (:
Excuse my english...
I could be misuderstood and i could misunderstood you.

My suggestion affects the following matters:
- use this format (in paralel to those used in TC now)
- the best way is to use it as default (but older will be respected for compatbility)
- creation and verification of checksum could be easily expanded in future for example: sha512, sha1024 or new algorithms (:
- checksum file could merge different checksum items and could be marked by extension (definied in TC config).
- extension(s) association could be defined in TC config (with default prefered) for internal processing (or leave it as it is now)
- increase compatibility with other operating systems
- increase usefulnes of TC (:
- simplicity of modification of existing code
- created checksum files is easily readable by human

I hope this summary, man pages and previous messages can describe advantage of implementing this checksum format in TC.
In addition to this, code for compute new (for TC) checksums is freely available.

Is there a chance to convice you and TC author to implement this format? (: