Develop CVE Strategy?

[jeremiahpslewis]

The various difficulties and challenges with the CVE's in mbedtls (CVE in version built with Julia, lots of packages which (indirectly) depend on the library), distributed responsibility across main Julia repo and Yggdrasil ecosystem seem to point at the need for a clear CVE strategy.

As a starting point, (without a strong claim to completeness and acknowledging that is is a very complex topic) it might make sense to develop a position on the following questions (not all of which are strictly limited to Yggdrasil):

1. Should the Yggdrasil project try to proactively (and systematically) scan / subscribe to potential CVEs in project binaries?
2. How should Yggdrasil & julia communities collaborate / who / which org should take the lead in managing addressing CVEs for binaries which are shipped with julia?
3. Is there a goal / commitment to not ship Julia built with dependencies with known CVEs? Is this already the case? Is this feasible? How can it be made easier to track CVEs for binary dependencies which the language itself relies upon and can these be consistently incorporated into point releases?
4. If an Yggdrasil binary with a CVE is updated, how are downstream dependencies alerted / encouraged to update their package (e.g. 10 direct mbedtls dependencies, but 1.7k indirect ones)?

[giordano]

For point 4, downstream libraries need to do something only if the affected library changes ABI/API in the new version, which is what happens with mbedtls. But you can't just rebuild the downstream libraries against the new fixed library: there are compatibility bounds to respect, accept the fact we can't change compat bounds inside the same patch version (changing only the build number), and if the affected library is shipped by Julia, you have also to deal with julia compatibility bounds and not break existing packages

[mkitti]

I was looking into mbedtls and its ABI issues. This is mind-boggling:

https://github.com/ARMmbed/mbedtls/releases/tag/v2.28.0

Some fields of mbedtls_ssl_session and mbedtls_ssl_config are in a
different order. This only affects applications that define such
structures directly or serialize them.

They just rearranged the fields, and for what? That's crazy. I'm not confident that Mbed TLS is a good dependency to have upstream if they make such rearrangements flippantly like this.

[mkitti]

For what it's worth there is this:
https://github.com/JuliaLang/julia/security/policy
[email protected]

[fingolfin]

Indeed it seems bad that a TLS library of all things can't resist the "clean up for clean up's sake" urge :-(. Their sentence "This only affects" neatly leaves out "... code that is not recompiled". From the 2.26.0 changelog:

API glue function mbedtls_ecc_group_of_psa() now takes the curve size
in bits rather than bytes

So... Any code using this function that is just recompiled may be silently broken, too? Wow. (OK, I just checked: they also added one more argument, so recompilation will trigger this; but the ABI is indeed broken). I still don't get it; why not make a new function mbedtls_ecc_group_of_psa_bits which takes bits, and keep mbedtls_ecc_group_of_psa around, calling mbedtls_ecc_group_of_psa_bits? That way, only a new ABI is added, no recompilation needed. Urgh.

[ViralBShah]

I believe that github is trying to provide support for some of this stuff. Apparently they have APIs for building out the package dependency graph and I believe once you do that, things like vulnerabilities in dependencies can propagate etc.

[giordano]

The problem is that we are constrained by compatibility of packages in the registry and packages breaking the ABI every other day don't help us at all.

[fingolfin]

Of course in cases where there are security patches available for older versions of software (in particular for whatever version we use), then one could perhaps use those with relatively little pain. But often the instructions are simply to switch to the very latest version. Which indeed sadly is non-trivial, as far too many projects are very cavalier about breaking compatibility at any time :-(.

Of course in the end we are not unique with this issue, e.g. more or less all Linux distros suffer from a variant.

But it is indeed particularly difficult for us because of the super strict "precise version and even build variant must match" employed for the "stdlib JLLs". So even if one backports a patch for, say, mbedTLS_jll, I think right we'd also have to make new releases of affected Julia versions to take advantage of them, don't we?

[ViralBShah]

Yes, for stuff that is included in Julia itself, we have do new Julia releases, and also backport to LTS and stable. The points are valid, but I suppose the important thing is to have patched versions that people can easily update to, and to be security conscious. As I often hear - it is a journey, and it is important to get started.

[ViralBShah]

Is it better to have this issue on the BinaryBuilder repo - since Yggdrasil issues and PRs are mostly about packages? If so, let's transfer it there.