#515 Bundling determination and exception request
Closed: Fixed None Opened 4 years ago by hobbes1069.

I am attempting to get the rest of the w1hkj suite of ham radio related programs into Fedora. The main program, fldigi, has been in Fedora for some time.

During the review a possible bundled library was discovered:
https://bugzilla.redhat.com/show_bug.cgi?id=1060817

Also all of his programs use this same library for communications between them, including fldigi, flrig, flamp, etc.

The library is a copy/fork of this project:
http://xmlrpcpp.sourceforge.net/

Which does not appear to be active since around 2003 and is not currently in Fedora. The version in the flxxx suite of programs is heavily modified and upstream does not wish to offer it as a separate library.

From a security point of view, I don't think there's a large reason to be concerned as these programs are only of interest to ham radio operators.


So do all of those programs use the same library code? Would like to see a breakdown of that. Would also like to see the requested list of bundled files and links to them. See https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

Since you're claiming there's no security concerns here, can we assume that this library never comes into contact with untrusted data? Does the maintainer update all of the various programs when something changes in this library? (Seems horribly inefficient to me, but it's his time to spend.)

I'm thinking maybe "too small to care", but then only if there's a good answer to "why don't all of those just link to the same library?" But without seeing the files it's tough to tell.

Replying to [comment:1 tibbs]:

So do all of those programs use the same library code? Would like to see a breakdown of that. Would also like to see the requested list of bundled files and links to them. See https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

Yes, the same code is used.
http://sourceforge.net/p/fldigi/fldigi/ci/master/tree/src/xmlrpcpp/

Since you're claiming there's no security concerns here, can we assume that this library never comes into contact with untrusted data? Does the maintainer update all of the various programs when something changes in this library? (Seems horribly inefficient to me, but it's his time to spend.)

Not that there's no security concern, just that it's very small.

I'm thinking maybe "too small to care", but then only if there's a good answer to "why don't all of those just link to the same library?" But without seeing the files it's tough to tell.

He doesn't want to support it as a separate library because if he separates it out then it would be directly available for other people/projects to use. Even if he built it in a separate library within one of the projects (probably fldigi) then you would have to have that installed in order to install any of the other projects. Obviously we could handle that on this end through a sub-package but many of his users build from source themselves.

Can we get an estimate of lines of code that are bundled ... also you say these programs speak to each other via. xmlrpc, is that only trusted communication then (nothing from a different privilage level could ever directly/indirectly use those communication channels)?

Here's the answer to the first part:
{{{
$ diff -aur xmlrpc++0.7/src/ xmlrpcpp/ | diffstat
xmlrpc++0.7/src//Doxyfile |only
xmlrpcpp//.deps |only
xmlrpcpp//.dirstamp |only
xmlrpcpp//XmlRpcMutex.cpp |only
xmlrpcpp//XmlRpcMutex.h |only
xmlrpcpp//XmlRpcThread.cpp |only
xmlrpcpp//XmlRpcThread.h |only
xmlrpcpp//XmlRpcThreadedServer.cpp |only
xmlrpcpp//XmlRpcThreadedServer.h |only
xmlrpcpp/XmlRpc.h | 48 ++--
xmlrpcpp/XmlRpcClient.cpp | 242 ++++++++++++++++++-----
xmlrpcpp/XmlRpcClient.h | 74 +++++--
xmlrpcpp/XmlRpcDispatch.cpp | 223 +++++++++++++++------
xmlrpcpp/XmlRpcDispatch.h | 46 +++-
xmlrpcpp/XmlRpcException.h | 26 ++
xmlrpcpp/XmlRpcServer.cpp | 264 ++++++++++++++++++++++++-
xmlrpcpp/XmlRpcServer.h | 101 ++++++++-
xmlrpcpp/XmlRpcServerConnection.cpp | 251 +++++-------------------
xmlrpcpp/XmlRpcServerConnection.h | 87 ++++----
xmlrpcpp/XmlRpcServerMethod.cpp | 24 ++
xmlrpcpp/XmlRpcServerMethod.h | 30 ++
xmlrpcpp/XmlRpcSocket.cpp | 207 +++++++++-----------
xmlrpcpp/XmlRpcSocket.h | 77 +++++--
xmlrpcpp/XmlRpcSource.cpp | 202 +++++++++++++++++++
xmlrpcpp/XmlRpcSource.h | 65 +++++-
xmlrpcpp/XmlRpcUtil.cpp | 202 ++++++++++++++-----
xmlrpcpp/XmlRpcUtil.h | 60 ++++-
xmlrpcpp/XmlRpcValue.cpp | 371 ++++++++++++++++++++++--------------
xmlrpcpp/XmlRpcValue.h | 180 +++++++++++++++--
xmlrpcpp/base64.h | 27 ++
30 files changed, 1974 insertions(+), 833 deletions(-)
}}}

I don't think it only permits "trusted" communication. I believe it also allows other applications to communicate and give commands.

We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-26/fpc.2015-03-26-16.00.txt):

  • 515 Bundling determination and exception request (geppetto,


    16:06:55)
  • LINK: https://fedorahosted.org/fpc/ticket/515 (geppetto, 16:07:01)
  • ACTION: Can you try to create a static library that all the
    components use (geppetto, 16:37:56)

To better frame my arguments below let me say I'm not a fan of bundling and of the numerous packages I maintain this is my first time to request an exception.

I'm not an autotools expert but I'm sure it's possible to create a static library and link to it, but other than make sure all the projects are using the exact same copy of the code I don't see much benefit. At a high level I understand the thought here but I have some concerns...

We seem to be working on solutions without answering the first question, is this considered a bundled library? I agree that it's not ideal to have the same code in all the projects but it's a practical approach for a very small upstream (one major contributor, 2 others on a somewhat regular basis).

From the Fedora wiki:
"...bundled libraries being defined as libraries which exist and are maintained independently, whether or not they are packaged separately for Fedora..."

  • If the determination is that it is not a fork, conical upstream is dead. (Last release some time in 2003) so I would argue that it is not maintained.
  • If it is a fork, the current upstream does not, nor does it intend to provide the library separately.

Assuming it is determined that it is a bundled library I still have some concerns:
- Which package would provide the -devel that all the others would use?
- Upstream doesn't want this available as a separate library because it would imply that other projects could/should start using it for other purposes (and have expectations that go along with that). If we choose to do this then would we not be signing up to be the "upstream" for support?
- Considering these programs would only be used by people who are both ham radio operators and Fedora users, I would think this would fall under the "too small to care" umbrella as an exception.

We discussed this at today's meeting (https://lists.fedoraproject.org/pipermail/packaging/2015-April/010561.html):

  • 515 Bundling determination and exception request (geppetto,


    16:49:16)
  • ACTION: Create a static. lib., decide among yourself who will own
    it. Size exception is based on the bundling size (and xmlrpcpp is
    big). (geppetto, 16:58:58)

Ok, obviously the decision is theirs to make but I would have appreciated at least some sort of answer to my questions or rational, none of which was given.

I have confirmed that the bundled libraries are not identical within the projects so a single static library will not work without modification.

He has tried moving back to the ancient xmlrpc++ at sourceforge with some success except for the main program, fldigi, which is already in Fedora.

I have asked if he's willing to formally fork the project and I'll package it as a shared library.

Upstream has developed an independent library which works for the whole suite of program and I have submitted a review request for it:

https://bugzilla.redhat.com/show_bug.cgi?id=1214467

I will post to devel and see if someone can quickly review this. New versions of each of the programs are going through testing and the next release should be able to be built against this library.

Metadata Update from @hobbes1069:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata