Add server-side checksums - #83
Open
christhomas wants to merge 1 commit into
Open
Conversation
Implements secsy#17. Two commands exist for this and servers are split between them. HASH is the standards-track one and reports which algorithm it used; the older XCRC, XMD5, XSHA1, XSHA256, XSHA512 and MD5 each compute one thing. Both are read from FEAT, so a caller does not have to know which the server implements — algorithms are named as HASH names them ("SHA-256") either way. Three things this decides rather than pass along: Results are lowercase hex, whichever command answered. Servers are inconsistent — proftpd's HASH replies lowercase and its XSHA256 uppercase — and a caller comparing against hex.EncodeToString would be right half the time for reasons nothing in their code would explain. An empty algorithm means the strongest available, ordered by collision resistance rather than speed. A caller who wanted speed would say so; a caller who did not is comparing files, and a CRC32 that matches is much weaker evidence than a SHA-256 that does. Replies are read from their last line, because servers may prefix a progress line ("Computing SHA-256 digest"). Tested against proftpd with mod_digest loaded: the assertion is that the server's SHA-256 equals what the file's bytes hash to locally, not merely that a string came back. pure-ftpd supports none of this and is in the same test run, so the "server computes no checksums" path is covered by a real server rather than a stub.
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements #17.
The answer in the thread at the time was to
Statthe file and compare sizes, with the acknowledgement that two files can share a size and differ. This is the thing that settles it.@fbrettnich mentioned proftpd's
mod_digestin the thread, which is exactly what this talks to.Two commands, and servers are split between them
HASHis standards-track and reports which algorithm it used. The olderXCRC,XMD5,XSHA1,XSHA256,XSHA512andMD5each compute one thing. Both are read fromFEAT, so a caller does not have to know which the server implements — algorithms are named asHASHnames them (SHA-256) either way.Three things decided here rather than passed along
Results are lowercase hex, whichever command answered. proftpd's
HASHreplies lowercase and itsXSHA256uppercase. A caller comparing againsthex.EncodeToStringwould be right half the time, for reasons nothing in their code would explain.An empty algorithm means the strongest available, ordered by collision resistance rather than speed. A caller who wanted speed would say so; one who did not is comparing files, and a CRC32 that matches is much weaker evidence than a SHA-256 that does.
Replies are read from their last line. Servers may prefix a progress line —
Computing SHA-256 digest— so the first line is not the answer.Tested against a server that computes them
proftpd with
mod_digest. The assertion is that the server's SHA-256 equals what the file's bytes hash to locally — the property the feature exists for, not merely that a string came back. Every algorithm the server advertises is also checked to be computable, since one advertised and then refused is worse than one never mentioned.pure-ftpd supports none of this and is in the same test run, so the "server computes no checksums" path is covered by a real server rather than a stub.
Loading
mod_digestin the test server is part of the container work in #73, so it isn't in this branch — the tests here skip cleanly against a server without checksum support, which is whatmaster's test servers are.