Re: Regarding in-memory validation using Xerces C 2.8

[Cantor, Scott]

On 10/16/11 6:45 AM, neetha patil neethapa...@gmail.com wrote:

Does Xerces C 2.8 support this method? If so can u please brief it out?

What method?

The API docs are public, and the samples in the project already show
parsing in various contexts.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Introduction to icXML

[Cantor, Scott]

On 9/1/12 11:51 AM, Rob Cameron r...@international-characters.com
wrote:

On thing that is not quite clear to me, though, is the best organization
for keeping our code in a common framework with existing Xerces
code.We presently have some source subdirectories for our own
newly created files, while we have also made edits, both major and
minor, to many other Xerces source files in place.Is there any way
that the autotools chain can be used to address these issues?

I don't think it will help or hinder you. If you target a particular
Xerces release, then you could just include that code plus your
modifications directly in your source tree. Since your patches could
change between Xerces releases (allowing that there may not be another,
there's no sign of activity here), it doesn't buy much to build that into
your make process.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C / Patch Release Request

[Cantor, Scott]

On 4/10/13 10:46 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

I was hoping to find time and make a release around June or July.
It would also be a good idea to spend some time and try to fix some
new bugs that have been uncovered since the 3.1.0 release. Not sure
if you would like to wait or if you want to press ahead. But your
help would be greatly appreciated.

I'm happy to spend some time testing the build on my supported platforms
once it's ready to go.

I would suggest as a way of perhaps reducing time commitment than actually
producing binaries for other than Windows is not a great use of time. Most
projects using this software need packaging, not binaries. The focus
should be on making sure configure; make works well. In my opinion anyway.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C / Patch Release Request

[Cantor, Scott]

On 4/11/13 5:03 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

 I would suggest as a way of perhaps reducing time commitment than
actually
 producing binaries for other than Windows is not a great use of time.

Yes, I was also thinking along those lines, especially for platforms
like HPUX, AIX, etc. But perhaps you are right, maybe we should drop
everything except Windows. Would be good idea to send an email to the
lists and check if anyone objects.

For Linux it's literally a complete waste of your time, same for Mac.

Solaris is the one that you can make a case for, but it's also the worst
of the lot by far to deal with, and there are so many variables involved
in that platform that I know it never was of any use to me in producing my
software.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C / Patch Release Request

[Cantor, Scott]

On 4/11/13 12:59 PM, shath...@e-z.net shath...@e-z.net wrote:

I can check with Debian and Ubuntu integration teams to see what
support there is to create (.deb) packages for their distributions.

I can't speak for Ubuntu, but there are official shibboleth packages for
Debian (that I don't maintain) and that includes Xerces, if it wasn't
already packaged. So I may know the maintainer, and the point is that you
don't do it twice. Somebody owns that responsibility and you/we/somebody
can share that or assist.

Solaris-11 has also changed the way that software distribution
packages are managed.  I may still be able to test on Solaris-11
on X64 platforms, but I first need to get comfortable with the
platform.

Yes, Solaris packages are historically awful and there are a dozen
different packaging projects that are all different. Whether Oracle is
changing that and using something new that actually works I couldn't say,
but nothing that existed in Solaris alone was usable before or worth
wasting the time on.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: building xerces-C++ in Linux

[Cantor, Scott]

On 11/11/13, 9:20 PM, Shazni Nazeer mshazninaz...@yahoo.com wrote:

I'm new to Apache as well as to xerces. I took an SVN checkout of the
trunk directory into my Ubuntu as well as to a Windows machine.

You should use the distribution provided on the web site, not a checkout.

 I could successfully build the xerces in Windows with the MSVC solutions
that are provided. But
 I'm stuck with building it in Linux. I can't find any configure or
runConfigure scripts in src/xercesc directory as described in
http://xerces.apache.org/xerces-c/build-winunix-2.html

You don't get configure scripts out of subversion, those are generated by
autotools by running autoreconf against the source files.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 3:01 PM, Boris Kolpackov bo...@codesynthesis.com wrote:

See it from my POV: I have a ton of users that are pretty happy with
3.1.1. Now comes Scott and wants to cut a half-tested release just
to satisfy his immediate needs. Once you do this I will start getting
emails from my users saying why doesn't my stuff (which depends on
Xerces-C++) works in this or that situation. I don't want that.

I don't either, but to be blunt, the branch shouldn't be in the state it's 
in if you think it needs that much testing, because if a security issue 
pops up, you don't have the luxury of taking a lot of time.

I completely understand your point about using the trunk, and I agree with 
it. It's not worth the risk. But any fixes to the branch should be very 
carefully looked at, in which case testing can be fairly pro-forma.

I did review some of, but not all, the branch changes

Nobody is talking about months. Here is what I suggest you do:

1. Prepare the release (with all the updates to docs, new projects,
   etc).

I am not going to add in project files for a compiler I can't test. That 
flies in the face of the exact point you made above. If you think the 
files on trunk work, we can add them. As far as docs go, I obviously need 
specifics.

3. I will test it to the best of my abilities (even though I have
   absolutely zero time for it right now) and report any problems
   (I will also review the changes for any ABI breakage).

Do you think I do have time?

BTW, I am surprised you had to back-port so many bug fixes to the
3.1 branch. Normally anything that is backwards-compatible gets
committed to both head and 3.1. Are you sure you are using 3.1
and not, say, 3.1.1?

After about 2011-2012 or so, the branch simply died. Every fix was applied 
to trunk only, even when it was minor.

The most risky changes are to the transcoder code which saw a large set of 
fixes, mostly not ABI-impacting, that only hit trunk.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 4:00 PM, Boris Kolpackov bo...@codesynthesis.com wrote:

 As far as docs go, I obviously need specifics.

You will have to go through the website docs and figure what needs
updating. If something specific is unclear, ask and I will try to
help. But don't expect me to provide a step-by-step guide for you.
I unfortunately really don't have the time for that right now.

Is this the document mentioned earlier?

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt

If you could at least skim it for any errors, that would be a big help.

-- Scott

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 4:41 PM, Cantor, Scott canto...@osu.edu wrote:

Is this the document mentioned earlier?

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt

If you could at least skim it for any errors, that would be a big help.

Never mind, I missed the note at the top, from you in fact.

-- Scott

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 9:01 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

What about other platforms?! If this class is defined in a public header
(i.e., a header that is installed) and the function is virtual, then this
is an ABI change.

It's a struct, in an impl/ header marked as do not use, and the struct 
itself isn't embedded in any classes, only pointed to.

It's borderline, I suppose. If the impl/ header wasn't installed, it 
wouldn't even come up.

I can probably do the less efficient patch, but given the other notes on 
this thread, I don't know that it matters much.

-- Scott

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 9:10 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

 I've reviewed all the resolved issues against the trunk, and backported 
 15-20 or so to the branch.
 
 Once I have access I'll commit.

Before you do this have someone review your back-ports to double
check there are no ABI breakages.

If somebody is here to do the commits, then I don't have to do them, I'm 
happy to supply a patch with the Jira numbers.

The only change with even a hint of ABI impact is the string pool thing, 
which is a borderline case, and I can change it if need be. Nothing else I 
reviewed is close.

The only reason I assumed the pool change was acceptable is that the impl/ 
headers are marked do not use externally very prominently, and I assumed 
that was to warn people off so that they could change without altering the 
formal ABI in a shared library if they changed in a forward-compatible way.

-- Scott

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/17/15, 9:07 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

 I definitely don't have the cycles for a beta and it wouldn't fit my 
 timeline anway.

Then you shouldn't be making the release.

No, I shouldn't, but I didn't see any real alternative either. If somebody 
else is going to, I can easily step back.

I'm on VC10 for my builds, and I believe those are already there.

What about other users of Xerces-C++? When we publish a new release,
it is presumed that it will work on all commonly-used platforms and
compilers, not only what Scott Cantor needs.

It's been years, Boris. I think you're being very aggressive here with 
somebody trying to help and able to do so only within the limits of his 
own funding and project needs. That's how this stuff works. If you're 
going to set requirements that I can't meet, then there's not much I can 
say.

Bare minimum is to make sure 3.1.2 is as good quality as 3.1.1.

I can't go back and review every commit you all have made. I can be very 
careful with any commits *I* make, and I can test my use cases and allow a 
bit of time beyond that. If you're asking me to wait months, no, I can't 
do that. I have constraints too.

 I don't think you are approaching it with the right attitude. If all
you need is a bug-fix that only has to work for your specific case,
then just provide a patch (or a patched version of Xerces-C++) to
your users.

I probably would consider that, if it weren't for the fact that Red Hat 
and other distros have shipped your code.

And I'm not the only one who needs fixes. A simple review of Jira 
demonstrates that very easily.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/16/15, 2:51 PM, Cantor, Scott canto...@osu.edu wrote:



The fix on trunk changes the ABI by adding a length field to the string 
pool entries. I probably can come up with one that doesn't by just doing 
the length checking, at the cost of some efficiency.

Correction, it's not an ABI change, the pool entry class isn't exported on 
Windows, my mistake. So I'll just backport that directly.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

I've reviewed all the resolved issues against the trunk, and backported 
15-20 or so to the branch.

Once I have access I'll commit.

I don't have access to Jira either of course. I watched everything I 
backported for now, I can at least note it in a comment, but I can't alter 
the fix versions at the moment.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

On 2/16/15, 11:52 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

Unless you are prepared to do a good amount of testing (I can help
somewhat but you will have to take the lead, e.g., package a beta,
announce it, etc, etc), I would strongly suggest that you do the
bug-fix release (i.e., 3.1.2). Simply back-port the fix that is
only on trunk (and maybe check if there are more fixes that haven't
been applied to the 3.1).

The fix on trunk changes the ABI by adding a length field to the string 
pool entries. I probably can come up with one that doesn't by just doing 
the length checking, at the cost of some efficiency.

I definitely don't have the cycles for a beta and it wouldn't fit my 
timeline anway.

 Stillm packaging a beta is probably a
good idea. As is adding new VC++ project/solution files (i have
them in XSD but they use different DLL naming).

I'm on VC10 for my builds, and I believe those are already there.

Also, I must warn you, Xerces-C++ release process is probably
the most brain-dead thing you will ever experience. There is
the admin/ repository with some outdated release information.
I will also try to answer questions if you have any (I've done
the last couple of releases).

You'd have to give me some direction on this. With Santuario, it's a very 
limited process because projects with essentially no resources don't get 
big, elaborate processes in my world.

What's the bare minimum we can do once I have a tarball tested?

-- Scott

Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Cantor, Scott]

 We need a 3.1.2 release very badly. I'm willing to contribute heavily to that
 process.

