Bug 907464 - cpanm bundle lots of library and is not listed on fesco page
Summary: cpanm bundle lots of library and is not listed on fesco page
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-App-cpanminus
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 952281 (view as bug list)
Depends On: 929254
Blocks: DuplicSysLibsTracker 952282
TreeView+ depends on / blocked
 
Reported: 2013-02-04 13:27 UTC by Michael S.
Modified: 2014-01-02 13:35 UTC (History)
4 users (show)

Fixed In Version: perl-App-cpanminus-1.6927-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-11 08:35:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1045378 0 unspecified CLOSED perl-App-cpanminus: does not build from source code 2021-02-22 00:41:40 UTC

Internal Links: 1045378

Description Michael S. 2013-02-04 13:27:29 UTC
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 )

Comment 1 Marcela Mašláňová 2013-02-04 15:14:52 UTC
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.

Comment 2 Michael S. 2013-02-04 16:28:22 UTC
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 :
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_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.

Comment 3 Marcela Mašláňová 2013-02-05 08:46:57 UTC
Filed as:
https://fedorahosted.org/fpc/ticket/250

I wonder if the wiki is checked by security team for possible CVEs.

Comment 4 Petr Pisar 2013-04-15 15:22:15 UTC
*** Bug 952281 has been marked as a duplicate of this bug. ***

Comment 5 Florian Weimer 2013-04-15 15:34:00 UTC
As of upstream version 1.6108, the situation is even worse because the bundled sources are now obfuscated.

Comment 6 Petr Pisar 2013-08-02 15:20:07 UTC
I have unbundled version 1.6927, but it requires these unpackaged modules:

perl(Module::CPANfile)
perl(version::vpp)

I guess core-only version::vpp is useless. Standard perl(version) should be enough.

Comment 7 Marcela Mašláňová 2013-08-05 08:57:18 UTC
I agree, standard perl(version) should be enough, when I was looking on this package.

Comment 8 Fedora Admin XMLRPC Client 2013-08-12 13:14:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


Note You need to log in before you can comment on or make changes to this bug.