Mono Package audit

Thu Apr 10 19:06:29 UTC 2008

David Nielsen wrote:
> 
> 
> 2008/4/10, Toshio Kuratomi <a.badger at gmail.com <mailto:a.badger at gmail.com>>:
> 
>     David Nielsen wrote:
> 
> 
>         I'll just comment on the ones I own:
> 
> 
>            .. _banshee: Boo.dll files are in an Extras/Boo directory.
>          May be
>            able to
>                        disable at buildtime.  Note in spec that Boo does not
>            build on ppc
> 
> 
>         Actually Nant does not build on ppc (well 0.86-beta 1 does but
>         look what happened when we tried that), no Nant means no ppc for
>         Boo. Regardless when Banshee 1.0 can be rolled out this should
>         not be an issue anymore as one of the goals as been to remove
>         all those bundled wonders. I am inclined to think the best
>         option is waiting and letting the problem solve itself upstream.
>         Upstream is very friendly and on a mission to destroy these anyways.
> 
>     I'm definitely okay with this for libraries which are simply bundled
>     (ie: the package is shipping the source for an external library and
>     is compiling that before installing it.)  It makes sense that we
>     wait for an active and friendly upstream to complete changes they've
>     already planned to do something we want.  This appears to be the
>     case for the sources in banshee-0.13.2/ext and some of the libraries
>     in banshee-0.13.2/src/Extras.
> 
>     In the Boo case, though, there's a set of precompiled Boo libraries
>     in banshee-0.13.2/src/Extras/Boo/ which are not accompanied by any
>     source.  This is more problematic as we have no way to audit those
>     precompiled bits.  Are they Boo?  Are they a trojaned Boo?  Are they
>     secret government plans to bring about Armageddon masquerading as a
>     .dll? Unless you can read CIL byte code, there's no way of knowing.
> 
> 
> Here good sir, a tinfoil hat to complete your attire.
> 
Let me ask you this, then, why do we have::

http://fedoraproject.org/wiki/Packaging/Guidelines#SourceRequirementExceptions

at all then?  Please give the Packaging Committee a draft with rationale 
for removing that.  After all, if it is overly paranoid to apply thatto 
mono packages it is overly paranoid to apply that rule to any package.

> The source tree for Banshee-1 (current SVN) the only interesting Banshee 
> as it is the only one being worked on, contains no precompiled bundles 
> what so ever. Even the banshee in F9 uses system libraries, except boo 
> on account of nant not allowing us boo on ppc. But the focus should be 
> on getting 1.0 into all maintained Fedora releases, it is the only 
> version upstream takes bugs against and it is a substantial improvement 
> on all levels.
> 
Then why isn't it in Fedora?  The package in Fedora ATM is in violation 
of the Fedora Packaging Guidelines that are currently written.  Not only 
that, it is in violation of a Guideline that bears on security.  That 
binary package should not be in Fedora.  If Banshee-1 fixes that problem 
and we are not competent enough to fix the issue through a backport or 
removing the specific feature that causes the issue at the downstream 
level then the package should start using a snapshot.

However, your explanation of the reason we use the prebuilt Boo.dll 
instead of system libraries points out that this is not the case.  If 
nothing else, banshee could depend on the system library and not be 
available for ppc.  This would be a case where security is more 
important than fixing the unable-to-build on a specific platform bug.

> For upstream to stop this behavior we could focus inward as well, they 
> do this because they can't count on libraries being available, the 
> slowness (and rather frightening absolute lack of progress most of the 
> time) of our review process certainly does nothing to help that. We need 
> to do better at this step, then the prebuilt issue will go away without 
> any work. It is my experience that once upstream can count on the 
> libraries being available they will use them. It's not an upstream 
> problem, we are helping to cause it.
> 
banshee, or indeed, mono, is not special in this regard.  Many OSS and 
proprietary projects have to deal with this same issue.  The proper 
thing for an upstream proprietary product to do is to create build 
scripts that detect whether the platform provides the needed libraries. 
  If not, then the software uses an internal copy.  For an OSS upstream, 
the software should compile the source of an internal copy.  For Fedora 
as a downstream, we need to be adding each third party library to our 
repository and then using the upstream's build scripts to use the system 
libraries instead of what's internal.  This will cause us to do more 
work at times and not be able to get things into our repositories as 
quickly as we'd like at others but it's what we do to meet our goals.

PS: Not that our goals can't change.  Like I say, feel free to propose a 
draft for either of the two problems that apply to banshee:
http://fedoraproject.org/wiki/Packaging/Guidelines#SourceRequirementExceptions
http://fedoraproject.org/wiki/Packaging/Guidelines#SystemLibraryDuplication

Just be sure to include persuasive rationale as this is something that I 
think contravenes the prevailing wisdom so it needs to have a lot of 
firm support.

-Toshio

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080410/56597d80/attachment.sig>