Correcting myself, I see that the fix I need was applied to trunk and is part 
of, I guess,  what would be 3.2, not 3.1.2. I'm not sure if either branch is 
active at this point, but if not, I probably have to fork, so what is the 
current chance of seeing a release?

It doesn't seem like me forking is superior to my just preparing a release 
based on trunk, which seems to build. I'm willing to do that since I'm already 
an Apache committer, if given access and nobody else is willing.

Thanks,
-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Final Xerces-C 3.1.2 RC posted

[Cantor, Scott]

A hopefully-final distribution set is now posted [1].

No code changes have occurred since the second beta posting last week, but 
various distribution tweaks and changes to the doc/ content for generation of 
the web site have been made.

I believe this is now ready for the PMC to conduct a vote for the release.

-- Scott

[1] http://people.apache.org/~scantor/

Re: [VOTE] release of 3.1.2

[Cantor, Scott]

My committer's +1

-- Scott

On 3/18/15, 11:28 AM, Gareth Reakes gar...@reakes.com wrote:

Hey guys,

   Here is my +1.

Re: Final Xerces-C 3.1.2 RC posted

[Cantor, Scott]

On 3/18/15, 4:30 PM, Denis Excoffier xer...@denis-excoffier.org wrote:

When i compare the first RC and the second RC (current), i observe some 
improvement in the doc/ and samples/ folders, but also that
- config.guess has timestamp='2013-05-16' (RC2) instead of 
timestamp='2014-11-04' (RC1)
- config.sub has timestamp='2013-04-24' (RC2) instead of 
timestamp='2014-12-03' (RC1)
Just in case it might not be under control.

The difference is because I was building the early ones on a Mac, and the 
final host is a FreeBSD 9 VM with the latest port tree. I've distributed many 
packages off of it with no problems. They can always be regenerated locally any 
time it's needed.

-- Scott

Xerces-C Security Advisory [CVE-2015-0252]

