Please consider making download a non-default feature

[Andlon]

I've raised a similar concern before in #29. The situation is much improved now since a local library is sought first, and there is a download feature which controls whether or not MKL might be downloaded if none was found.

However, because the feature is default, it means that if any library depending on intel-mkl-src fails to set default-features = false, the download option will be enabled, and there is no way to turn it off (besides patching all dependencies that use it). There are several reasons why downloading is problematic or undesirable:

1. The Intel MKL binaries can be pretty huge (potentially hundreds of megabytes). I would not expect simply adding a dependency to Cargo.toml could result in hundreds of megabytes in bandwidth for a single dependency. This is problematic for people on limited connections (slow / capped / mobile).
2. It represents a potentially very dangerous attack vector. If someone with malicious intent would gain control of intel-mkl-src and modified the source code for evil purposes, in this case there would be a record of the release, and it would be detectable by inspecting the source code uploaded to crates.io. However, by just downloading a binary blob off of AWS there are no guarantees that a malicious actor hasn't switched out the binaries with malicious code. This would be much harder to detect.
3. The feature only works for as long as whoever foots the bills for AWS is still paying. This might be somewhat mitigated by moving to GitHub Releases however, (as discussed in Hosting MKL binary on GitHub release instead of S3 #58) and you can anyway install system libraries.

My suggestion is as follows:

1. Make download non-default.
2. Encourage library authors to not enable it.
3. Instead, encourage end users (i.e. those producing a binary application) that want the automatic download to turn on the feature in their binary crate instead.

I would love to hear your thoughts. For us this is currently a blocker from possibly diverting our attention from our own mkl-sys crate (not on crates.io) to instead contributing to this crate. I think for the sake of the ecosystem it would be great if we could consolidate efforts here.

[njaard]

Hi Andlon, I have forked this crate to https:/njaard/mkl-src/ because of the apparent absence of the original author. To be clear, it's with complete respect to @termoshtt's work.

May I ask you to re-submit your issue for the purposes of a paper trail and I will be pretty much immediately apply the change.