Publishing on Crates.io?

[sagebind]

This is more of a question than a feature request. Currently MesaLink is not available on crates.io, which makes it difficult to use within a Rust application. I know that native Rust code is better to use Rustls directly, but I'm in a bit of a unique situation.

I am interested in adding to the curl-sys crate on crates.io the ability to statically link to MesaLink as the TLS implementation; this would allow Rust applications to use a statically linked libcurl that in turn uses a statically linked MesaLink for its TLS implementation. This would be a pretty big win for Rust applications that make use of curl (including cargo itself) as it eliminates the OpenSSL dependency and gains the safety of MesaLink + Rustls.

Doing this as-is is a challenge for several reasons:

• curl-sys cannot be published to crates.io if it depends on crates that are not also on crates.io
• We need to be careful to ensure that libraries are not duplicated (like libstd) when linking to MesaLink. Having Cargo aware of the mesalink crate is the best way to avoid this.

I see only a few ways of making this possible:

• Publish mesalink to crates.io along with its forked dependencies (as mesalink-rustlsand so on).
• Absorb all of mesalink's forked dependencies inside the mesalink crate (under modules or something) and publish that.
• Pre-compile MesaLink without libstd for every platform, and ship that as a wrapper crate. (yuck)
• Create a mesalink-sys crate that builds MesaLink inside a build script. (Awkward running Cargo inside a build script inside Cargo...)
• Fork MesaLink and do one of the above.

I am interested to hear of better solutions, or if there is any interest in publishing to crates.io.

[ymjing]

Hi @sagebind, your proposal sounds awesome!!!

A straightforward approach is to use the depdencies on crates.io instead of our forks; then we can publish MesaLink on crates.io; although this comes with a cost that users wouldn't be able to customize ciphersuites.

[sagebind]

Submitting patches to the upstream crates to avoid using forks does seem like the most ideal way, though publishing the MesaLink forks with a mesalink- prefix seems reasonable to me as a stopgap until it is no longer required.

[ymjing]

@sagebind rust-lang/cargo#7237 seems promising.

[ymjing]

Just published MesaLink on crates.io: https://crates.io/crates/mesalink

This version is built with the crates_io branch of MesaLink, which depends on the original rustls and webpki on crates.io instead of our forks. However, the following 3 APIs are disabled due to limitation in rustls and webpki.

• mesalink_SSL_CTX_set_verify
• mesalink_X509_get_alt_subject_names
• mesalink_X509_get_subject

I can bring them back once rust-lang/cargo#7237 is merged.

[sagebind]

That's great news, and a good first step! That version isn't sufficient for curl (it needs mesalink_SSL_CTX_set_verify... 😢), but I'm glad to hear that this can be done fully soon.

Also, it seems like the version you published does not include TLSv1.3 support. mesalink_TLSv1_3_client_method is not defined, and the tls13 feature does not exist.

[ymjing]

Just yanked 1.0.0 and added 1.0.0-cratesio with tls13 fixes. And mesalink_SSL_CTX_set_verify is back! But client authentication is not supported 😢.

[sagebind]

That's great! I just tried it out and confirmed that it appears to be working well when integrated with the curl crate. Since curl only cares about server authentication it should be fine for this use case, but I would warn users about client auth config being ignored if it isn't resolved soon.

Though if rust-lang/cargo#7237 does arrive soon, then we could have just added MesaLink as a Git dependency of curl-sys, and you wouldn't have had to worry about publishing to Crates.io at all. I wouldn't want to hinder MesaLink's primary use-case...

[sagebind]

MesaLink is almost useable now from curl-sys, but currently there's no way to access the C headers without copy-paste. I opened a separate PR here to add that: #31

[sagebind]

With #31 now merged in, MesaLink seems to be ready for use as a Rust crate. @kevinis Thanks for your help on this!

[ymjing]

@sagebind No problem!

[ymjing]

I'm leaving this issue open for a while until alexcrichton/curl-rust#280 is merged.

[sagebind]

I imagine that PR can't be merged until after the recent changes are published to crates.io.

[ymjing]

No problem. 1.1.0-cratesio just pushed to crates.io based on the current crates_io branch.