From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: The openjade and opensp packages are currently packaged together, which makes it difficult to upgrade one and not the other. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.rpm -ql openjade 2. 3. Actual Results: list of files includes both openjade and opensp Additional info: GnuCash is currently working on a new version which will be the first free software program to support OFX. This is done by the use of an external generic library called libofx. This library requires the use of a newer version of OpenSP than is currently included with Openjade. Currently in order to upgrade OpenSP users have to build and install from source rather than making a separate rpm to upgrade. Please consider changing this to facilitate upgrading OpenSP
Notably, OpenSP 1.5 contains a security fix that is essential for being able to safely use onsgmls with untrusted inputs in a CGI, or similar, environment. That is, of course, in addition to the other advantages to being able to upgrade OpenSP to 1.5 (such as it's much improved XML and SGML support) and the fact that OpenJade and OpenSP are also being split upstream (OpenJade 1.3.2 is capable of being linked with an external libosp).
What security fix? Following the thread on the openjade mailing list, it looks to me like packaging up opensp 1.5 is NOT something we want to be dealing with right now.
Versions of OpenSP prior to 1.5 suffer from a potential file disclosure vulnerability when fed untrusted input. Since SGML allows references to external entities that are automatically expanded, you could construct an input file such that you could gain access to all files accessible to the user OpenSP is running as. OpenSP 1.5 introduced the "-R" switch to restrict file reading to safe directories (typically "/usr/share/sgml/" or similar). Note that this is _only_ an issue if OpenSP is used in an environment such as CGI where it accepts untrusted input _and_ deliver the resulting ESIS and/or error output to a different user then the one OpenSP is running under. Typical application that behaves in this fashion is a CGI gateway to onsgmls such as the WDG or W3C HTML Validators.
Okay, this is just a missing security feature rather than a security bug. We'll look at openjade 1.3.2 next time round.
So I note that Phoebe is released just before Xmas, OpenSP 1.5 is released beginning of november, openjade 1.3.2 released in october. I'm not sure what the problem is with OpenSP 1.5 packaging, all I could see in the mailing list after the release was a problem with VPATH builds which was suggested to be fixed by a small patch submitted. Can you give me some more information about what you see the problem with splitting these packages off from each other is here Tim? Note that the request I made was not even that Redhat upgrade their package, but rather that they split the rpm so that there are separated openjade and opensp packages to facilitate upgrades. Please consider this for the release of 8.1, it will make support of libofx a lot easier for the GnuCash team if we can tell users they just need to upgrade OpenSP that comes with Redhat rather than do a build of a tarball to get the required library
This is too late for the upcoming release, which is why it is deferred. We'll get to it next time hopefully.
The current rawhide openjade package contains the latest OpenSP.
The Summary refers to splitting OpenJade and OpenSP to make it possible to upgrade the two independantly of eachother. While OpenJade needs OpenSP to function -- which I guess is the main reason for including OpenSP at all -- OpenSP has no such dependancy on OpenJade. i.e. OpenSP in itself is interesting for some applications -- e.g. the W3C Markup Validator and, apparently, GnuCash -- and it would be a net win for these if OpenSP was independantly upgradeable. Perhaps it would be possible to leave this bug open, or possibly DEFERRED, so it can be reviewed at some later date?
Sure.
(removing security priority)
If it's too late to get a split version into the next RHL version, could you at least consider making the openjade package "Provides: opensp = 1.5"? That would help cross-distribution packaging of applications that need OpenSP, eg. the W3C Markup Validator at <http://validator.w3.org/>.
This appears to be a duplicate of Bug #60409.
*** This bug has been marked as a duplicate of 60409 ***