[Cantor, Scott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


CVE-2015-0252: Apache Xerces-C XML Parser Crashes on Malformed Input

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.2

Description: The Xerces-C XML parser mishandles certain kinds of
malformed input documents, resulting in a segmentation fault during
a parse operation. The bug does not appear to allow for remote code
execution, but is a denial of service attack that in many applications
may allow for an unauthenticated attacker to supply malformed input
and cause a crash.

Mitigation: Applications that are using library versions older than
V3.1.2 should upgrade as soon as possible. Distributors of older versions
should apply the patches from this subversion revision:

http://svn.apache.org/viewvc?view=revisionrevision=1667870

Credit: This issue was reported independently by Anton Rager and Jonathan
Brossard from the Salesforce.com Product Security Team and by Ben Laurie
of Google.

References:
http://xerces.apache.org/xerces-c/secadv/CVE-2015-0252.txt


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVCzmVAAoJEDeLhFQCJ3lipRoP/RLr+6EyyUBp7PxXi31pHYbv
z7E1GZLZ+349BydmI+28y6QXSjjQIeU1VXHaRdBCpfNqv2rIe7n+s/PvojprdHGZ
Ocxg7iPs+mQTxtkTJht1JqT1d4s96BN+DgPDRf7vUzMsu7u6mf9E+Ds2Yajddqgh
zxmsv5YFJlppeAOKDbyaWPfivJS7ubjDK7SQ8Il5N7XHSmVcdGMjGh0Zmbn0mlzk
iTp13aoEknYI3M+4OpIgtszOgbsMQnhRwOgAX+0jBHxrWkK4MBNlotY6oPtx6zWt
DjM/JRr9+V59BsQKrNmE/D0csoEf4OeBEgeqmNTjpy8EO+gOgVHWMowUUAVQkMqu
37njc8IyR/JXStdtzJpHsj4HO2PE9ZE1Uy69DCqCDEeGWl61qx4+sg7Ul783dAab
hCAvAO0zLiyPgkNdydmBQWGymHsle+niydNAi+EGj47rEJ7lDhJhl9qVQ0zyMXr4
O1//QwV7BUaRcgQhcbvd71KeDkPBBNvwpYLAXxIpDkI1/2qjo8ANHxzu/EMP8weK
N+KoIEugAab+t1s1qWpgneYXHLy3uE3KvVeNvb/iHsl5nzzFVBkPe+2OCZfWoedJ
t7gAXaZ2htrF2BQl6g/5hm13/6ajmrtNcX0hBjx2VB4VACOtt0bqextaW/w2Vvb4
AcsopfNHOGvXLDJ3JkHS
=l9vC
-END PGP SIGNATURE-




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: [VOTE] release of 3.1.2

[Cantor, Scott]

 Thanks again Scott.

Ok, unfortunately I'm deep into the bowels of my software release at the 
moment, and OpenSSL just screwed me royally by adding to the 1.0.2 ABI in 
1.0.2a, so that's costing me a nice chunk of today.

I may get to the release late afternoon or tonight, hopefully, and if not it 
will be tomorrow. I have access to the web site and dist tree in svn, so there 
shouldn't be any hold up needing intervention.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Status of cleanup after release

[Cantor, Scott]

I believe I've corrected the few bugs I noticed with the web site, and all of 
the web site content is now checked into the branch, including the security 
advisory.

A blocker task is recorded noting that a trunk release should copy that content 
over as part of prepping it.

I have added a note to the old xerces-c/web tree's README file indicating that 
the content there is now legacy and would probably advise just removing that 
directory from svn.

I also reopened and marked the security fix as a blocker for 3.2 so that the 
fix gets ported to trunk.

I have one last TODO, which is to rewrite the admin/release-procedure file to 
reflect the actual process now so that the docs will be up to date in case 
somebody else needs to come along and repeat this exercise to fix an urgent 
bug, including me when I forget all of it in a month.

-- Scott

Re: Xerces-C 3.1.2 beta-3 available, call for testing

[Cantor, Scott]

On 3/9/15, 3:54 PM, Denis Excoffier xer...@denis-excoffier.org wrote:

Would it be feasible to also include the documentation (the doc folder,
like under xerces-c-3.1.1)?

I didn't recall the old source distribution including the API docs, but I see 
it's there, I just didn't run doxygen. I'll make sure the final includes them 
if I do the prep.

-- Scott

Xerces 3.1.2 Release Candidate available

[Cantor, Scott]

I have prepared a hopefully-final distribution for testing [1] as a release 
candidate. The filenames are identical to the eventual release.

I fixed the distribution last night to include all missing content that was 
present in the 3.1.1 distribution, including the HTML site and API docs. If 
anything is still missing, please let us know.



This distribution also contains the old tools/ directory for building the site, 
because the distribution was big enough already without it making much 
difference. One less separate file to post.

There are no code changes between beta-2 or beta-3 and this release, only 
distribution content.

-- Scott

[1] https://people.apache.org/~scantor/

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Xerces 3.1.2 Release Candidate available

[Cantor, Scott]

 Not missing ones i guess but extra ones. I suppose the following files should
 not be present in the gz and bz2 distributions:
 
 m4/._libtool.m4
 m4/._ltoptions.m4
 m4/._ltsugar.m4
 m4/._lt~obsolete.m4

I hadn't actually found where they came from. Might be a Mac thing. Probably 
not worth worrying over unless I actually have to rebuild...

 By the way, could we please also get a xerces-c-3.1.2.tar.xz distribution, in
 addition to or instead the bz2 distribution?

Does automake support it? I guess I can add that and rebuild another RC if it's 
important enough.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Xerces 3.1.2 Release Candidate available

[Cantor, Scott]

 Does automake support it? I guess I can add that and rebuild another RC if 
 it's
 important enough.

(For context, the only reason I added bz2 was that I package this for some SUSE 
platforms, and they're probably going to start warning me at the build service 
about not having bz2 sources.)

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

In case it matters, this is what I'm using with configure:

configure: Report:
configure:   File Manager: POSIX
configure:   Mutex Manager: POSIX
configure:   Transcoder: icu
configure:   NetAccessor: socket
configure:   Message Loader: inmemory


Any of those different in your build that's giving different output?

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

On 3/6/15, 9:34 AM, Gareth Reakes gar...@reakes.com wrote:

On OSX compiles fine but test run produces this attached failure diff.

Somewhat surprisingly, on my OS X laptop, my test run has identical output 
to what's checked in, no diff. But I did that out of subversion, not the 
tarball, so I'll rerun the check with the tarball.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

On 3/6/15, 4:17 AM, Gareth Reakes gar...@reakes.com wrote:

On OSX compiles fine but test run produces this attached failure diff.

Compared to 3.1.1 you mean?

How do the tests get run as a unit? Do you know which test is giving that 
different result?

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

On 3/6/15, 9:34 AM, Gareth Reakes gar...@reakes.com wrote:

No, compared to the committed test output file - 
scripts/sanityTest_ExpectedResult.log

Ok, I'll look at when that was committed.

make check

So it runs them as part of the test build? Ok, I didn't notice that, will 
review that.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

On 3/6/15, 10:08 AM, Gareth Reakes gar...@reakes.com wrote:

Do you have the file in your checkout? 

/xerces-c-3.1.2/samples/data/long.xml

No, it's not in the dist target, so that's the problem. I'll add it and 
republish a third beta today.

One of the things I'm trying to clean up is the dist. It was quite 
incomplete, which is a bad thing in general, it's important that it 
include everything needed for every platform.

I left the tools that rebuild the web site out for the moment, because 
those are pretty large, and the site inside the tree appears to be stale 
anyway, but everything else I'm trying to include.

-- Scott

Xerces-C 3.1.2 beta-3 available, call for testing

[Cantor, Scott]

A third beta with the missing test file added is now available [1]. The 
test output now matches the output checked in as a baseline.

-- Scott

[1] https://people.apache.org/~scantor/

Re: Xerces-C 3.1.2 beta-3 available, call for testing

[Cantor, Scott]

On 3/6/15, 11:07 AM, Gareth Reakes gar...@reakes.com wrote:

Great. So looks like tests all pass with expected results.

Yes, at least in this case. Anybody building elsewhere, it would be good to run 
that same check of course.

-- Scott

Re: Xerces-C 3.1.2 beta-3 available, call for testing

[Cantor, Scott]

On 3/6/15, 10:58 AM, Gareth Reakes gar...@reakes.com wrote:

Are you still getting that seg fault Scott? Which test?

No, should have clarified that sorry, I just didn't know how the tests were run 
or that you had a real script to run them. I was running them by hand without 
knowing what parameters to give them and that doesn't work too well.

-- Scott

Re: Xerces 3.1.2 Release Candidate available

[Cantor, Scott]

On 3/11/15, 1:41 PM, Cantor, Scott canto...@osu.edu wrote:

 By the way, could we please also get a xerces-c-3.1.2.tar.xz distribution, in
 addition to or instead the bz2 distribution?

Does automake support it? I guess I can add that and rebuild another RC if 
it's important enough.

I saw that this is also built-in. In the interest of stability, I'm leaving the 
automake file alone for now and I just manually generated a distribution with 
make dist-xz and posted it, it's the same distribution as the others.

Once the release is done, I'll tweak the makefile to include it going forward. 
If we don't have binaries, the least we can do is accomodate formats.

-- Scott

Xerces-C 3.1.2 beta-2 available, call for testing

[Cantor, Scott]

I've uploaded a second beta of Xerces-C 3.1.2 [2] containing a couple of 
small fixes (VS2012 solution file fix, a backport of an XMLString 
binToText bug reported yesterday) and a tweak to the automake settings so 
I can generate a ZIP distribution from make dist.

Just want to keep the test sources current.

Thank you to everybody who's smoke tested.

I have tried to run a few of the programs in test/ and they mostly did ok 
but one actually crashed (the DOM Normalizer test). I then reproduced the 
exact same exception crash using the 3.1.1 sources, so this isn't a 
regression, it was already behaving that way. I'm guessing the tests are 
out of date in some cases, but I don't know them well enough to look at it.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Tarball of 3.1.2 beta

[Cantor, Scott]

Irrespective of what the PMC would like me to do with this to get it 
formally out there, a beta-1 tarball of the 3.1.2 Xerces-C release is 
signed and uploaded to http://people.apache.org/~scantor/

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Tarball of 3.1.2 beta

[Cantor, Scott]

On 3/2/15, 4:29 PM, Gareth Reakes gar...@reakes.com wrote:

 On 2 Mar 2015, at 21:27, Cantor, Scott canto...@osu.edu wrote:
 
 Irrespective of what the PMC would like me to do with this to get it 
 formally out there, a beta-1 tarball of the 3.1.2 Xerces-C release is 
 signed and uploaded to http://people.apache.org/~scantor/
 


Thanks a lot Scott for the work. If people have a chance it would be much 
appreciated if they could test the beta.

Incidentally, I don't know how the ZIPped sources were prepared in the 
past, maybe just manually. But I marked the Windows project files with 
Windows line endings, so it should be possible to directly build for 
Windows from the tarball, barring any mistakes which I'll fix.

I included VC11 and VC12 project files as requested, don't know that they 
work. I will test VC10 this evening.

-- Scott

Re: Tarball of 3.1.2 beta

[Cantor, Scott]

On 3/2/15, 9:39 PM, Cantor, Scott canto...@osu.edu wrote:



Incidentally, I don't know how the ZIPped sources were prepared in the 
past, maybe just manually. But I marked the Windows project files with 
Windows line endings, so it should be possible to directly build for 
Windows from the tarball, barring any mistakes which I'll fix.

Or it would be if the tarball included the Windows project files. I'll 
take care of that before this goes final.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: xerces-c-3.1.2b1

[Cantor, Scott]

On 3/4/15, 10:42 PM, Denis Excoffier xer...@denis-excoffier.org wrote:



Hi,

Compiled successfully and somewhat tested on Cygwin 32 bits (1.7.35), 
Solaris 10, Linux 32 bits Ubuntu, and Darwin Yosemite (10.10.2).

It seems that you forgot the following one:

Is there a bug filed on it? If so I just missed it when I looked for 
things to backport, but if not, please file it.

-- Scott

Re: Xerces-C 3.1.2 beta-1 available, call for testing

[Cantor, Scott]

On 3/4/15, 8:18 AM, Alberto Massari albertomass...@tiscali.it wrote:



first of all, thank you for taking care of the release; I compiled the
source on Windows using VC9, VC11 and VC12; I have noticed that the 
solution file for VC12 is missing the correct version, so it is opened 
by VC11. I will be fixing this shortly on both trunk and branch

Appreciate the check and fix, thanks.

-- Scott

Re: [VOTE] release of 3.1.2

[Cantor, Scott]

On 3/18/15, 4:02 PM, Alberto Massari albertomass...@tiscali.it wrote:

Here's my +1 too. And also my thanks to Scott for the time spent in 
arranging this release.

You're welcome.

Just following up to say that I'll be doing the actual formal release tomorrow 
(various timing/scheduling factors make that the best choice for me).

I believe somebody from the PMC has to officially call the vote approved, but 
I'll assume that will happen. ;-)

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: [VOTE] release of 3.1.2

[Cantor, Scott]

On 3/18/15, 5:04 PM, Michael Glavassevich mrgla...@ca.ibm.com wrote:

Got to give folks time to vote. Normally suggested that these run for 72 
hours [1] before tallying them up. It's only been 6 hours on this one.

I will await the PMC's decision. I was operating based on off-line discussion.

-- Scott

Re: Xerces support on Solaris 11 (built on Solaris 10)

[Cantor, Scott]

On 6/16/15, 3:54 AM, thosaratu...@gmail.com on behalf of Atul Thosar 
thosaratu...@gmail.com on behalf of atultho...@gmail.com wrote:


From archives/google, I believe Xerces should work on Solaris 11 platform. But 
has anyone actually tried/ran it on Solaris 11?

A supported version, yes.

One more scenario I would to clarify/discuss –  Currently, we build Xerces 
v2.8 on Solaris 10 (SunOS, sun4u, sparc) and it works well on Solaris 10 
platform. We use Sun Studio 12 compiler. We would like to run it on Solaris 
11.2 (SunOS, sun4v, sparc) platform w/o changing the build platform. I mean we 
will continue to build Xerces on Solaris 10 and run it on Solaris 11.

Well, 2.8 is long dead and insecure.

-- Scott

Re: Xerces support on Solaris 11 (built on Solaris 10)

[Cantor, Scott]

On 6/16/15, 1:05 PM, thosaratu...@gmail.com on behalf of Atul Thosar 
thosaratu...@gmail.com on behalf of atultho...@gmail.com wrote:

Btw Could you please help me to understand in what sense 2.8 is insecure?

In the sense that it has security bugs that are fixed, such as [1]. There are 
undoubtedly others.

-- Scott

[1] http://xerces.apache.org/xerces-c/secadv.html

Xerces-C 3.1.4 release candidate for testing

[Cantor, Scott]

I have prepared a release candidate for 3.1.4 that fixes some outstanding bugs. 
My ETA for release is around the end of the month. I haven't checked over the 
generated HTML pages in the tarballs yet, so I probably will do a second RC 
before calling for a vote maybe around the end of next week, just to fix any 
missing doc changes. Code is frozen at this point barring feedback.

https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

This patch release includes a new security feature you can test. You can 
disable DTD processing (and cause the parser to error out) by setting an 
environment variable, XERCES_DISABLE_DTD=1. This was done in that 
less-than-ideal manner because of the desire to maintain ABI compatibility, 
while at the same time allowing applications that don't need DTD support to 
insulate themselves from a large class of bugs and attacks.
 
-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: How DOM can be serialized to JSON

[Cantor, Scott]

> How DOM presentation  of XML document can be serialized into string in
> JSON format and opposite?

Well, a) that's not a well-defined mapping, and b) there's no code in Xerces to 
do that if that's what you're asking. If there's any library using Xerces under 
it that does this, I wouldn't know but would be interested.

