https://bugzilla.redhat.com/show_bug.cgi?id=1629642 Will Braswell <william.braswell@xxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |william.braswell@autoparall | |el.com --- Comment #1 from Will Braswell <william.braswell@xxxxxxxxxxxxxxxx> --- Actually, you do not need to evaluate $VERSION at all, you can use the (much safer) MetaCPAN API instead! Background: I caused this bug report to be opened by ppisar when I discovered the incorrect Perl module version numbers embedded in the perl-Encode RPM package. I am the author of the RPerl compiler, as well as the CPANtoFPM packaging system which automatically packages dozens (or hundreds) of CPAN distributions into the corresponding RPMs by use of the official MetaCPAN API. CPANtoFPM is based on the cross-platform FPM packaging system, which is used for generating RPM packages, DEB packages, and many other packing formats. Because of the cross-platform nature of FPM, it does not use the automatic capabilities of the perl-generators software, instead relying on its own Ruby implementation to generate the RPM specfile, etc. However, even though FPM does not use perl-generators itself, our generated RPMs must still be 100% compatible with the already-existing RPMs in the base repo which do use perl-generators, and this is how I discovered the incorrect version numbers in the ubiquitous perl-Encode RPM. (I assume the same problem of incorrect version numbers may be present in many other perl-* RPM packages, we just haven't found them yet.) Simply put, the version numbers currently created by perl-generators is incorrect, due to the differences between RPM versioning and Perl versioning. Thankfully, it is not very difficult to fix this problem, and I have already done so in my own CPANtoFPM software! :-) The perceived security risk of executing arbitrary Perl code can be completely bypassed by using the MetaCPAN API to make a simple JSON query. For example, to find all of the Perl modules (.pm files) provided by the Encode distribution on CPAN, simply fetch this URL: https://fastapi.metacpan.org/v1/release/Encode In the JSON data returned, you can see the "provides" data element is a string array of all the Perl modules provided by the Encode distribution, including "Encode" itself (in the file "Encode.pm"), along with "Encode::Byte" (in the file "Encode/Byte.pm") and many others. Then, for each of these modules listed in the above API request, you can formulate another URL to fetch the correct module versions, for example with the Encode::Byte module in question: https://fastapi.metacpan.org/v1/module/Encode::Byte You can see the following data returned among the JSON output: [[[ BEGIN JSON CODE ]]] "module" : [ { "version" : "2.04", "authorized" : true, "indexed" : true, "version_numified" : 2.04, "associated_pod" : "DANKOGAI/Encode-2.98/Byte/Byte.pm", "name" : "Encode::Byte" } ], [[[ END JSON CODE ]]] As you can see, the "module->version" data element contains the string with the REAL version you want, in this case "2.04", and you do not have to execute any potentially-hazardous Perl code whatsoever! In other words, you MetaCPAN evaluate $VERSION for you. :-) (Please note, do NOT use the "version" data element, because this is actually the Encode distribution's version, not the Encode::Byte module's version. Also, do NOT use the "module->version_numified" data element, because it is numeric data instead of string data and may have already undergone incorrect loss of significant digits which are preserved only in the "module->version" string.) You can also save time and bandwidth by combining all of the module version API requests into one single http fetch using the POST method, as shown in the following Ruby code snippet: [[[ BEGIN RUBY CODE ]]] # call metacpan API to find all modules belonging to distribution metacpan_search_url = "https://fastapi.metacpan.org/v1/module/_search"; metacpan_search_query = <<-EOL { "query" : { "constant_score" : { "filter" : { "exists" : { "field" : "module" } } } }, "size": 5000, "_source": [ "name", "module.name", "module.version" ], "filter": { "and": [ { "term": { "distribution": "#{VARIABLE_CONTAINING_DISTRIBUTION_NAME}" } }, { "term": { "maturity": "released" } }, { "term": { "status": "latest" } } ] } } EOL search_response = httppost(metacpan_search_url,metacpan_search_query) [[[ END RUBY CODE ]]] The output for this POST request is a bit more complex, but all of the needed version data is there. As mentioned above, I have already written all the Ruby code for parsing the JSON returned by all 3 of the above MetaCPAN API requests, and will be happy to share as needed. Unfortunately, at this time the RPM versioning for Perl packages is truly "broken", but as you can see we can fix it with just a few extra lines of code! Please let me know how I can be of assistance in fixing this bug, let's work together to make the RPM-and-Perl world a better place for everyone! Thank you for your time and attention. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
