Discussion:
apitrace, bundled libbacktrace
(too old to reply)
Sandro Mani
2014-05-13 16:56:40 UTC
Permalink
Hi,

apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.

Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?

Thanks,
Sandro
Jakub Jelinek
2014-05-13 17:02:22 UTC
Permalink
Post by Sandro Mani
apitrace 5.0 bundles libbacktrace, which looks like is living within
the gcc sources. libbacktrace is not build as a shared library from
the gcc sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it
in a corresponding package?
No.
Post by Sandro Mani
Or should I rather go for a bundling exception request?
I'd say so.

Jakub
Sandro Mani
2014-05-13 17:08:25 UTC
Permalink
Post by Jakub Jelinek
Post by Sandro Mani
apitrace 5.0 bundles libbacktrace, which looks like is living within
the gcc sources. libbacktrace is not build as a shared library from
the gcc sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it
in a corresponding package?
No.
Post by Sandro Mani
Or should I rather go for a bundling exception request?
I'd say so.
Ok thanks. While I'm at it, looks like apitrace is using GLIBC_PRIVATE
symbols... How can I find out which are the offending symbols?

Thanks,
Sandro
Sandro Mani
2014-05-13 22:09:26 UTC
Permalink
Post by Sandro Mani
Post by Jakub Jelinek
Post by Sandro Mani
apitrace 5.0 bundles libbacktrace, which looks like is living within
the gcc sources. libbacktrace is not build as a shared library from
the gcc sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it
in a corresponding package?
No.
Post by Sandro Mani
Or should I rather go for a bundling exception request?
I'd say so.
Ok thanks. While I'm at it, looks like apitrace is using GLIBC_PRIVATE
symbols... How can I find out which are the offending symbols?
Never mind...

$ readelf -Ws glxtrace.so | grep PRIVATE
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
__libc_dlsym at GLIBC_PRIVATE (2)
Eric Smith
2017-12-17 20:32:11 UTC
Permalink
Post by Jakub Jelinek
Post by Sandro Mani
apitrace 5.0 bundles libbacktrace, which looks like is living within
the gcc sources. libbacktrace is not build as a shared library from
the gcc sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it
in a corresponding package?
No.
Post by Sandro Mani
Or should I rather go for a bundling exception request?
I'd say so.
ghdl, a VHDL compiler, can produce better run-time diagnostics if
libbacktrace is available:

https://sourceforge.net/p/ghdl-updates/tickets/54/

Is there (still) a good reason why gcc can't make libbacktrace available as
a shared library?

Thanks,
Eric

Adam Williamson
2014-06-12 21:42:15 UTC
Permalink
Post by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?
So in writing a reply to this, I noticed the guidelines around this are
actually fairly unclear and subject to interpretation.

The section on this topic from
https://fedoraproject.org/wiki/Packaging:Guidelines reads:

"Duplication of system libraries

A package should not include or build against a local copy of a library
that exists on a system. The package should be patched to use the system
libraries. This prevents old bugs and security holes from living on
after the core system libraries have been fixed.

In this RPM packaging context, the definition of the term 'library'
includes: compiled third party source code resulting in shared or static
linkable files, interpreted third party source code such as Python, PHP
and others. At this time JavaScript intended to be served to a web
browser on another computer is specifically exempted from this but this
will likely change in the future.

Note that for C and C++ there's only one "system" in Fedora but for some
other languages we have parallel stacks. For instance, python, python3,
jython, and pypy are all implementations of the python language but they
are separate interpreters with slightly different implementations of the
language. Each stack is considered its own "system" and can each contain
its own copy of a library."

The thing that is particularly unclear there is the definition of "a
system" (as in "a library that exists on a system"). The following
paragraphs seem to imply that Fedora's stacks for languages/frameworks
that implement some kind of shared library functionality are to be
understood as "systems" in that context. This is still not made
*entirely* clear, though, really.

The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
has all sorts of rationale and process stuff, but still no clear
definition of precisely what it is that constitutes a "bundled library".

Even more confusingly,
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries
seems to have a rather different definition from that given on
Packaging:Guidelines. It reads:

"(bundled libraries being defined as libraries which exist and are
mantained independently, whether or not they are packaged separately for
Fedora)"

to me, that seems fundamentally different from the definition that is
somewhat unclearly implied on the Packaging:Guidelines page.

Has this been considered before? Is there a superior definition
somewhere, or an accepted interpretation which is consistent with both
pages?

Do we in fact need a section in Packaging:Guidelines and then two
separate 'subsidiary' pages all on the topic of bundled libraries? Would
it make more sense to combine all the details onto a single subsidiary
page and have Packaging:Guidelines just have a very short sort of
'summary' and a link to that one subsidiary page? Would that reduce the
likelihood of confusion?

