On Sat, Jul 8, 2017 at 10:24 AM, Ville Skyttä ville.skytta@iki.fi wrote:
7.7.2017 20.45 "Jason L Tibbitts III" tibbs@math.uh.edu kirjoitti:
I would argue that it doesn't remove the ability, but that it does make it more difficult to do in an automated fashion. Basically you can see that something has a bundled library but then you need to do manual inspection to go further.
I think the versioning isn't worth much at all.
If the bundled version corresponds to an upstream release to an extent that it can be called that version, and checks like the discussed one could be skipped just by looking at the version label, then it must be practically the same. So why is it bundled in the first place?
On the other hand if there is a "good" reason it is bundled, that reason quite probably is that it is a modified version. So it's different than the upstream one, and thus knowledge whether an upstream release is vulnerable or not cannot be just assumed based on the version label a packager has attached to it. It needs to be checked anyway.
The main motivation for bundling as of late is golang[0], it's extremely common out in the community for software to pull in "Vendored" libraries even if they are exact copies of remote upstreams (this is common with tools like godep[1]) because golang is statically compiled by default (you can dynamically link with gcc-go and I *think* recent releases of cgo but I've yet to find a golang project that officially uses or endorses it's use). It's also extremely painful to unbundle these as some more popular software written in golang such as docker[2], kubernetes[3], and openshift[4] have upwards of 100 bundled libs (over 1000 for OpenShift).
-AdamM
[0] - https://golang.org/ [1] - https://github.com/tools/godep [2] - http://pkgs.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec [3] - http://pkgs.fedoraproject.org/cgit/rpms/kubernetes.git/tree/kubernetes.spec [4] - http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org