I'm submitting a new package into fedora for uif2iso; the review ticket URL can be found at https://bugzilla.redhat.com/show_bug.cgi?id=881443. After an initial review by Eduardo Echeverria the source zip archive turned out to contain bundled libraries: libmcrypt and lzmasdk. I managed to create a patch that will modify the Makefile to link against the lzmasdk library already available in fedora through the lzma-sdk-devel package. For libmcrypt however, one file gost.c is modified from the original sources. I compared it to the sources of the SRPM fedora package for libmcrypt and found out that the modifications were even based on an earlier version of libmcrypt(couldn't identify which version exactly).
I hereby request an exception to bundle gost.c into a devel subpackage for uif2iso.
without more information, this sounds like a bad idea. gost is an encryption algorithm so bugs in it are likely to be security concerns. if you give us more information (such as the questions asked for on this page: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ) it might give us information that allows us to approve this but right now it seems likely that we'd tell you to work with upstream to get this ported to a newer version of mcrypt and remove the patch.
OK. I'll clarify things a bit.
Has the library behaviour been modified?
I really don't know. I'm not familiar with the library code or functionality(; I've never used it). Moreover the changes were based on an old version(that I couldn't determine exactly) and that makes judging the impact of the changes much difficult.
* Why haven't the changes been pushed to the upstream library?
As I knew from the upstream, there's no intention to release any update for their software as they see it fitting their users as it's now.
* Have the changes been proposed to the Fedora package maintainer for the library?
These changes were applied to an old version of the library; I'm not quite sure if it's appropriate to integrate them to the original package in fedora. Could we make the forked version the canonical version within Fedora? The latest version of the libmcrypt library is 2.5.8 release in 2007-02-19(as shown on [http://sourceforge.net/projects/mcrypt/files/Libmcrypt/ SourceForge]), and this's also the version packaged in fedora. Regarding uif2iso upstream being willing to make their fork a library that others can link against, as I said earlier upstream isn't planning to do any changes to their software for the moment.
Are the changes useful to consumers other than the bundling application? I don't know as I don't understand the changes well. A comment near the header of the modified file reads
// modified by Luigi Auriemma for emulating the shameful customizations of MagicISO
So it really might be only relevant to emulating MagicISO. Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release? The latest version of the library was released long ago(2007-02-19), however the bundled version inside uif2iso even looks older.
What is the attitude of upstream towards bundling? (Are they eager to remove the bundled version? are they engaged with the upstream for the library? Upstream has no plans to release a new version of uif2iso in the foreseeable future.
Does the maintainer of the Fedora package of the library being bundled have any comments about this? I haven't even tried to inform the maintainer.
* Is there a plan for unbundling the library at a later time? From uif2iso upstream perspective, no. From the library upstream perspective, I really don't know. It seems like the libmcrypt project has been inactive for the last 4 or 5 years.
Following is the mail I sent earlier to the upstream asking him to identify the sources:
From: Mohammed El-Afifi firstname.lastname@example.org
To: "email@example.com" firstname.lastname@example.org
Sent: Friday, November 30, 2012 6:26 PM
Subject: Fw: packaging uif2iso for fedora
As you know I'm in the process of packaging uif2iso as a RPM package for fedora. I've filed an initial review ticket(URL found below in my previous mail) and I've received a few remarks about it. I'm currently working on resolving these remarks.
One of those remarks are related to licensing issues. As per fedora packaging guidelines for software licensing found here https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text you're strongly recommended and encouraged to include the license text of GPLv2+ with your zip source archive. The reliable and canonical sources for license texts approved by fedora can be found here https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses.
Also I noticed that you used(sometimes modified) versions of some source files from external libraries, like lzmasdk and libmcrypt. I made a quick analysis of the sources files in the uif2iso zip archive and compiled the following list of results:
3way.c, rc5.c: unidentified source
bf_tab.h, blowfish.c, blowfish.h: publicly available source code from http://www.di-mgt.com.au/crypto.html
Bra86.c, Bra.h, LzmaDec.h, LzmaDec.c, Types.h: from lzma-sdk-devel RPM package in fedora
des.c, des.h: publicly available source code from http://www.mobilec.org/
gost.c: modified from the files provided by libmcrypt RPM package in fedora
idea.c: from the book Applied Cryptography. John Wiley & Sons, 1996. ISBN 0-471-11709-9. . by Bruce Schneier: (implements a patented algorithm)
dunno.c, magiciso_is_shit.h, uif2iso.c: authentic sources(by uif2iso upstream themselves)
loki91.c, loki.h: publicly available source code from http://www.mavi1.org/web_security/cryptography/aes-testing/loki/
seal.c: publicly available source code from http://www.mavi1.org/web_security/cryptography/General/
For point 3, I created a patch to use the lzmasdk library(as it's already packaged in fedora). For point 7 please correct me if my assumption is wrong, otherwise you don't have to do anything for this point. For other points, I'll be greatly grateful if you can provide advice and guidance to any official sources/libraries you based your work on(as the sources I listed above mightn't be the real sources you based your work on).
You'll find attached the second patch I've created to address the linking with an external fedora-provided lzmasdk library. You'll need to apply this patch(along with the one I sent you in a previous mail) to see how your sources will look like just before building under fedora(and also to get an idea of what I needed to change in your sources).
Thank you in advance for your cooperation and support and sorry for disturbance.
And this's a citation of the response I received from upstream:
at the moment I have no plans to update the uif2iso zip just because
it's ok for my usage and for my users.
I update it only if there is code to fix or add.
While, regarding the licenses of the various algorithms, some of them
are in public domain (like the whole lzma sdk).
For point 7 (dunno.c, magiciso_is_shit.h, uif2iso.c: authentic sources
(by uif2iso upstream themselves)) yeah they are all files created by me
and released under gpl2.
The original 3way.c is in public domain since it's the reference
implementation of Joan Daemen, the author of the 3way algorithm.
rc5.c derives from the reference implementation too, which is under
Please provide advice if I can take further actions in any of the previous points(related to the questions on the No Bundled Libraries page).
Thanks in advance for your support and cooperation.
Any suggestions for what I can do next?
Somehow this never made it back to committee. Is this still relevant? I will bump it to a meeting anyway to see if the committee has any input.
We talked about this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-12/fpc.2015-02-12-17.05.txt):
Metadata Update from @msk61:
- Issue assigned to tibbs
to comment on this ticket.