Upporting status
I've ported essentially all code-related changes and a decent amount of the web site changes from the 3.1 branch back up to trunk. At least one of the original security fixes to the branch apparently caused a regression, which I wasn't surprised by. I think there's a separate bug open on that, plus the additional security concerns with the bad casts that needs fixing, so the rest is "new work" to get a release done, please at least one new feature setting I will be adding (the disable DTDs option). Hope to get most of this done over the next few weeks at the latest. I haven't pulled any of the old Windows solutions yet, but that's TBD. I'm using the cmake-generated version to actually build and test anything. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2061) Buffer overruns in prolog parsing and error handling
[ https://issues.apache.org/jira/browse/XERCESC-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2061: - Assignee: Scott Cantor > Buffer overruns in prolog parsing and error handling > > > Key: XERCESC-2061 > URL: https://issues.apache.org/jira/browse/XERCESC-2061 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser, Validating Parser (DTD), > Validating Parser (XML Schema) >Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1, 3.1.2 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Blocker > Fix For: 3.2.0, 3.1.3 > > > Vulnerabilities were reported to the project that led to the discovery of > several buffer overflows. > The issue was publically disclosed as CVE-2016-0729 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2046) Crash while parsing malformed documents
[ https://issues.apache.org/jira/browse/XERCESC-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2046: - Assignee: Scott Cantor (was: Boris Kolpackov) > Crash while parsing malformed documents > --- > > Key: XERCESC-2046 > URL: https://issues.apache.org/jira/browse/XERCESC-2046 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Blocker > Fix For: 3.1.2, 3.2.0 > > > A bug was reported that causes the parser to crash on malformed inputs. The > issue was assigned CVE-2015-0252. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2046) Crash while parsing malformed documents
[ https://issues.apache.org/jira/browse/XERCESC-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2046. --- Resolution: Fixed Applied trunk, r1799602. > Crash while parsing malformed documents > --- > > Key: XERCESC-2046 > URL: https://issues.apache.org/jira/browse/XERCESC-2046 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.0.0, 3.1.0, 3.1.1 >Reporter: Scott Cantor >Assignee: Scott Cantor >Priority: Blocker > Fix For: 3.2.0, 3.1.2 > > > A bug was reported that causes the parser to crash on malformed inputs. The > issue was assigned CVE-2015-0252. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2061) Buffer overruns in prolog parsing and error handling
[ https://issues.apache.org/jira/browse/XERCESC-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2061: -- Affects Version/s: 3.0.0 3.0.1 3.1.0 3.1.1 > Buffer overruns in prolog parsing and error handling > > > Key: XERCESC-2061 > URL: https://issues.apache.org/jira/browse/XERCESC-2061 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser, Validating Parser (DTD), > Validating Parser (XML Schema) >Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1, 3.1.2 >Reporter: Scott Cantor >Priority: Blocker > Fix For: 3.2.0, 3.1.3 > > > Vulnerabilities were reported to the project that led to the discovery of > several buffer overflows. > The issue was publically disclosed as CVE-2016-0729 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1800) Xerces-C++ is not 64-bit safe
[ https://issues.apache.org/jira/browse/XERCESC-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059579#comment-16059579 ] Scott Cantor commented on XERCESC-1800: --- If there's any low hanging fruit on this one worth looking at, I can probably carve out a bit of time, but anything requiring deep knowledge of the code's probably out. > Xerces-C++ is not 64-bit safe > - > > Key: XERCESC-1800 > URL: https://issues.apache.org/jira/browse/XERCESC-1800 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.0 >Reporter: Boris Kolpackov >Priority: Critical > Fix For: 3.2.0, 4.0.0 > > > There are a number of places in DOM where unsigned int and unsigned long are > used for indexes and sizes. These should be changed to XMLSize_t. Here is the > grep result: > DOMDocument.hpp: const > unsigned long lineNum, > DOMDocument.hpp: const > unsigned long columnNum) = 0; > DOMDocumentTraversal.hpp: > unsigned longwhatToShow, > DOMDocumentTraversal.hpp: > unsigned long whatToShow, > DOMLocator.hpp:virtual unsigned long getLineNumber() const = 0; > DOMLocator.hpp:virtual unsigned long getColumnNumber() const = 0; > DOMLSParserFilter.hpp:virtual unsigned long getWhatToShow() const = 0; > DOMLSSerializerFilter.hpp:virtual unsigned long getWhatToShow() const =0; > DOMLSSerializerFilter.hpp:// unsigned long fWhatToShow; > DOMNodeIterator.hpp:virtual unsigned long getWhatToShow() = 0; > DOMTreeWalker.hpp:virtual unsigned long getWhatToShow()= 0; > DOMTypeInfo.hpp:virtual bool isDerivedFrom(const XMLCh* typeNamespaceArg, > const XMLCh* typeNameArg, unsigned long derivationMethod) const = 0; > DOMXPathResult.hpp: virtual unsigned long getSnapshotLength() const = 0; > DOMXPathResult.hpp: * @param index of type unsigned long - Index into the > snapshot collection. > DOMXPathResult.hpp: virtual const DOMNode* snapshotItem(unsigned long > index) const = 0; > DOMImplementationList.hpp:virtual DOMImplementation *item(unsigned int > index) const = 0; > DOMImplementationList.hpp:virtual unsigned int getLength() const = 0; > DOMLSParser.hpp:virtual const XMLCh* getURIText(unsigned int uriId) const > = 0; > DOMNamedNodeMap.hpp:virtual DOMNode *item(unsigned int index) const = > 0; > DOMNamedNodeMap.hpp:virtual unsigned int getLength() const = 0; > DOMNodeList.hpp:virtual DOMNode *item(unsigned int index) const = 0; > DOMNodeList.hpp:virtual unsigned int getLength() const = 0; > DOMStringList.hpp:virtual const XMLCh *item(unsigned int index) const = 0; > DOMStringList.hpp:virtual unsigned int getLength() const = 0; > Ideally, we should do such an audit of the entire codebase. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059540#comment-16059540
]
Scott Cantor commented on XERCESC-1866:
---
Boris, feel free to unassign but I was just reviewing open bugs and noticed
this one mentions a "permanent" fix involving an ABI change. I'm guessing no
actual patch with that fix exists, but just checking now that we're able to
change the ABI again.
> Crash with regular expression
> -
>
> Key: XERCESC-1866
> URL: https://issues.apache.org/jira/browse/XERCESC-1866
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
> Environment: Windows XP, Visual Studio 2005
>Reporter: Alexander Hartmann
>Assignee: Boris Kolpackov
> Fix For: 3.2.0, 4.0.0
>
> Attachments: XERCESC-1866.patch
>
>
> when I run the following test code my application crashes on the second
> regEx.matches call:
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> some details I found during debugging:
> - there is an instance of RangeToken where I have no idea where this is
> created. I've set a breakpoint in the constructor but the debugger does not
> stop.
> - when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
> created and stored in fCaseIToken
> - when parsing is finished the newly created RangeToken is deleted (through
> ~RegularExpression -> ~TokenFactory), but the original RangeToken (where I
> don't know where it is created) still exists and references the deleted
> RangeToken in fCaseIToken
> - the next time RangeToken::getCaseInsensitiveToken is called the invalid
> reference fCaseIToken is returned and this leads to a crash when it is
> accessed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-1866:
-
Assignee: Boris Kolpackov (was: David Bertoni)
> Crash with regular expression
> -
>
> Key: XERCESC-1866
> URL: https://issues.apache.org/jira/browse/XERCESC-1866
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
> Environment: Windows XP, Visual Studio 2005
>Reporter: Alexander Hartmann
>Assignee: Boris Kolpackov
> Fix For: 3.2.0, 4.0.0
>
> Attachments: XERCESC-1866.patch
>
>
> when I run the following test code my application crashes on the second
> regEx.matches call:
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> {
> XMLBuffer optionsBuf;
> optionsBuf.append('i');
> optionsBuf.append('H');
> RegularExpression regEx(L"^\\W*Excel\\W*$", optionsBuf.getRawBuffer());
> regEx.matches("Excel");
> }
> some details I found during debugging:
> - there is an instance of RangeToken where I have no idea where this is
> created. I've set a breakpoint in the constructor but the debugger does not
> stop.
> - when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
> created and stored in fCaseIToken
> - when parsing is finished the newly created RangeToken is deleted (through
> ~RegularExpression -> ~TokenFactory), but the original RangeToken (where I
> don't know where it is created) still exists and references the deleted
> RangeToken in fCaseIToken
> - the next time RangeToken::getCaseInsensitiveToken is called the invalid
> reference fCaseIToken is returned and this leads to a crash when it is
> accessed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1956) x86-64 binary distribution can't be statically linked into a shared library
[ https://issues.apache.org/jira/browse/XERCESC-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-1956. - > x86-64 binary distribution can't be statically linked into a shared library > --- > > Key: XERCESC-1956 > URL: https://issues.apache.org/jira/browse/XERCESC-1956 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: Linux x86-64 >Reporter: Lee Doron > > I'm creating a shared object library that uses Xerces-C++. I'd prefer to link > my code to the static library (libxerces-c.a). However, when I try to do > that, I get a link error: "relocation R_X86_64_32S against `a local symbol' > can not be used when making a shared object; recompile with -fPIC". (I've > encountered this on Linux so far, but this is actually cross-platform code > that will also run on Windows and Mac, so if there would be a similar problem > on those platforms, please consider this bug to include them.) It appears > that it is impossible to statically link a shared object against 64-bit code > that is position dependent, since the shared object must contain only > position-independent code. The static libraries can only be linked directly > into an executable. > To fix this, I suggest that you please compile the static libraries for > 64-bit Intel binary distributions such that they have position-independent > code (the -fPIC option on gcc, as mentioned in the error above). Then it will > be possible to link them either into an executable or into a shared object > library. Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1956) x86-64 binary distribution can't be statically linked into a shared library
[ https://issues.apache.org/jira/browse/XERCESC-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-1956. --- Resolution: Won't Fix Binaries are no longer provided. > x86-64 binary distribution can't be statically linked into a shared library > --- > > Key: XERCESC-1956 > URL: https://issues.apache.org/jira/browse/XERCESC-1956 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.1 > Environment: Linux x86-64 >Reporter: Lee Doron > > I'm creating a shared object library that uses Xerces-C++. I'd prefer to link > my code to the static library (libxerces-c.a). However, when I try to do > that, I get a link error: "relocation R_X86_64_32S against `a local symbol' > can not be used when making a shared object; recompile with -fPIC". (I've > encountered this on Linux so far, but this is actually cross-platform code > that will also run on Windows and Mac, so if there would be a similar problem > on those platforms, please consider this bug to include them.) It appears > that it is impossible to statically link a shared object against 64-bit code > that is position dependent, since the shared object must contain only > position-independent code. The static libraries can only be linked directly > into an executable. > To fix this, I suggest that you please compile the static libraries for > 64-bit Intel binary distributions such that they have position-independent > code (the -fPIC option on gcc, as mentioned in the error above). Then it will > be possible to link them either into an executable or into a shared object > library. Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-1957) Add 64-bit Mac OS X binary distribution
[ https://issues.apache.org/jira/browse/XERCESC-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-1957. - > Add 64-bit Mac OS X binary distribution > --- > > Key: XERCESC-1957 > URL: https://issues.apache.org/jira/browse/XERCESC-1957 > Project: Xerces-C++ > Issue Type: Improvement >Affects Versions: 3.1.1 > Environment: Mac OS X 10.6 "Snow Leopard" >Reporter: Lee Doron > > Now that 64-bit software for Mac OS X has become commonplace, please add a > 64-bit binary distribution. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-1957) Add 64-bit Mac OS X binary distribution
[ https://issues.apache.org/jira/browse/XERCESC-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-1957: -- Fix Version/s: (was: 3.2.0) > Add 64-bit Mac OS X binary distribution > --- > > Key: XERCESC-1957 > URL: https://issues.apache.org/jira/browse/XERCESC-1957 > Project: Xerces-C++ > Issue Type: Improvement >Affects Versions: 3.1.1 > Environment: Mac OS X 10.6 "Snow Leopard" >Reporter: Lee Doron > > Now that 64-bit software for Mac OS X has become commonplace, please add a > 64-bit binary distribution. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1957) Add 64-bit Mac OS X binary distribution
[ https://issues.apache.org/jira/browse/XERCESC-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-1957. --- Resolution: Won't Fix There are no more binaries provided for any platforms. Macport includes, and will continue to include, a maintained port. > Add 64-bit Mac OS X binary distribution > --- > > Key: XERCESC-1957 > URL: https://issues.apache.org/jira/browse/XERCESC-1957 > Project: Xerces-C++ > Issue Type: Improvement >Affects Versions: 3.1.1 > Environment: Mac OS X 10.6 "Snow Leopard" >Reporter: Lee Doron > Fix For: 3.2.0 > > > Now that 64-bit software for Mac OS X has become commonplace, please add a > 64-bit binary distribution. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 17:40:
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
#include
#endif
so it either can't cope with "#if xxx" (which is used in many places),
or the error is in the generated "config.h". I'm afraid you'll need
to identify the cause of the error here. Can you include config.h in
a single test file like this:
#if HAVE_CONFIG_H
#include
#endif
int main()
{}
with or without the #if/endif? If you can pinpoint where the problem
is, we can look at further fixes.
Compilation of that single test file failed with just the same error
"Expression syntax" when HAVE_CONFIG_H defined without value
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or defined
with value (-DHAVE_CONFIG_H=1)
Good luck!
Vitaly
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
