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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
