Rust-crypto based md5 implementation

[newpavlov]

In the future it would be good if your repository became part of the larger repository which will contain hash functions for rust-crypto project to make it easier to maintain project. If you don't want to lose history something like subtree should suffice.

As for about controlling md5 crate, you can give an access to organization (for now it's RustCrypto, but I hope I will be able to contact with the current owner of rust-crypto), this will allow organization admins to publish new crate versions without your participation, but not to remove you from crate owners.

[IvanUkhov]

I see. You actually want to overwrite the entire crate. I’d then recommend following what num, futures, and tokio are doing. Namely, you could create a family of crates with a common prefix. For instance, you could have crates like crypto-md5, crypto-sha1, crypto-sha2, and so on.

[newpavlov]

I thought about such approach, but the thing is, most of the non-prefixed names are available, so there is a chance to make all (or almost all) crates with "natural" names part of the single effort of creating rust crypto platform. Of course if owners of several pre-existed crates will not allow to proceed with this plan I'll have no choice but to publish this several algorithms under the prefixed names. This will create name inconsistency across project and cause confusion for new users, which will be quite unfortunate, but I guess not lethal.

[IvanUkhov]

On the other hand, by having a common prefix, you clearly tell the users that those crates belong to the same project, that they play well with each other, that they are highly interoperable. Personally, if I had to choose between these two options—with and without a common prefix—I’d go for the one with a prefix. It seems to be an emerging pattern in Rust.

[newpavlov]

You definitely have a point. But initially I've planned to use meta-packages (e.g. crypto-hashes) for highlighting project's crates. And the second more practical issue: I've already started publishing non-prefixed crates and registered other available names.

Well there is no rush in deciding, so you can close this PR for now if you want. I think I'll proceed with non-prefixed names for now, but depending on feedback I could switch on prefixed scheme in the future.

[IvanUkhov]

I’m sorry, but I’d rather not make such a drastic change at the moment. There’re people who rely on the crate in its current state. It’s simple and has no dependencies. It does what it’s supposed to do.

[newpavlov]

Ok, no problem. Write to me if you'll change your mind.

As for whose who rely on the current crate, on of the reasons why crate versioning exists is to allow API breakage without consequences for users, this is why in this PR I've used version 0.3. (of course I speak under assumption what they do not use * in their dependencies section, which is considered bad practise for a reason)

Also in addition to no_stdsupport, proposed code depends only on pure-Rust crates, so to migrate on the new version users will only need minor code changes.

[tarcieri]

@IvanUkhov is there any reason why those people can't lock to the current version of the crate and then @newpavlov can publish a new one?

[IvanUkhov]

@tarcieri, I understand that you want the name so that RustCrypto’s crates’ names match the names of the corresponding algorithms. However, in my opinion, it’s a very fragile path that RustCrypto is talking. It takes only one name that RustCrypto cannot get on crates.io in order to break the naming scheme and make the whole family of crates look inconsistent.

Suppose you have the names sha2 and sha3 but not sha1. Then the crate implementing SHA-1 has to have a different name, and you end up with something like crypto-sha1, sha2, and sha3, which looks odd, taking into account the fact that the crates are meant to play together; they are parts of the same project. There are such cases already, and there will be more. Suppose tomorrow a new algorithm is invented, and the authors decide to call it “Tokio.” What do you do? It’s unlikely you’ll get that name on crates.io. A more reliable naming scheme could be to use the name of the project as a prefix: crypto-sha1, crypto-sha2, and crypto-sha3. In this case, it’s crystal clear that they have something profound in common, and you’ll get fewer collisions on crates.io.

[tarcieri]

@IvanUkhov if you don't want to give up the crate name that's fine. However, I was trying to propose a technical solution to a specific problem.

[IvanUkhov]

I apologize if it sounded rude; I didn’t mean it to come across that way. If the name is out of the question, there is no problem to solve. As I write above, the crate is simple and has no dependencies, which, I think, people appreciate. It does exactly what it’s supposed to.

[jhg]

I'm a third in this then it'll be only a opinion more. @newpavlov and @tarcieri consider the idea of @IvanUkhov about prefix, check it:

• In any IDE that integrate (or with extension for) crates search it's so easy look at all about one project.

Someone realize that hmac require sha2 and that's available when enter in the doc.

The crate page really is so summarized. Too much summarized. It's easy not to enter in the doc link and continue looking in crates.io without realize what it does and that there is available more crates that work well together.

• With the prefix it sounds like maybe it's part of something. Maybe not for all people, because that the crate page could be a nice welcome to a crate of a project bigger than a crate.

• And in the end, for the meta-crate it's in use the prefix...

Also maybe an abrupt change is not the easier way to do a fusion of crates when both have hundreds of thousands of downloads in the last months.

• Incremental additions like to use both a common trait could be more easy. Maybe as an common small dependency and optional if that can avoid download or add anything for who doesn't want that and would like continue with a crate of zero dependencies.

Also that could bring that anyone could choose use one crate with some dependency from other project. Something more that only request a name, then the name could be out of the question as @IvanUkhov told.

[tarcieri]

@jhg FYI, there's an open issue about package naming here RustCrypto/traits#102

[tarcieri]

It's been a few years so I thought I'd check in again. Any further thoughts on this?

FYI, at one point we did discuss renaming all of our crates with a rustcrypto-* prefix, and Linux distribution maintainers hated that idea. See aforementioned issue.

md-5 is possibly the only naming notable oddity in the hundreds of crates we maintain. We used to have sha-1 but have since acquired the sha1 crate.

@IvanUkhov perhaps you could do the same thing as we did with sha1, where the original crate was republished as sha1_smol, providing a simple migration path for existing users.