Ring: re-export `untrusted` to prevent version mismatch

[drahnr]

This can be cause be variety of constraint specifications other than a very fixed version (x.y.z) for both crates.

[briansmith]

@drahnr Thanks for reporting this. I think your idea is this:

• ring should pub use untrusted, or whatever, so that there is a ring::untrusted module inside ring that contains the entire untrusted API.

• webpki and Rustls other ring-based crates should stop depending directly on untrusted in their Cargo.toml, and should instead use ring::untrusted, so that they automatically pick up whatever version of untrusted ring is using.

I think this is an interesting idea. I'm not sure how necessary it is. We make changes to untrusted very rarely, and those changes are rarely breaking changes. I guess it would be good to get feedback from others about how useful it would be first.

[andrewtj]

We make changes to untrusted very rarely, and those changes are rarely breaking changes.

Perhaps it's time for an untrusted 1.0 so minor releases can be more compatible.

[drahnr]

@briansmith that is exactly right, sorry for my initial brevity.

The initial issue I faced was regarding multiple crates of one project depending on conflicting untrusted versions while they actually might be completely compatible. Using re-exports will avoid this.

[hahseba]

Just to weigh in, I don't think it's strictly necessary but I've found it to be an unnecessary papercut to be required to explicitly depend on another crate to be able to work with ring. To me, maybe the right question would be "does it hurt anything to re-export untrusted?" rather than "is it a big improvement?".

[briansmith]

Closing this because I'm planning to remove untrusted from the public API completely.

[briansmith]

In the current ring master, almost all of the public API has been changed to avoid using untrusted. (Some less-commonly-used APIs are still using untrusted.) Take a look and report anything problematic.