Bug 441517 - nant includes non-nant, not-from-source libraries
nant includes non-nant, not-from-source libraries
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nant (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Paul F. Johnson
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 435898
  Show dependency treegraph
 
Reported: 2008-04-08 11:24 EDT by Toshio Ernie Kuratomi
Modified: 2008-04-14 11:20 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.85-20.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-14 11:20:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Toshio Ernie Kuratomi 2008-04-08 11:24:04 EDT
Description of problem:
nant includes several libraries that do not belong to the nant package and are
not built from source.  These libraries should not be shipped with the nant package.

Version-Release number of selected component (if applicable):
nant-0:0.86-5.fc9.i386

nant for other releases (f8, etc) has not been checked.

How reproducible:
Everytime

Steps to Reproduce:
This problem was discovered by running the following repoquery:

1. sudo repoquery --repoid=development --whatprovides
'mono(ICSharpCode.SharpZipLib)'

Actual results:
mono-core-0:1.2.5.1-3.fc8.i386
nant-0:0.86-5.fc9.i386
mono-core-0:1.9-3.fc9.i386


Expected results:
mono-core-0:1.2.5.1-3.fc8.i386
mono-core-0:1.9-3.fc9.i386


Additional info:
This problem leads to banshee, f-spot, and other desktop apps depending on nant.

It looks like the entire  nant-0.85/lib/ directory in the source tree
(%{_libdir}/NAnt/bin/lib on the filesystem) might be upstream libraries that
need to be stripped out.

It also looks like we might need to do some further packaging of upstream
libraries to replace some of the things in that directory.
Comment 1 Toshio Ernie Kuratomi 2008-04-08 11:32:32 EDT
CC'ing Alex Lancaster because we were discussing this on IRC.
Comment 2 Alex Lancaster 2008-04-08 19:58:41 EDT
We downgraded to 0.85 because of issues with 0.86 (e.g. boo didn't build against
it), can you check if these problems are still in this build?

http://koji.fedoraproject.org/koji/buildinfo?buildID=41174

I'm not really the package maintainer and don't know much about mono packaging,
I was simply trying to repair the broken dep of boo in rawhide.  I say that we
get things fixed to at least how they are on F-8 and then worry about fixing
this issue.
Comment 3 Alex Lancaster 2008-04-08 20:53:48 EDT
Actually the build is:

http://koji.fedoraproject.org/koji/buildinfo?buildID=45460

Looking at:

http://koji.fedoraproject.org/koji/rpminfo?rpmID=524072

it seems it still provides:

mono(ICSharpCode.SharpCvsLib) = 0.36.4902.7334
mono(ICSharpCode.SharpCvsLib.Console) = 0.36.4902.7334
mono(ICSharpCode.SharpZipLib) = 0.84.0.0

but so does the version in F-7/F-8:

http://koji.fedoraproject.org/koji/rpminfo?rpmID=47700
Comment 4 Toshio Ernie Kuratomi 2008-04-08 23:45:42 EDT
Ugh.  If I'm looking at the cvs history right, this has never been right.  This
package should never have passed review. :-(

This is a potential security risk since we're using many libraries which will
stay at the same version even if a security hole is found.  This is exacerbated
since we also seem to be stuck on an older version of nant because of the boo
and other rebuild problems.  So even if upstream nant is proactive about fixing
problems with the included libraries we're still in trouble because we aren't
ready to upgrade to it.
Comment 5 David Nielsen 2008-04-09 04:53:55 EDT
Nant predates the review process and still has not undergone the merge review so
far as I know. However we will be happy to recieve one and a patch for this.
Comment 6 Alex Lancaster 2008-04-09 08:44:56 EDT
I think this is serious and it needs to be fixed soon, but it shouldn't block the
current nant/boo update.  Because:

1. it isn't any worse that the nant that is currently tagged f9-final;
   (i.e. it's not introducing any new bogus provides) and,

2. it fixes the boo broken dep

So in summary I think this problem shouldn't hold back tagging these
packages for inclusion in f9-final.
Comment 7 Toshio Ernie Kuratomi 2008-04-09 12:58:09 EDT
The review was here::
  https://bugzilla.redhat.com/show_bug.cgi?id=193957

This feels dangerous to me since it touches a build tool and a compromised build
tool has the potential to compromise build tools for the rest of time. (There's
a classic ACM article on this  by Ken Thompson

FWIW, I agree that it's not a regression.  So if the danger of having the
non-built from source library is great enough to block the update, it's also
great enough to remove nant from the download repos (and anything that Requires it.)

I'm working on a list of problematic libraries in nant now.
Comment 8 Toshio Ernie Kuratomi 2008-04-09 14:03:23 EDT
= Not in Fedora =
mono/1.0/NDoc.ExtendedUI.dll
mono/1.0/NDoc.Core.dll
mono/1.0/NDoc.Documenter.Msdn.dll
mono/2.0/NDoc.ExtendedUI.dll
mono/2.0/NDoc.Core.dll
mono/2.0/NDoc.Documenter.Msdn.dll
net/1.1/NDoc.Core.dll
net/1.1/NDoc.Documenter.Msdn.dll
net/1.0/NDoc.ExtendedUI.dll
net/1.1/NDoc.ExtendedUI.dll
net/1.0/NDoc.Core.dll
net/1.0/NDoc.Documenter.Msdn.dll
net/2.0/NDoc.ExtendedUI.dll
net/2.0/NDoc.Core.dll
net/2.0/NDoc.Documenter.Msdn.dll

I'm guessing these come from here: http://ndoc.sourceforge.net/

scvs.exe
ICSharpCode.SharpCvsLib.Console.dll
ICSharpCode.SharpCvsLib.dll

I'm guessing these come from here: http://sourceforge.net/projects/sharpcvslib

NUnitCore.dll

This is associated with NUnit somehow but I'm not sure why it isn't being built
by our package.

= mono-nunit =
mono/1.0/nunit.util.dll
mono/2.0/nunit.util.dll
net/1.1/nunit.util.dll
net/1.0/nunit.util.dll
net/2.0/nunit.util.dll

&& monodevelop? -- probably a problem in monodevelop as well.
mono/1.0/nunit.framework.dll
mono/1.0/nunit.core.dll
mono/2.0/nunit.framework.dll
mono/2.0/nunit.core.dll
net/1.1/nunit.framework.dll
net/1.1/nunit.core.dll
net/1.0/nunit.framework.dll
net/1.0/nunit.core.dll
net/2.0/nunit.framework.dll
net/2.0/nunit.core.dll

= log4net =
log4net.dll

= mono-core =
ICSharpCode.SharpZipLib.dll
Comment 9 Toshio Ernie Kuratomi 2008-04-09 14:06:45 EDT
So to fix this 100% we need at least two new mono packages in Fedora.  Getting
rid of the false dependencies ought to be possible by selectively removing the
.dlls that are already in other packages (although I don't know whether nant
will need patching to build against the system libraries or not.)
Comment 10 David Nielsen 2008-04-09 14:20:06 EDT
I am already getting the "I don't want to maintain nant ever" feeling at the
mention of such a patch. Upstream is veery infrequently active it seems to me,
and I thus doubt such a patch would be accepted.. carrying it and rediffing for
every release seems far more dangerous than having some static libraries.

We can manage the latter but adding a maintainer burden like this would severely
limit the amount of people interested in keeping nant running on Fedora from far
to few, to none at all. 

I would consult upstream first before taking the machete to the Nant source tree.
Comment 11 Toshio Ernie Kuratomi 2008-04-09 14:52:31 EDT
If that's the case, then nant needs to go.  nant is doing the following things
wrong:

1) Shipping precompiled binaries.
  1a) Those binaries don't even have source in the upstream tarball
2) Duplicating libraries shipped by different upstreams

These things have to be fixed.  There is probably some leeway to fix #2 in the
future but fixing #1 really needs to happen ASAP.

If upstream is not active, then the problems that can arise with #2 are
exacerbated.  (ie: if a security problem crops up with a library shipped with
nant then there's no upstream to catch the problem or fix it, only the distro
maintainer.)
Comment 12 Alex Lancaster 2008-04-14 11:20:20 EDT
Fixed now with spot's latest build, and tagged f9-final:

http://koji.fedoraproject.org/koji/buildinfo?buildID=46066

Closing bug.

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