Description of problem: While looking into what it would take to close out all of the libiberty CVE problems I came across the fact that the crash package is bundling gdb. This should either be patched to use the system gdb or a bundling exception granted by the FPC. Note that if you're going down the bundling exception route that gdb already has some bundled library exceptions that may not extend to a third party bundling their code and also that gdb has a bundled library exception (for libreadline) that was rejected in favour of using the system libreadline. This will likely mean that even if you were granted an exception to bundle gdb you may have more work to do in order to unbundle those other packages or be granted exceptions to bundle those as well. Version-Release number of selected component (if applicable): crash-0:7.0.3-1.fc21.x86_64
(In reply to Toshio Ernie Kuratomi from comment #0) > Description of problem: > > While looking into what it would take to close out all of the libiberty CVE > problems I came across the fact that the crash package is bundling gdb. > > This should either be patched to use the system gdb or a bundling exception > granted by the FPC. The crash utility cannot "use the system gdb"; it can almost be considered as a huge wrapper around a significantly patched gdb embedded within it. > > Note that if you're going down the bundling exception route that gdb already > has some bundled library exceptions that may not extend to a third party > bundling their code and also that gdb has a bundled library exception (for > libreadline) that was rejected in favour of using the system libreadline. > This will likely mean that even if you were granted an exception to bundle > gdb you may have more work to do in order to unbundle those other packages > or be granted exceptions to bundle those as well. I'm not familiar with the concept of bundling exceptions, what the FPC is, the "work to do" to unbundle packages, or what this addition to the crash.spec file actually accomplishes: +Provides: bundled(libiberty) Can you point me to some documentation?
documentation link first: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries The FPC is the Fedora Packaging Committee. Their main function is to work on the Packaging Guidelines that all packages in Fedora follow. As an adjunct to that, they decide whether a package is allowed to bundle another upstream's code, must patch out that behaviour and use a system version, or should be removed from Fedora. The first of those outcomes is known as a bundling exception. It's an FPC verdict that the package in question is allowed to bundle the other upstream's code. The addition to the crash spec file that I made is there to allow people to track down what packages are bundling another piece of code. They are used, for instance, when a CVE in the bundled code is found and we then have to track down all the other packages that are bundling it and fix them. If you are granted a bundling exception for gdb, you would need to add a similar virtual provide that allowed people to track the fact that the crash package is bundling gdb's code. We would likely also need to grant you permission to use bundled(binutils) (as it seems that crash isn't being produced by sourceware.org, which is the bundled library exception that allows gdb to use bundled(binutils). And we'd also have to decide if you were allowed to bundle libreadline or must use the system version of that (the Fedora gdb uses the system version of readline.) I see that the bundling issues were brought up in the merge review request but you never finished that process so the issues have lingered.
It's more like crash is a forked gdb which periodically integrates gdb code. I really don't think this has anything to do with bundling. If there was a security bug against gdb then it would have to be cloned to crash (but surely that happens already as this situation is well-known and has been around for years). If it was up to me I'd close this bug as NOTABUG.
You make a poor assumption there. The bundled library exceptions (with their virtual provides) is how fedora tracks bundling. Without that information there is no way that people who are not involved with crash itself would know that there's a relationship between gdb and the crash package.
Advancing the position that this is a fork is a good idea. We do allow forks as opposed to bundling. However, there are underlying reasons that we consider forks to be a valid reason and bundling to not be okay... The crash case would have to be evaluated to see if the specifics here actually satisfy those underlying reasons (most forks don't ship the whole bundled tarball from the upstream and then apply a patch to that as part of the build process, for instance. The build process for a forked gdb should allow the package maintainers to influence the build of the forked gdb via configure switches, etc and it's not immediately obvious whether that's the case here.) Closing a bundling violation as NOTABUG is not a great idea... it just means that the problem will escalate to FESCo and from there back to FPC with everyone involved thinking that you are a combative and uncooperative maintainer rather than someone they can work with to craft a solution.
OK, I agree on that point. A similar situation would be the mingw-* packages, where security errata get cloned for (eg) pixman and mingw-pixman. Our security team are aware of this and do it automatically. I don't think the bundled libraries policy applies to either of these situations, since (a) it's not a library, (b) it's not bundled in the ordinary sense of that word and (c) if you read the policy page it's not obvious it was intended to apply to these cases. Cross-compilation is a special case we have handled ad-hoc. Crash is a straight fork of gdb with many extra features and a completely different use case -- when I looked at the crash code it was obvious (to me) there was no chance of any meaningful merge happening in the future. (Perhaps Dave will disagree) (This is probably not a good place to continue this discussion however ... perhaps on the devel or packaging list)
> The build process for a forked gdb should allow the package maintainers > to influence the build of the forked gdb via configure switches, etc and > it's not immediately obvious whether that's the case here. I don't follow... > Crash is a straight fork of gdb with many extra features and a > completely different use case -- when I looked at the crash code > it was obvious (to me) there was no chance of any meaningful > merge happening in the future. (Perhaps Dave will disagree) If you mean a "meaningful merge" with the upstream gdb, then no, that will never happen. As you've stated, the crash utility can be considered a fork of gdb, where the user interface has been redirected to the crash sources by hooks provided by the gdb code. The embedded gdb is invoked as "gdb vmlinux", and for the most part used for accessing debuginfo information from the vmlinux file, and is not aware of any core file. I just don't see anything that embodies a need to "craft a solution".
Sure. So open the FPC exception ticket and get an exception granted along with the virtual provides that can be used to track your package's use of the bundled code. I'm just letting you know that when you do, you should probably be thinking about what the FPC is going to be evaluating your package on so that you can have answers that show that this package builds on the precedents we have already set for granting exceptions rather than being placed in the category of precedents we have set where exceptions were rejected.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This still applies even to current rawhide. The guidelines have changed in the meantime, so please at least specify the bundled gdb version in: Provides: bundled(gdb) = x.x
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
- Fedora Rawhide build: crash-7.1.6-1.fc26 (10/14/16) http://koji.fedoraproject.org/koji/buildinfo?buildID=810068
Pushed to fc25 stable: Information for build crash-7.1.7-1.fc25 https://koji.fedoraproject.org/koji/buildinfo?buildID=823252 FEDORA-2016-b7c1bcbc18 https://bodhi.fedoraproject.org/updates/FEDORA-2016-b7c1bcbc18