On Thu, 2022-12-01 at 00:41 +0000, Daniel Alley wrote:
I'm quite not sure how one would go about empirically measuring
something like that - at least in the general case. It might be an
interesting research topic. So no, unfortunately I don't really have
hard evidence for this.
We did run discovery for this in RHEL when we started the SHA-1
deprecation process.
Some embedded implementations were found but the vast majority of
programs used one of the available libraries for SHA-1. I do not expect
SHA-256 to be any different.
so empirically I can tell you there isn't anywhere as much "vendoring"
in C as you claim. Using dynamically linked libraries is well establish
and the reason why sometimes the dependency chain is ... monstrous.
I just know that of all the C libraries I've looked at, in my
personal experience it seems to be a very common phenomenon to copy
or reimplement code that in Rust you would just import and re-use.
Perhaps this is true in the niche you are interested in?
It's just a pattern that one notices frequently when it comes to
C
libraries, especially crossplatform ones that can't rely exclusively
on the existence of a Linux-like package manager.
Yes, those kind of libraries tend to be quite bad in this regard, OTOH
it can be done right.
For example the NSS library generally carries copies of external
dependencies, but the configure script looks for a system version and
links to the one if available on build.
So if you looked at NSS you may think it vendors, and it does, but
smartly and in a way that is compatible with systems integration.
If you want specific examples, the ones that pop to mind are:
* zchunk and deltarpm both reimplement / "bundle" multiple different
hashing algorithms
* libcomps implements about 4 different relatively common data
structures
I am not sure this qualify as vendoring/bundling, kind of borderline
but I see why you added it as a case.
* GTK appears to contain a bundled, forked copy of the CRoaring
library
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc