Bump version to v5, allow v5 use v4-sys

[kornelski]

When #406 is released, this will be backwards-compatible with projects using boring-sys v4.

This will be crucial for users of boring, because boring v4 and v5 can co-exist in the dependency tree (it's merely a bloat), but boring-sys v4 and v5 can't (due to linking C having globals all over the place). boring v5 with boring-sys v4 will let projects upgrade their dependencies gradually.

[kornelski]

@Lekensteyn

[nox]

We actually need an update of BoringsSSL itself in boring-sys, which I think makes this irrelevant?

[kornelski]

Irrelevant in what sense?

You haven't released v5 to crates.io yet, so I don't think anybody has experienced yet the pain I'm trying to prevent here.

[nox]

boring 5 can't work with boring-sys 4 if it uses new APIs that are only present in boring-sys 5.

[kornelski]

I've ran the tests on v5 with boring-sys v4, and it seems to be fine? (apart from minor tweaks that were fixed here: #406)

[nox]

Because AFAIK we haven't bumped BoringSSL in boring-sys yet.

[rushilmehra]

Do you have an example of one of the new APIs?

[nox]

As an example, the BoringSSL bump I'm working on needs changes to boring-pq.patch, and it now includes a new function SSL_use_second_keyshare.

[rushilmehra]

Yeah I see what you mean. This might be overkill but could we make a build.rs to feature flag APIs based on crate version? Alternatively, would solving #197 also solve this problem?

[rushilmehra]

I think it will. If you can wait until the weekend I'll put up a PR

[nox]

#197 breaks FIPS.

[nox]

thinking twice about this I don’t understand why we want boring 5 to be compatible with boring-sys 4. I think it would be preferable to make boring 4 compatible with boring-sys 5 once the latter is released.

[kornelski]

Extra functions can be made to work.

v4 sys crate can contain dummy definitions of future functions to avoid compilation errors.

or new functionality in v5 that calls new functions can be behind a feature flag. It will work if the flag isn't enabled.

[kornelski]

Yeah, we could make it flexible in the other direction instead.

[kornelski]

Making it compatible in the other direction is complicated by removal of Cargo features from the sys crate:

package boring depends on boring-sys with feature fips-link-precompiled but boring-sys does not have that feature.

it requires re-adding at least dummy feature flags: #410

[kornelski]

#442