japaric / as-slice Goto Github PK

generic-array v0.12 and v0.13 are vunlerable
See https://rustsec.org/advisories/RUSTSEC-2020-0146

This makes as-slice vulnerable too:

✦ ❯ cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 248 security advisories (from /home/sergey/.cargo/advisory-db)
    Updating crates.io index
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (7 crate dependencies)
Crate:         generic-array
Version:       0.12.3
Title:         arr! macro erases lifetimes
Date:          2020-04-09
ID:            RUSTSEC-2020-0146
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0146
Solution:      Upgrade to >=0.14.0
Dependency tree: 
generic-array 0.12.3

Crate:         generic-array
Version:       0.13.2
Title:         arr! macro erases lifetimes
Date:          2020-04-09
ID:            RUSTSEC-2020-0146
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0146
Solution:      Upgrade to >=0.14.0
Dependency tree: 
generic-array 0.13.2

error: 2 vulnerabilities found!

Would you consider releasing a new version with dropped support of the vulnerable versions of generic-array?
(I am not sure what is the best solution to the problem, but just want to point to its existence)

Thank you in advance! <3

UPDATE:
Alternative solution could be, if generic-array will backport the fix to the old versions.
See: fizyk20/generic-array#99

Hey there,

the newest version the package at https://crates.io/crates/as-slice is 0.1.3 (there's also been a 2.0 version but it's yanked). The version in master is 0.1.2.

Background

In PR #3 the generic-array dependency was semver bumped and v0.2.0 of this
crate was released just to include that change.

In general, I prefer to avoid making a new minor release (AKA semver bump) of an
"interface" crate, which main role is providing a trait for crates to
inter-operate, because it causes the ecosystem to be split in two. For example,
for aligned to work with as-slice v0.2.x (PR rust-embedded-community/aligned#6) I would need
to semver bump the aligned crate (i.e. release v0.4.0). Then cortex-m to
work with that new version of aligned would need also a semver bump. You can
see how this produces a cascade of semver bumps across the ecosystem.

Proposal

In the case of PR #3, the goal of supporting generic-array v0.13.x could have
been achieved without a semver bump. So I propose we support that crate on the
v0.1.x line and yank v0.2.0.

Bump the MSRV

(MSRV = Minimum Supported Rust Version)

Due to the generic-array dependency, as-slice v0.1.0 has an effective MSRV of
1.19.0; on the other hand as-slice v0.2.0 has an effective MSRV of 1.31.0.

In this first alternative, the approach would be release a v0.1.2 of as-slice
that depends on both generic-array v0.12.x and v0.13.x. This approach bumps
the MSRV of v0.1.0 from 1.19 to 1.31 in v0.1.2, which is a breaking change.
However, we can get away with the MSRV bump because there's no guaranteed
MSRV; MSRV is not documented therefore there's no guaranteed MSRV.

Cargo feature

The other option is to support generic-array v0.13.x in v0.1.2 behind an
opt-in Cargo feature, e.g. ga13. Enabling this feature makes as-slice v0.1.2
support both v0.12.x and v0.13.x of generic-array. Enabling the Cargo
feature does bump the MSRV but this is not a breaking change because it's
an opt-in bump.

Isn't depending on two generic-arrays bad for compilation time?

No, there's hardly any difference in compilation time between compiling
generic-array once or twice. I measured cargo clean; cargo build-ing this
crate and I got 2.64 s +- 0.5s for both configurations, so if there's any
difference is within standard deviation.

Isn't yanking v0.2.0 a "breaking change"?

No, it's not a breaking change according to the Rust project's concept of
guaranteed stability. Crates that depend on v0.2.0 published on crates.io will
continue to use version v0.2.0 and thus continue to compile. On the other hand,
unpublished crates, which can be modified by the person who's compiling them,
will indeed break but can be easily fixed by subbing v0.2.0 for v0.1.2.

But builds will break!

Sure, but the CI builds of unpublished crates also break whenever new warnings
are introduced in rustc and you were using #[deny(warnings)]. This breakage
is along the same line and still within Rust's concept of guaranteed stability
of published crates, which all crates are expected to follow (e.g. by
following semver).

This is not a pain-free change but I think some short-term pain is a better alternative than a long-term ecosystem split and a cascade of semver bump.

Thoughts? @korken89
cc @burrbull

On targets with 16bit for usize or less, the compilations fails due to the overflow of usize due to the shift by 16

I noticed this while trying to use the heapless library with an atmega328p. If you want to stick to the implementations up to 1 << 16 it could be a better option to split the array! macro call into several and guard them with #[cfg(target_pointer_width = " ...")]. I'll fire up a PR for that ;)

Compilation error is something like that

error[E0080]: evaluation of constant value failed
   --> /home/bisbarn/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs:169:102
    |
169 |     250, 251, 252, 253, 254, 255, 256, 1 << 9, 1 << 10, 1 << 11, 1 << 12, 1 << 13, 1 << 14, 1 << 15, 1 << 16
    |                                                                                                      ^^^^^^^ attempt to shift left by 16_i32 which would overflow

This crate presently pulls in both generic-array v0.12 and v0.13.

It'd be nice to also support v0.14, and potentially toggle off v0.12 and/or v0.13 support unless they're really still needed.

Related: #2