-- Scott

Error messages / ABI

[Cantor, Scott]

Question to the rest of the remaining developers: is it an ABI change to add 
error messages/codes? I'm not familiar enough with the error handling machinery 
to know what's entailed in adding one, though I know there's an enum, and an 
XML file that's used to produce all the source code with the error messages.

I'm inclined to assume that it is an ABI change, which is a pain, but thought 
I'd check.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Call for vote

[Cantor, Scott]

I've done a bit of minor cleanup (removing .svn detritus) and posted new 
artifacts with signatures:

https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

I would like to call for a vote by the PMC to release V3.1.4.

This is my +1

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Call for vote

[Cantor, Scott]

> Couldn't you find a more recent config.guess? See for example the one in
> gcc-6.1.0.tar.bz2, dated 2016-01-01.

I built it on Red Hat 7. I assume autoreconf pulls in whatever is there.
 
-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Release candidate of Xerces-C 3.1.3 for evaluation

[Cantor, Scott]

I've built a release candidate of xerces-c-3.1.3 for testing. This is a bug fix 
release to address some reported issues and I am targeting late February for 
the PMC to approve the release.

I noted there's a dev/ tree in the dist.apache.org svn repository, though I 
haven't located a URL that maps to it apart from svn directly.

You can find the unofficial RC1 source distributions here:
https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

CVE-2016-0729: Apache Xerces-C XML Parser Crashes on Malformed Input

