On Sat, Jul 8, 2017 at 10:24 AM, Ville Skyttä <ville.skytta@xxxxxx> wrote: > > > 7.7.2017 20.45 "Jason L Tibbitts III" <tibbs@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
