usage in rocket / actix-web is "hard"

[pythoneer]

i tried to use the lib on rocket and actix-web and on both i have the problem with dependency resolution.

you're using tokio-rustls v0.5.0 which depends on ring v0.13.0-alpha5 and that collides with the current version of cookie which depends on ring v.0.11.0

here is the error from rocket

error: multiple packages link to native library `ring-asm`, but a native library can be linked only once

package `ring v0.13.0-alpha5`
    ... which is depended on by `rustls v0.12.0`
    ... which is depended on by `tokio-rustls v0.5.0`
    ... which is depended on by `a2 v0.2.3`
    ... which is depended on by `depend_test v0.1.0 (file:///home/dustin/Documents/dev/rust/depend_test)`
links to native library `ring-asm`

package `ring v0.11.0`
    ... which is depended on by `cookie v0.9.2`
    ... which is depended on by `rocket v0.3.13`
    ... which is depended on by `depend_test v0.1.0 (file:///home/dustin/Documents/dev/rust/depend_test)`
also links to native library `ring-asm`

and from actix

error: multiple packages link to native library `ring-asm`, but a native library can be linked only once

package `ring v0.13.0-alpha5`
    ... which is depended on by `rustls v0.12.0`
    ... which is depended on by `tokio-rustls v0.5.0`
    ... which is depended on by `a2 v0.3.2`
    ... which is depended on by `herold v0.1.0 (file:///home/dustin/Documents/dev/rust/herold)`
links to native library `ring-asm`

package `ring v0.12.1`
    ... which is depended on by `cookie v0.10.1`
    ... which is depended on by `actix-web v0.7.0-dev (https://github.com/actix/actix-web.git#5c42b090)`
    ... which is depended on by `herold v0.1.0 (file:///home/dustin/Documents/dev/rust/herold)`
also links to native library `ring-asm`

and i can't think of an easy way to resolve this currently. Any suggestions?

[pimeys]

I've had this same issue with Ring and some libraries. It contains some C-code in the ring-asm library that forces the whole project to use the same version.

What you could try is to update cookie, actix-web and heroid to use ring v0.13.0-alpha5, it should be possible with little or no changes. a2 uses rustls for alpn negotiation, so it's a quite hard dependency for this project right now.

Ring is also quite notorious forcing you to update, but they have a reason to keep people with the newest and most secure version.

Please tell me if you face trouble.

[pimeys]

Cookie did it already in master: https://github.com/alexcrichton/cookie-rs/commit/8579b4b7ca0fb4d698e0f4452d3fb55e9e72c50d

Actix is depending on cookie with their sessions feature, so you can either disable it if you don't need it or if you do, upgrade to the master branch of cookie: https://github.com/actix/actix-web/blob/master/Cargo.toml#L37

What I suggest is that you go with the Github versions and try to get updates to cookie-rs and actix-web through so the official versions would use the new ring. Please tell me if you have any trouble!

[pythoneer]

thanks for the fast reply. What i currently did was forking actix-web and changed the dependency of cookie manually this way but i don't really know if that is a good way or not.

what do you think is a good way from now on? Is it reasonable to open a ticket on the actix-web side as well? The problem is, i don't see anyone at fault here but it sure is a problem to a certain degree. Do you think that things like this just "settle" because its hard to justify such a situation for a production environment to be honest – i really like your crate and it feels mature but these dependency quirks let me think ...

EDIT: to be fair in that regard my current approach in python has some weird dependency difficulties with openssl, too – i don't see anyone at fault here, its just unpleasant.

[pimeys]

Welcome to the cowboy country! Rust async story is moving fast now and expect some changes before Rust2018 this Autumn, at least pinning and async/await.

For the crypto story, ring is quite ergonomic and absolutely the fastest crypto library available. It still uses C and assembly libraries for some of its algorithms, but one by one they're rewriting them to Rust. At some point there might be no ring-sys anymore, but that time is not yet. The best thing now is to keep track of ring versions and follow the upgrade path. At least it's much easier to upgrade to new major versions that it ever was with OpenSSL. A big thanks for @briansmith and everybody doing this work.

Also what we have here... The a2 is using libraries just released to crates.io. We have very stellar performance and reliability with this lib, but I expect even more of these hiccups as you witnessed before the situation settles. At least with Rust you can quite safely just upgrade and let the compiler find the problems for you. Never had any trouble after compilation was successful.

[pimeys]

https://github.com/briansmith/ring/issues/535

[pythoneer]

YMMD .. i can very much agree on the OpenSSL part. It is just a terrible experience every time something is not quite right (either system installed dependencies [on older systems] or library issues etc.)

after all, what i have here currently is insanely fast [after a few tests against the python approach] and i think i am just heading this way further and find out how this is going. I think i can close this for now because there is really not much to do here i think.

Have a nice day and thank you very much for your help, this really helped!