Thanks!

I've seen several cases in the Real World where 'bundled' libraries that
are not a part of the Fedora repositories were considered to be OK under
the policy, which is a possible interpretation of the policy as given on
Packaging:Guidelines, but doesn't really seem to be a possible
interpretation of the policy as given on
Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states
"whether or not they are packaged separately for Fedora"). This could
have considerable implementations for webapps if it were interpreted
strictly, I think.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Pavel Alexeev
2014-08-19 11:19:56 UTC
Permalink
Post by Adam Williamson
Post by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
request?
So in writing a reply to this, I noticed the guidelines around this are
actually fairly unclear and subject to interpretation.
The section on this topic from
"Duplication of system libraries
A package should not include or build against a local copy of a library
that exists on a system. The package should be patched to use the system
libraries. This prevents old bugs and security holes from living on
after the core system libraries have been fixed.
In this RPM packaging context, the definition of the term 'library'
includes: compiled third party source code resulting in shared or static
linkable files, interpreted third party source code such as Python, PHP
and others. At this time JavaScript intended to be served to a web
browser on another computer is specifically exempted from this but this
will likely change in the future.
Note that for C and C++ there's only one "system" in Fedora but for some
other languages we have parallel stacks. For instance, python, python3,
jython, and pypy are all implementations of the python language but they
are separate interpreters with slightly different implementations of the
language. Each stack is considered its own "system" and can each contain
its own copy of a library."
The thing that is particularly unclear there is the definition of "a
system" (as in "a library that exists on a system"). The following
paragraphs seem to imply that Fedora's stacks for languages/frameworks
that implement some kind of shared library functionality are to be
understood as "systems" in that context. This is still not made
*entirely* clear, though, really.
The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
has all sorts of rationale and process stuff, but still no clear
definition of precisely what it is that constitutes a "bundled library".
Even more confusingly,
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries
seems to have a rather different definition from that given on
"(bundled libraries being defined as libraries which exist and are
mantained independently, whether or not they are packaged separately for
Fedora)"
to me, that seems fundamentally different from the definition that is
somewhat unclearly implied on the Packaging:Guidelines page.
Has this been considered before? Is there a superior definition
somewhere, or an accepted interpretation which is consistent with both
pages?
Do we in fact need a section in Packaging:Guidelines and then two
separate 'subsidiary' pages all on the topic of bundled libraries? Would
it make more sense to combine all the details onto a single subsidiary
page and have Packaging:Guidelines just have a very short sort of
'summary' and a link to that one subsidiary page? Would that reduce the
likelihood of confusion?
Thanks!
I've seen several cases in the Real World where 'bundled' libraries that
are not a part of the Fedora repositories were considered to be OK under
the policy, which is a possible interpretation of the policy as given on
Packaging:Guidelines, but doesn't really seem to be a possible
interpretation of the policy as given on
Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states
"whether or not they are packaged separately for Fedora"). This could
have considerable implementations for webapps if it were interpreted
strictly, I think.
Sorry for the old thread.
But it is very interesting question to clearly determine "bundled
library" to which returning happened again and again.
Does it hang again now or something indeed changed?
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: Hubbitus at jabber.ru
Adam Williamson
2015-01-08 01:39:02 UTC
Permalink
Post by Pavel Alexeev
Post by Adam Williamson
Post by Sandro Mani
Hi,
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from
the gcc sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and
ship it in a corresponding package? Or should I rather go for a
bundling exception request?
So in writing a reply to this, I noticed the guidelines around
this are actually fairly unclear and subject to interpretation.
The section on this topic from
"Duplication of system libraries
A package should not include or build against a local copy of a
library that exists on a system. The package should be patched to
use the system libraries. This prevents old bugs and security
holes from living on after the core system libraries have been
fixed.
In this RPM packaging context, the definition of the term
'library' includes: compiled third party source code resulting in
shared or static linkable files, interpreted third party source
code such as Python, PHP and others. At this time JavaScript
intended to be served to a web browser on another computer is
specifically exempted from this but this will likely change in the
future.
Note that for C and C++ there's only one "system" in Fedora but
for some other languages we have parallel stacks. For instance,
python, python3, jython, and pypy are all implementations of the
python language but they are separate interpreters with slightly
different implementations of the language. Each stack is
considered its own "system" and can each contain its own copy of a
library."
*entirely* clear, though, really.
The page https://fedoraproject.org/wiki/Packaging
:No_Bundled_Libraries has all sorts of rationale and process
stuff, but still no clear definition of precisely what it is that
constitutes a "bundled library".
Even more confusingly,
https://fedoraproject.org/wiki/Packaging
:Treatment_Of_Bundled_Libraries seems to have a rather different
"(bundled libraries being defined as libraries which exist and are
mantained independently, whether or not they are packaged
separately for Fedora)"
to me, that seems fundamentally different from the definition that
is somewhat unclearly implied on the Packaging:Guidelines page.
Has this been considered before? Is there a superior definition
somewhere, or an accepted interpretation which is consistent with
both pages?
Do we in fact need a section in Packaging:Guidelines and then two
separate 'subsidiary' pages all on the topic of bundled libraries?
Would it make more sense to combine all the details onto a single
subsidiary page and have Packaging:Guidelines just have a very
short sort of 'summary' and a link to that one subsidiary page?
Would that reduce the likelihood of confusion?
Thanks!
I've seen several cases in the Real World where 'bundled'
libraries that are not a part of the Fedora repositories were
considered to be OK under the policy, which is a possible
interpretation of the policy as given on Packaging:Guidelines, but
doesn't really seem to be a possible interpretation of the policy
as given on Packaging:Treatment_Of_Bundled_Libraries (as it
explicitly states "whether or not they are packaged separately for
Fedora"). This could have considerable implementations for webapps
if it were interpreted strictly, I think.
Sorry for the old thread.
But it is very interesting question to clearly determine "bundled
library" to which returning happened again and again.
Does it hang again now or something indeed changed?
Yeah, I'm still interested in other people's thoughts on this, I
rather expected it to get more traction when first posted. I guess
I'll try one more bump (this one) and if still no-one bites, we can
file an FPC ticket, perhaps.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-cond
Richard Shaw
2015-01-08 03:36:33 UTC
Permalink
On Tue, 2014-08-19 at 15:19 +0400, Pavel Alexeev wrote:> Sorry for the old
thread.
Post by Pavel Alexeev
But it is very interesting question to clearly determine "bundled
library" to which returning happened again and again.
Does it hang again now or something indeed changed?
Yeah, I'm still interested in other people's thoughts on this, I
rather expected it to get more traction when first posted. I guess
I'll try one more bump (this one) and if still no-one bites, we can
file an FPC ticket, perhaps.
I don't think it's possible to get a perfectly blank-and-white definition
of what constitutes a bundled library. Of course there's always the obvious
cases where a project copies one in to their source tree more-or-less
verbatim.

That being said I think one thing that helps make it more clear is to look
at the guidelines in reverse, meaning why don't we allow/like bundled
libraries? Overall the primary drivers from the wiki page seems to be
security, so when dealing with the "grey area" perhaps looking at things
from a security perspective may help.

In the specific case I ran into one of the package suites I've been working
on technically bundles a modified copy of xmlrpcpp. However, it is quite
modified, upstream is dead, it's not already in Fedora, and the author I'm
working with only uses it for communication between his suite of programs
and has no intention of offering it as a separate library.

So again, from a security point of view:
- It's not in Fedora so there's no code/library duplication
- Upstream is dead so there's no one to send the code to upstream
- It's not going to get used by another package in Fedora because it's not
offered as a separate library.

The final determination during the review was that it was far enough into
the grey area to not be considered a bundled library and practically that
makes sense when you think about the requirement to add a virtual provide
to the package, in my case there's no upstream "name" to use due to the
amount of modification nor a specific version I could tie it to.

Don't know if this helps any with the discussion but just sharing my
experience dealing with package reviews.

Thanks,
Richard
Matěj Cepl
2015-01-08 07:55:07 UTC
Permalink
Post by Richard Shaw
In the specific case I ran into one of the package suites I've been working
on technically bundles a modified copy of xmlrpcpp. However, it is quite
modified, upstream is dead, it's not already in Fedora, and the author I'm
working with only uses it for communication between his suite of programs
and has no intention of offering it as a separate library.
Hi,

I think in the end it is not that much matter of definition as
where the buck stops. I believe there are these questions which
need to be answered:

1) Will you be able to identify a security concern? Way more
simple for the independent well-known library, then for some
directory down in your project. Even more difficult for
hundreds of bundled libraries scattered all over the system
(the famous Debian libz issue).
2) Who will fix the issue? Because if there is not well
maintained upstream for the library, or if the maintainer of
your upstream is not willing or able to fix any issue which
comes her way, then there is only person who is responsible
for fixing any such issue, you.

Best,

Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

"Push to test." (click) "Release to detonate..."
-- from a bugzilla quip list
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Co
Loading...