sha-1 vs sha1

[igor-raits]

Hello,

I'm packaging headers for Fedora and I noticed that it uses sha-1 which depends on quite some number of crates which had last release in 2016/2017 and we try to avoid packaging such crates. Would it be feasible to swith to sha1?

Thanks in advance!

[seanmonstar]

The sha-1 crate is published by the "RustCrypto" team, which I find valuable.

[trevyn]

@seanmonstar Possible to bump sha-1 to 0.9, then? https://github.com/hyperium/headers/pull/72

Looks like some soundness bugs were fixed in generic-array 0.14, a transitive dependency of block-buffer and digest: https://github.com/fizyk20/generic-array/blob/master/CHANGELOG.md

├── headers v0.3.3
│   ├── sha-1 v0.8.2
│   │   ├── block-buffer v0.7.3
│   │   │   ├── block-padding v0.1.5
│   │   │   │   └── byte-tools v0.3.1
│   │   │   ├── byte-tools v0.3.1
│   │   │   ├── byteorder v1.4.2
│   │   │   └── generic-array v0.12.3
│   │   │       └── typenum v1.12.0
│   │   ├── digest v0.8.1
│   │   │   └── generic-array v0.12.3 (*)

[barrowsys]

commit 31fe3e19e5763b95c9b5dfed1569bef555380dc4 replaces sha-1 with sha1

at the moment, the released 0.3.7 version of the crate does not have this change, and does not build.

   Compiling sha-1 v0.10.3
   Compiling headers v0.3.7 (/home/barrow/src/headers)
error[E0463]: can't find crate for `sha1`
  --> src/lib.rs:83:1
   |
83 | extern crate sha1;
   | ^^^^^^^^^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `headers` due to previous error

this is causing many downstream crates to also not build. a new minor release should fix.

[seanmonstar]

many downstream crates to also not build

This sounds like a different issue, there's no reason headers v0.3.7 should suddenly stop working.

Wrapping up here, though, we've changed to the sha1 crate as of v0.3.8.