[Cantor, Scott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2016-0729: Apache Xerces-C XML Parser Crashes on Malformed Input

Severity: Critical

Vendor: The Apache Software Foundation

Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.3

Description: The Xerces-C XML parser mishandles certain kinds of malformed
input documents, resulting in buffer overlows during processing and error
reporting. The overflows can manifest as a segmentation fault or as memory
corruption during a parse operation. The bugs allow for a denial of service
attack in many applications by an unauthenticated attacker, and could
conceivably result in remote code execution.

Mitigation: Applications that are using library versions older than
V3.1.3 should upgrade as soon as possible. Distributors of older versions
should apply the patches from this subversion revision:

http://svn.apache.org/viewvc?view=revision=1727978

Credit: This issue was reported by Gustavo Grieco.

References:
http://xerces.apache.org/xerces-c/secadv/CVE-2016-0729.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWzlsyAAoJEDeLhFQCJ3liUAsP/Rr4rBKVPxOw3+5JDiQWT27y
/TT1kLFV+u6LtuBL3q6rwOIANquEMP1nJPVuYtceNF66xHi7eX6HZ8jZch6T+uvZ
Bt+kUTOfG4PW1RLm83W1kof58PTI5mIYBWofAQzXm9TSyvoHF5GXWqzNyGOKauYN
pto5xvJzEN5gM7DjbXF8OoIesNVaqCnr+9A2WmCCdNGNzSQLlUVDg9kDvXUdDvHD
+TXHDfgP8OSEYl5e3B3P5OV6SzUi2xdATR6zQgb1QANJy7FoK/FOP5+2J8ccultu
mXlVHpsGlPoIi85nyKVykK3hTT4DyhqSwCa9ek3D5i7lIEk2dXxeevh90is3y/Al
0GSUoG7yXbfe7xmlcUUghdYeYBP6JSOiOqAREUsKfY6nYo4XpGwvJRz/Xgk7iw9y
p39sCIKuJBpqe1Vgy8ONeTFc0WZkkriq23n2oZ4zxoOImF5k44f01olZhA/wmE1P
Wi6Qrafn6myUtp1TAXWoakfxJo0DgHfH6fazlmYSPHIyfLShrAcG6aETDn92KsDp
gy4a5ulP/qpkncJrF2+XeM1wgQSTpUln2664fSwRw5whqg/PW/qGx+/1sltwOSQe
l4bvQhr9xvkv+W++aPFgmJF3HW0Gnsglty6KQAcQ/RqheZ+/vL9buCqWw2xg4bkN
BQJ4QvN4uaHIUxhzVfiL
=vI5o
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: file structure for installed xerces-c 3.1.2

[Cantor, Scott]

> I would like to ask which is the file structure for xerces-c_3_1.dll that has
> been successful built after following steps described here
> 
> https://xerces.apache.org/xerces-c/build-3.html

The solutions for MSVC at least build to the Build directory (with subsequent 
nesting based on what build is being done).

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Prepping a 3.1.3 release

[Cantor, Scott]

I'm starting to work on a bug fix release and while I'll review Jira and some 
notes I have saved up, this is just a general heads up in case anything 
pressing and small can be identified to fix.

Timeline for this is probably mid-Feb or so.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Xerces-C 3.1.3 released

[Cantor, Scott]

I have (finally) gotten the updated release posted [1]. The web site should be 
updated now; if any site errors are spotted, report them and I'll get them 
fixed.

-- Scott

[1] http://xerces.apache.org/xerces-c/download.cgi

RE: support for MSVC 2015?

[Cantor, Scott]

> Did someone manage to get xerces build with MSVC 2015?

Yes, I checked in solution files that are mostly working the other day.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 2.7.0 Source Code needed

[Cantor, Scott]

On 7/13/16, 10:11 AM, "Gobbur, Pratima"  wrote:
> I need the source code for 2.7.0 to check if there was any customisation on 
> our side.

http://svn.apache.org/viewvc/xerces/c/tags/Xerces-C_2_7_0/

-- Scott




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Call for vote

[Cantor, Scott]

With several +1 votes and no objections, the vote has passed and I will 
finalize the release tomorrow morning.

Thanks,
-- Scott

> -Original Message-
> From: Cantor, Scott
> Sent: Wednesday, June 22, 2016 12:32 PM
> To: c-dev@xerces.apache.org
> Subject: Call for vote
> 
> I've done a bit of minor cleanup (removing .svn detritus) and posted new
> artifacts with signatures:
> 
> https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/
> 
> I would like to call for a vote by the PMC to release V3.1.4.
> 
> This is my +1
> 
> -- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: [patch] Allow building with ICU using VC12 and VC14

[Cantor, Scott]

> Attached is a diff against 3.1.4 to enable building with VC12 and VC14
> with the ICU configurations.

I assume that's already in Jira. If not, it's not going to ever get remembered 
and applied.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Xerces-C 3.1.4 released

[Cantor, Scott]

> FYI, the downloads on http://apache.org/dist/xerces/c/3/sources/
> are missing the signatures and checksums for xerces-c-3.1.4.tar.xz.
> Would it be possible to add them?

Forgot it existed. I'll try and get to it when I can.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

CVE-2016-4463: Apache Xerces-C XML Parser Crashes on Malformed DTD

[Cantor, Scott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


CVE-2016-4463: Apache Xerces-C XML Parser Crashes on Malformed DTD

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.4

Description: The Xerces-C XML parser fails to successfully parse a
DTD that is deeply nested, and this causes a stack overflow, which
makes a denial of service attack against many applications possible
by an unauthenticated attacker.

Mitigation: Applications that are using library versions older than
V3.1.4 should upgrade as soon as possible. Distributors of older
versions should apply the patches from this subversion revision:

http://svn.apache.org/viewvc?view=revision=1747619

Note that the nesting limit is currently implemented as a compile-time
constant in order to maintain ABI-compatibility.

In addition, a related enhancement was made to enable applications
to fully disable DTD processing through the use of an environment
variable. Distributors of older versions are urged to incorporate
this patch to enable applications to more fully protect themselves
from future issues if they do not require DTD support. This change
is ABI-compatible and can be found in this subversion revision:

http://svn.apache.org/viewvc?view=revision=1747620

Credit: This issue was reported by Brandon Perry.

References:
http://xerces.apache.org/xerces-c/secadv/CVE-2016-4463.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXXqPQAAoJEDeLhFQCJ3liyRwQAI5aUjhKtZtw+51EgNizpuLa
dvfEP27anUXLKwLXt+WIfogW3TLQ4HwyiszanO4YTlwz3qbKO3TJQXdT4kTQx6/k
KhWr7+vsn7pBEPiiC7kj3lH7QHCd+T8/W+Xik/rKDFV1qAAKuoFgYJ31qED8I65z
371Tdm+p2QE4Nh9M7k7LUs+yWu5XdwJIS61L3R/MpEptynuo7Onbp+sjF6OQCZHc
u1KJ3zAlKzP4iwtxKjvoXqOnLgYwjtqC2p7nYBEXOEn4DA4Q/PMrfdYIebjUo/Wy
CeIN5TGJ2aunMkVK0RgxCqjr0sl2cYqY8iegUqp9Iz4+rMpy5ZDLNyyjgbXgSY73
8145xO2tscLs7bLXAXUGbLlOPxnDqVieGlYyHICFnl58I4ekfhwtMmd9d2WOlaVE
7NEPTorFiHI+wdK2yebCLAMaJbL9KJQiJa/4xw9qvpZ4DQ7aein9jq7fklQ62crc
Ff4h4icX4icM1/s1tvcEM1lZw8Td4UyXkwvoEmfZg7dVy4NW+XM/Kn4FUCPRnC9A
XVAabL3K290Mz77YLqUTk733w1q/lFCxgOCJF18/OJef2azMn74QgFbLcBD16i2O
FNxdtPsSRGNsfOGN08Uiwg9RN6uqoZ6Rxwq3hEcAiufYQHFiXldlS26koP2QMk03
gNuHTr22AcR0ZgoW9GYP
=eilz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Xerces-C 3.1.4 released

[Cantor, Scott]

A patch release of the Xerces-C XML parser is now available and is propagating 
to the mirrors. It includes a small number of important bug fixes, including a 
fix for CVE-2016-4463.

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10510=12336069

Of special note, applications that don't make use of DTDs should strongly 
consider setting the XERCES_ DISABLE_DTD environment variable to "1" to 
insulate themselves from the likelihood of future vulnerabilities in that code. 
When I have a free moment I will make that a parser feature in the trunk since 
it requires an ABI change.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: 3.1.2 NuGet package

[Cantor, Scott]

> We are now wondering if Xerces-C++ devs are happy for us to upload this
> package to www.nuget.org and, if so, whether there are any specific
> guidelines we should follow or clauses to be aware of in order to do this
> (aside from clearly indicating the obvious bits, regarding who is the true
> author of the code and the license). The package is a simple build of the 
> 3.1.2
> sources, with no custom modifications to the source code, and as such we
> wish not to take any responsibility over maintenance of the NuGet package.

Speaking as the person who has done the last few releases, and not as a PMC 
member, can you clarify the last sentence?

If you're going to upload something like that, you would most certainly be 
taking responsibility for maintenance of such a package.
 
Basically, the licensing certainly permits you to do this, but you are the one 
supporting it, not the project. If somebody else on the project or in the 
community would like to support it, that's of course fine with me.

I'm not familair with this site, but if I thought I could get all my project's 
dependencies to use it for Windows, I might be more open to the idea of 
maintaining this one there, but that's not likely to be the case, at least not 
soon.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: 3.1.2 NuGet package

[Cantor, Scott]

> Our intention is to specifically use this platform to deliver the Xerces-C++
> 3.1.2 NuGet package that we have put together so that users of DNV GL -
> Energy software products can have access to it in a public and easily
> accessible repository. We would clearly indicate that the package has been
> put together with this specific goal in mind, and it is for this target 
> audience
> that we would, indeed, be maintaining it.

Then I don't think anybody would have any objections (and even if they did, the 
license permits you to, so apart from courtesy (thanks), there's really nothing 
stopping you.

What I would caution you about is simply the security model around this. If 
somebody were to ask me to obtain a package like this from a source that I had 
no reason to trust, I would tell them they were crazy. To draw an analogy, 
people using Maven Central as a source for artifacts but don't constrain the 
signers of the software they get from it are, well, let's say "ignorant of 
basic security practice".

Without authentication of the source of an artifact (not just authentication of 
an artifact, and that assumes you are in fact signing and people are in fact 
verifying that), you have no way to know what somebody might have done to the 
source.

But none of that really pertains to whether you *may* do this: you certainly 
may.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: XERCESC-2066 (Exception handling mistake in DTDScanner)

[Cantor, Scott]

> Does somebody know when it will be fixed in official patch?

Months ago?

http://svn.apache.org/viewvc?view=revision=1747619

Red Hat still hasn't backported it to my knowledge.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: XERCESC-2066 (Exception handling mistake in DTDScanner)

[Cantor, Scott]

> > Does somebody know when it will be fixed in official patch?
> 
> Months ago?
> 
> http://svn.apache.org/viewvc?view=revision=1747619

Meant to link to advisory.

http://xerces.apache.org/xerces-c/secadv/CVE-2016-4463.txt
 
> -- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Porting XERCESC-2052 fix to 3.1 branch

[Cantor, Scott]

> I had a transcoding problem with Xerces-C and noticed that it has
> already been described
> https://issues.apache.org/jira/browse/XERCESC-2052 and fixed for more
> than a year but not in the 3.1 branch.
> So I took the liberty to port the fix and would be happy if it could be
> released in a (hopefully soon) upcoming 3.1.5 or if 3.2 is just around
> corner, this would be even better.

I ported a number of patches from trunk back to the branch when I first jumped 
in to get security work done on the branch and put 3.1.2 out. This seems to 
have been filed against 3.1.2, so I don't think I ever saw that one, it 
probably wasn't brought to my attention and the bug entry doesn't have the fix 
outlined either. And I am generally terrified of touching transcoding code 
since I don't understand any of it, so that all explains why it wasn't 
backported.

The major problem is that I have no way to test fixes to code I don't 
understand. That's the biggest problem, paralysis out of fear of breaking 
something.

If somebody vouches for the fix, I don't have a problem applying it, but I 
can't possibly know whether the fix is safe beyond just taking somebody's word 
for it.

Either way, I'd advise attaching the patch to the bug, and I'll reopen it for 
now just to track that it hasn't been backported.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Porting XERCESC-2052 fix to 3.1 branch

[Cantor, Scott]

> So just for the record, the error is really a regression, it worked in
> 3.1.1 and the fix in trunk was this commit:

That's even stronger evidence that I have no business touching that code, I'm 
afraid. So I would have to say that somebody who does know it needs to own it 
and take care of applying those fixes to the branch.

-- Scott


-
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

[Cantor, Scott]

On 4/22/17, 2:59 PM, "Roger Leigh"  wrote:

> There are two choices for merging it:
> - to the 3.1 branch
> - to the trunk, for releasing as 3.2

Or a third branch, but I think you already did that via git anyway and that's 
simpler in practice so we can dismiss that one.

> Since the proposed changes don't touch any of the existing build 
> systems, merging onto the 3.1 branch would be safe, but since it's a 
> fairly large change it would be understandable to leave this for a new 
> minor release.  Is there any particular preference?

I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. So I'm inclined to 
do the very ugly work of figuring out what's missing from the trunk and 
reviewing all the additional work there that was done before the project went 
into moribundity, and try and get a 3.2 out the door this summer. 

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.

> For maintenance reasons, I'd like to propose removing all the Visual Studio 
> files; this was one of the primary reasons for developing the CMake 
> support in the first place.  This would make sense to do on the 
> trunk/3.2 branch, since we wouldn't want to remove existing 
> functionality on the 3.1 branch.

Right, I think that's another good argument for using trunk.

> Removing the Autoconf support would also be a possibility if there was 
> consensus to do so.  The CMake support certainly implements all the 
> Autoconf features--it reproduces every single feature test and option 
> exactly.  But the maintenance cost is vastly less than the Visual Studio 
> support, so retaining both Autoconf and CMake support is certainly possible.

I'm not inclined to consider removint autoconf without seeing the alternative 
and understanding the implications, particularly wrt libtool.

> Additionally, if anyone wanted to review and test the patch, it's 
> attached to the above ticket and also available here: 
> https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1

I will do so when I can.

-- Scott

Beta of 3.2.0 available

[Cantor, Scott]

I don't think we have a server at the ASF I can make these available with, so 
just doing what I can I guess.

https://shibboleth.net/downloads/prerelease/xerces-c/

They're signed with my published key.

These are directly from a make dist of trunk. I have not generated or reviewed 
the site doc output yet so there are certainly some errors left in there.

Please report any issues identified here or in Jira.

I'll probably try and post a RC next week.

-- Scott

RE: Remaining Xerces 3.2.0 issues and Xalan

[Cantor, Scott]

> Are there any known remaining issues for the 3.2.0 release?

Nothing known; I didn't have the time I had hoped to get some testing done with 
my application, which I really should do before I ask for a vote but I won't 
hold things up much longer either way.

>  I've tested with various Visual Studio versions and also tested on CentOS 6, 
> CentOS
> 7, Ubuntu 16.04, Ubuntu 17.10, MacOS X 10.11 and 10.12 and FreeBSD 11.1
> and it's worked on all of them.  I've also built with Xalan-C on all of
> these platforms, and it works across the board.  Xalan does require
> patching if using a C++11 compiler; I've filed a JIRA ticket with a
> patch for this: https://issues.apache.org/jira/browse/XALANC-773 .

Thanks very much.

> I've asked about this and cmake on the Xalan list a few times, but I've
> yet to have any response at all on the list or on a JIRA ticket.  Does
> anyone know the current maintenance status of Xalan-C?

I had been under the impression it was in worse shape than Xerces. I don't want 
to be over-dramatic, but it was my impression that if I hadn't been willing to 
dive in in 2015, this project would probably be in fairly bad shape because of 
the open security issues. I don't know who else was going to jump in and fix 
it. I didn't have the time to wait that out.

>  There are a number of outstanding patches which various Linux and other
> distributions are carrying in order to be able to compile which could
> really do with folding into a new release.  If the project is abandoned
> and without a maintainer, is there any process to go through to join the
> project to apply these outstanding patches?

It would be much the same as with Xerces, the difference being the PMC was at 
least still around and responding when I had to jump in, so there wasn't a 
problem getting commit access at the time.

If the PMC itself has gone dead, though, they should be getting attic'd by the 
board, due to missing board reports. So somebody must be keeping it alive, I 
would probably start by just offering to help and if you get no response I 
think your only recourse is to the ASF board.

(I have no exposure to Xalan, so it's not on my list of kittens to rescue, I'm 
afraid.)

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Porting XERCESC-2052 fix to 3.1 branch

[Cantor, Scott]

Don't know if the OP (cc'd) is still around but since I'm trying to get us 
moving toward a 3.2 release, I wanted to clarify this...

> So just for the record, the error is really a regression, it worked in
> 3.1.1 and the fix in trunk was this commit:

I don't see how this "worked" in 3.1.1, the patch in question:

> http://svn.apache.org/viewvc?view=revision=1701594

Was applied only to trunk, not to 3.1.0/3.1.1, and the test case is only on 
trunk. It couldn't have been working on 3.1.1 or the "fix" is something else.

I was concerned that one of the security fixes to 3.1.2 and up broke something, 
and had filed this away to follow up before a 3.2.0, but this seems to be 
something else entirely, just a fix that didn't ever get done on the branch, 
and therefore can be closed out once we release trunk.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Can we assume C99?

[Cantor, Scott]

Are you using C++11 in the cmake CI builds on Linux? Just curious...it seems to 
be detecting cstdint there but my autoconf test didn't due to that flag not 
being enabled.

I don't think we have an autoconf check for it, so there's nothing to enable it 
if the compiler supports it.

-- Scott

RE: Can we assume C99?

[Cantor, Scott]

> I wrote the Autoconf AC_PROG_CXX support for C++11 back in 2013
> (http://www.spinics.net/lists/ac/msg11596.html) but it appears not to
> have made it into a stable release yet.  It might be possible to take a
> copy of the macro from Autoconf CVS.  (This was before I discovered
> CMake!)

Seems like it might be worth it, I'll take a look. It would be simpler to 
compare outcomes with the cmake builds at least.

-- Scott

Re: Can we assume C99?

[Cantor, Scott]

On 7/7/17, 3:45 AM, "Boris Kolpackov"  wrote:

> Perhaps we should do something like this for Xerces-C++, especially if
> we plan to start migrating to C++11. In fact, this will be a great aid
> to gradual migration since we can just start using new features if they
> are available in all the supported compilers.

It's certainly workable for me but I only support a fairly limited set myself 
so it's hard for me to say what others might need, or be able to avoid 
problems, unless Travis or similar tool exists to verify the build, or we have 
volunteers I guess.

-- Scott

Release candidate forthcoming

[Cantor, Scott]

We have one main enhancement patch outstanding but no CLA on file for it and no 
response from the original submitter, so I'm going to start prepping for a 
release by getting a 3.2 release candidate out the door.

If there are any other issues open people intend to work on or have an actual 
fix for, please call it out.

One outstanding issue is deleting all the old Windows solution files, but I'll 
take care of that before I do the release candidate.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Upporting status

[Cantor, Scott]

On 6/29/17, 3:25 PM, "Roger Leigh"  wrote:

> It's "scripts/sanityTest.pl", a Perl script which runs all the tests, 
> concatenates their output, and then diffs it with the expected output. 
> It fails if the output differs or the tests fail prematurely.

Well, I've run that before, and now, and it never works, so I'm still missing 
the trick, that's why I never bothered with them, assumed they were all broken. 
Is there some special directory to be in? Files in place?

Doesn't work on a Mac maybe?

I'll keep playing.

-- Scott

Re: Upporting status

[Cantor, Scott]

On 6/29/17, 3:46 PM, "Roger Leigh"  wrote:

> Actually, just run "make check" which builds the tests and runs them foryou.

Not for me unfortunately.

export 
PATH=/Users/scantor/Documents/workspace/xerces-3.2/samples:/Users/scantor/Documents/workspace/xerces-3.2/tests:"/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/opt/local/bin"
 && export XERCESC_NLS_HOME=/Users/scantor/Documents/workspace/xerces-3.2/src/ 
&& cd . && perl scripts/sanityTest.pl 2>&1 | /usr/bin/sed 's/ *[0-9][0-9]*  *ms 
*/{timing removed}/' 1> 
/Users/scantor/Documents/workspace/xerces-3.2/test-results.log
/bin/sh: /Users/scantor/Documents/workspace/xerces-3.2/test-results.log: No 
such file or directory
make: *** [check] Error 1

-- Scott

Re: Upporting status

[Cantor, Scott]

Ack, never mind, PEBKAC, they're running now.

-- Scott

On 6/29/17, 3:49 PM, "Cantor, Scott" <canto...@osu.edu> wrote:

On 6/29/17, 3:46 PM, "Roger Leigh" <rle...@codelibre.net> wrote:

> Actually, just run "make check" which builds the tests and runs them foryou.

Not for me unfortunately.

export 
PATH=/Users/scantor/Documents/workspace/xerces-3.2/samples:/Users/scantor/Documents/workspace/xerces-3.2/tests:"/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/opt/local/bin"
 && export XERCESC_NLS_HOME=/Users/scantor/Documents/workspace/xerces-3.2/src/ 
&& cd . && perl scripts/sanityTest.pl 2>&1 | /usr/bin/sed 's/ *[0-9][0-9]*  *ms 
*/{timing removed}/' 1> 
/Users/scantor/Documents/workspace/xerces-3.2/test-results.log
/bin/sh: /Users/scantor/Documents/workspace/xerces-3.2/test-results.log: No 
such file or directory
make: *** [check] Error 1

-- Scott

Re: Upporting status

[Cantor, Scott]

On 6/29/17, 3:31 PM, "Roger Leigh"  wrote:

> This is because the unit test is comparing the tool help output line by 
> line and it's simply due to an extra line being added to the help 
> output.  It's not a fault of the change, it's just that the test data 
> needs updating to keep in sync with the change.

I get that one, but the invalid document structure message I think one of them 
mentioned is what the new option reports if you have a DTD. Since the test 
should still be allowing DTDs, I don't know why that would be getting raised. 
Could be one of the tests actually sets the DOM option that before wasn't 
implemented, I'll have to see.

Thanks for the tips on running them.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Upporting status

[Cantor, Scott]

On 6/29/17, 3:02 PM, "Roger Leigh"  wrote:

> The recent trunk changes broke a few of the unit tests.

I don't understand how, other than the ones that are for some reason depending 
on the output of the parameter options for the DOMCount sample. That seems like 
an odd test, but it certainly would have broken.

Since nothing should be actually invoking the sample with the new option, I 
don't know why a new error would be raised in the tests, it defaults to 
behaving the same as before, allowing DTDs.

>Do you need a hand looking at fixing any of these bits?

I don't know any of the tests or even how to run them, so probably.

If the tests can be run locally with an autotools build, I haven't found that 
trick yet.

-- Scott

RE: Upporting status

[Cantor, Scott]

> You might find https://issues.apache.org/jira/browse/XERCESC-2104 of
> interest.  This replaces sanityTest.pl with separate automake checks.
> You can still run "make check", but it now shows you each individual
> test being run and stores the logs in separate files.  This makes it
> much clearer what's breaking.

I don't know what XFAIL means but the tests all pass for me on Windows and 
Linux at the moment.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Upporting status

[Cantor, Scott]

Roger, is that separate fork updated with the master copy? It looks like maybe 
it's missing the bug fixes I checked in Friday after you let me know they were 
failing. That would certainly explain it.

The link issue was just a dangling reference to 3_1 in the ICU build from the 
version change, which I probably should see if we can get indirected into a 
macro.

I'm not familiar with Travis yet but I interpreted the output here [1] as 
successful (the #9 link).

-- Scott

[1] https://travis-ci.org/apache/xerces-c/builds

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Can we assume C99?

[Cantor, Scott]

I don't know what the baseline has been for the code base, is C99 a reasonable 
requirement?

I need SIZE_MAX to fix some bounds checking errors, just need to know if I need 
to waste time on an autoconf test for it.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Can we assume C99?

[Cantor, Scott]

On 7/6/17, 5:54 PM, "Roger Leigh"  wrote:

> Interesting, I'll certainly take a look.  I'm afraid I'm away until next 
> Wednesday, so I won't be able to do anything until then.

If you want to check it, this is what I had to use on the autoconf side:

#if defined(__cplusplus) && XERCES_HAVE_CSTDINT
#   include 
#elif XERCES_HAVE_STDINT_H
#   if defined(__cplusplus)
#   define __STDC_LIMIT_MACROS
#   endif
#   include 
#endif

Yours drops into the first bit so it didn't ever have to try and depend on 
stdint.h, but if you ever had to depend on that, the __STDC_LIMIT_MACROS 
defintion is required by the C99 standard if you want the limit macros defined 
in stdint.h when C++ is used.

Of course, your point about using numeric_limits is probably valid, but I don't 
know precisely when/where that might be unsupported.

-- Scott

RE: Can we assume C99?

[Cantor, Scott]

> Visual Studio had somewhat lacking C99 support, so it might be problematic
> for older versions.

It's not missing SIZE_MAX though, AFAIK, so Windows isn't really much of a 
concern there.

> Could we not use std::numeric_limits instead?  It should work everywhere,
> and should be better supported than C99?

Possibly, I'm not as familiar with it. If we're referring to size_t in the 
code, which we are, I wanted to be consistent with that. I checked in this 
change for now so I could patch a bug in Base64.cpp, and it's indirecting via 
XERCES_SIZE_MAX, so it's easy enough to change, though hard to test.

I think your cmake check around some of this may be slightly off. It was 
including stdint.h but if you do that in C++, you don't get the MAX macros 
unless you define another macro apparently. I don't get cstdint usable on Linux 
without C++11, so it's falling into the stdint.h part, and I had to alter your 
cmake version to make that work.

-- Scott

Re: Integrating CMake support for xerces

[Cantor, Scott]

On 4/25/17, 3:17 PM, "Roger Leigh"  wrote:

> Switching to git would be wonderful.  We could also enable CI testing 
> with e.g. Travis or some other CI service on github at that time to 
> enable testing of all PRs, if that would be accceptable.  Or does the 
> Apache project provide any equivalent services internally?

There are already mirrors of the code at git.apache.org (and to github from 
there), and of course all CI tools can pull from svn just as easily as git. 
That's never been an impediment. I don't know if there are tests sufficient to 
be worth exercising like that or not.

> Regarding (3), it's a bit outside the scope of this CMake ticket.  My 
> intentions here were to get a build system which would provide a working 
> build on all platforms, including the unit tests.  I didn't want to go 
> down the rabbit hole at the same time.  Ideally, if we merge this to the 
> trunk and branch off a 3.2 and release that, more adventurous changes 
> could be then done on the trunk.  I'd rather have a working release with 
> the CMake support included than to do both and not have an immediately 
> usable and API compatible release!

+1

I wasn't suggesting anything else, and it makes sense to go ahead and branch 
again if there's going to be any real screwing around, I need a stable branch 
myself.

I have made some progress today after a few hours reviewing trunk and I'm only 
about 10 commits back from when I started cherry picking things back to the 3.1 
branch, at which point the trunk essentially froze. So far there is very little 
divergence, just a few small API additions that are unique to the trunk. So I 
don't foresee anything terribly risky about releasing this after some 
additional fixes, some testing, and incorporating your patch.

> That said, I'd not be averse to including support for standard C++; 
> using Xerces is often a bugbear due to its age.  All our code is now 
> C++11, with RAII wrappers to make Xerces play nicely.  Primarily the 
> lack of RAII, non-standard exception types, odd memory management 
> semantics and transcoding all input.

The problem with C++11 is it's just not portable to enough compilers outside of 
Windows. I'm aware gcc probably supports it but gcc on actual Linux distros 
that people still use heavily does not. If I can't build it on RH6 it's not 
usable for me, and since I'm the one doing most of the work right now...

Really, C++11 is beside the point. Simply good old C++ would fix many issues, 
but this code dates to back when using real C++ and the STL was just too 
non-portable, along with the usual Unix anti-C++ bias.

> Something worth noting is that our 
> (optional) ICU dependency switched to requiring C++11 with ICU 59.1.  It
>  switched to using the standard char16_t as its XML string type.  If 
> Xerces were to also switch (or at least use a suitable typedef), we 
>  could be using const char16_t* foo = u"UTF-16 strings" and/or u8"UTF-8" 
> strings directly in both the xerces sources and in client programs.  A 
> major usability improvement.

At a huge cost in portability unfortunately. Believe me, I wish that were 
viable for me. So, so much.

> In a recent performance testing exercise at work, we found string 
> transcoding inside xerces-c to be a major time sink--using valgrind 
> callgrind--it was one of the major uses of CPU time during parsing and 
> DOM processing.  It was slower than xerces-j for the same operations, 
> and this was likely to be a major cause.

I'm not sure that you're going to fix that. It's already using UTF-16 
internally. If there are problems with transcoding, I think that's just the 
cost of transcoding, I don't think the need to transcode goes away unless I'm 
missing something.

Anyway, within a week or two I expect to be able to put trunk in a position to 
accept your patch and we can continue on from there.

-- Scott

Re: Integrating CMake support for xerces

[Cantor, Scott]

On 4/25/17, 8:30 PM, "Cantor, Scott" <canto...@osu.edu> wrote:

> So far there is very little divergence, just a few small API additions that 
> are unique to the trunk. So I don't foresee anything
> terribly risky about releasing this after some additional fixes, some 
> testing, and incorporating your patch.

Other than some things I have to port up from the branch and other bug reports 
that have come in, the two big commits on trunk are:

r1517488 (XERCESC-2016)
r1528170 (XERCESC-2019)

The former is a patch that's pretty invasive to add XML 1.0 5th edition 
support, which I surmise actually removes a lot of the special handling of XML 
1.1 All of that is outside my expertise, so I don't have any insight into how 
risky that change is or how well it was tested. For myself I don't need it at 
all and would as soon undo it if it can't be verified as safe, but I'm not 
suggesting that exactly, just noting it's significant.

The latter is smaller and is a change to memory handling of text buffers in the 
DOM. I haven't fully grokked that yet but I doubt it's a big deal, just worth a 
look.

Everything else on trunk now that's not on the branch is much simpler and I 
don't see as risky.

-- Scott



-
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

[Cantor, Scott]

On 4/26/17, 4:04 AM, "Roger Leigh"  wrote:

> Agreed that just moving up to C++98 standard types in and of itself 
> would be greatly beneficial.  There should be no portability barrier to 
> achieving that.

No, definitely not. I've been using the STL and Boost for years now on many 
platforms.

> Regarding portability, I also have the "pleasure" of supporting code on 
> CentOS 6.  I don't know if you've tried it, but we switched to using the 
> SCL "devtoolset-3" (now "devtoolset-4") packages which backport a modern 
> GCC and the rest of the toolchain to CentOS6 (and 7).

Do the packages built from that work on an unmodified CentOS 6 system? Meaning 
does it pull in any dependencies for that from the standard repos?

The change that's really relevant for me is that Red Hat 5 dropped out of 
standard support in March, so that was a major switch.

Unfortunately I also have many older SUSE versions to support also.

-- Scott




-
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

[Cantor, Scott]

> Since we are sharing plans, we (as in Code Synthesis) are planning
> to package Xerces-C++ for build2[1] in the near future (but no
> definite time-frame). While I haven't looked into this closely
> yet, the options we consider range between just packaging it as
> is to pretty much forking it. The main reasons for forking would
> be: (1) to switch to git (life is just too short for svn), (2)
> to get rid of the Apache bureaucracy, and (3) rip all the legacy
> parts out and clean things up (maybe even switching to C++11/14).

(1) doesn't matter to me, but +1000 to (2) and I have very little compunction 
about (3), aside from the obvious fact that once you start pulling that thread, 
you're on slippery ground.

I wasn't prepared to really go so far as to start tossing things out or 
proposing really invasive changes but it sounds like cleaning up and releasing 
the trunk would serve both short term and longer term ends here.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

3.2.0 RC1 posted

[Cantor, Scott]

A release candidate is posted:

https://shibboleth.net/downloads/prerelease/xerces-c/

This includes all the fixes from weekend bug finding, a rebuild of the web site 
in doc/ and the generated API docfiles.

I would like to call for a vote probably around the end of this week.

-- Scott

Re: Second 3.2.0 beta available

[Cantor, Scott]

Adding missing refs:

[1] https://shibboleth.net/downloads/prerelease/xerces-c/
[2] https://issues.apache.org/jira/projects/XERCESC/issues/XERCESC-2108

On 8/4/17, 10:50 AM, "Cantor, Scott" <canto...@osu.edu> wrote:

I've updated the beta [1] with the distribution fixes, and one code addition 
[2].

I'll let this one sit for a few days or so for testing and publish a release 
candidate next week. I have not tested Solaris yet, but I will test x86 at 
least today. I no longer can test Sparc.

Expect a call for a vote at the end of next week unless I get some indication 
people are doing additional testing.

-- Scott

Second 3.2.0 beta available

[Cantor, Scott]

I've updated the beta [1] with the distribution fixes, and one code addition 
[2].

I'll let this one sit for a few days or so for testing and publish a release 
candidate next week. I have not tested Solaris yet, but I will test x86 at 
least today. I no longer can test Sparc.

Expect a call for a vote at the end of next week unless I get some indication 
people are doing additional testing.

-- Scott

Re: Integrating CMake support for xerces

[Cantor, Scott]

On 5/17/17, 11:11 AM, "rle...@codelibre.net"  wrote:

> I've attached a followup patch, also on my cmake-trunk github branch, 
> which does this.  With this patch applied, you should get identical 
> versioning to Autoconf and Visual Studio.

Great, I'm WfH today but I'll see what it does on OS X today and re-test 
Windows tomorrow at the office.

Maybe we could look at doing the svn merge next week?

-- Scott

Re: Integrating CMake support for xerces

[Cantor, Scott]

On 5/17/17, 12:21 PM, "rle...@codelibre.net"  wrote:

> I spoke too soon; it's not working for the VS generators on Windows when 
> using multiple configurations.  I'll fix this up tomorrow.

FWIW, the names currently are the same for 32 and 64 builds. That probably is 
as much because of the timing of them being added, but it does also relate to 
the cross-platform point you had, people on Windows doing dual arch builds 
don't tend to use different names for the files (at least not that I've seen) 
since they tend to just copy their old makefiles and projects to 64-bit.

-- Scott



-
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

[Cantor, Scott]

> Additionally, if anyone wanted to review and test the patch, it's
> attached to the above ticket and also available here:
> https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1

Playing with this now, I had two issues I wanted to ask about. One is that it 
looks like there definitely is a lot of overlap with the material we have to 
maintain for autoconf, and I'm just concerned about the dual maintenance of it 
or the possibility of it falling out of sync since nobody else really knows 
cmake.

Leaving aside whether it's a good or bad idea, if we wanted to standardize on 
this, does the cmake system generate actual autoconf-compatible build files 
(i.e. you run configure?) or does it take over that role. I think the latter is 
a non-starter given the prevalence of autoconf assumptions across the 
landscape. And if so, that does raise maintenance concerns.

Secondly, I'm mainly playing with the Windows side of this, and I was unclear 
if it's possible to generate solution files for both 32- and 64-bit at once? It 
looks like it picks one to do at a time so that if you had to build both you'd 
have to generate the whole set of files twice in between or use separate 
unpacked trees, etc. Is that correct?

-- Scott

RE: Integrating CMake support for xerces

[Cantor, Scott]

> Secondly, I'm mainly playing with the Windows side of this, and I was unclear
> if it's possible to generate solution files for both 32- and 64-bit at once? 
> It
> looks like it picks one to do at a time so that if you had to build both you'd
> have to generate the whole set of files twice in between or use separate
> unpacked trees, etc. Is that correct?

Never mind, I see the instructions now for running it in separate directories 
now.

-- Scott



-
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

[Cantor, Scott]

One issue I did notice on the Windows side is that the DLL names are different 
from the existing convention. I would have to personally adjust them back and I 
don't think we'd have any reason to want them changed, so I assume that could 
be adjusted back?

-- Scott


-
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

[Cantor, Scott]

Roger,

Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp 
files "pre-cmake"? IIRC, I think those are the hardwired versions used in the 
old builds.

I don't want to leave them on trunk if they're going to atrophy and I don't 
really imagine we'd be doing anything to ensure they worked if the solution 
files came from cmake now.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Upporting status

[Cantor, Scott]

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