Red Hat Bugzilla – Bug 907464
cpanm bundle lots of library and is not listed on fesco page
Last modified: 2014-01-02 08:35:13 EST
According to the comment in the spec, and the source of cpanm, there is lots of perl modules bundle into the main software. While the way cpanm work kinda mandate it, I think there should be some tracking for it, only for security update reasons.
I would suggest to contact fesco and see what to do ( ie, either unbundle, or get a bundle exception, and list the module on the appropriate page, with appropriate provides bundled(foo) tags )
Did you look in to the tarball? It is not bundled like copied the module, but the "function" is copied into the main code. cpanm does it to have a minimal dependency chain, which is a must for this kind of a tool.
Also the bundling exception is given by FPC not FESCo. If you still believe it should be acked by FPC, then please feel free to reopen.
Yes, I have read the source code, and I am aware of the reason on why cpanm do it ( hence the "While the way cpanm work kinda mandate it" part in my first comment ).
But as I said, I think this should be tracked somewhere. I have seen how the code is bundled and I know this would be quite hard to unbundle, but I am not FPC, so in the end, it is up to them to decide, not to me, hence the request to see with them. If I was the one to decide, I would grant a exception, provided we can find what is bundled, so if any security issue arise, we can quickly see this should be fixed in cpanm too.
For example there is a bundle of JSON::PP or HTTP::Tiny, and I picking these 2 because they are either consuming untrusted input or network stuff, so could in theory be problematic.
And in all case, the packaging guidelines are quite clear on what to do if there if there is a bundle :
This include adding a link to the ticket for the exception. And while the ticket look like bureaucracy ( since I think the exception would be granted ), I think only FPC can edit the wiki page with bundled exceptions list, and that would be used as a reference source, and so must be up to date.
The fact that only part of the code is copied doesn't make it less a problematic copy from a tracking point of view.
So yes, i think something should be done, and the current process and documentation requires some group to do it, and that's FPC as you correctly said.
I wonder if the wiki is checked by security team for possible CVEs.
*** Bug 952281 has been marked as a duplicate of this bug. ***
As of upstream version 1.6108, the situation is even worse because the bundled sources are now obfuscated.
I have unbundled version 1.6927, but it requires these unpackaged modules:
I guess core-only version::vpp is useless. Standard perl(version) should be enough.
I agree, standard perl(version) should be enough, when I was looking on this package.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.