My project's older branch has a dependency on Xerces for historical
reasons, and we were made aware of an old CVE from 2013 [1] that
apparently has been corrected in trunk as of 16 months ago [2], but we're
trying to assess our options here (the most unpleasant being to fork if
that's the only way
On 10/16/14, 3:33 PM, "Michael Glavassevich" wrote:
>
>Long overdue to have a new release but not likely in the imminent future.
Thanks, I appreciate the update.
>
>Would be great if we had more volunteers who could dedicate time to that.
I already do so on the C++ side, including as essential
On 3/4/15, 4:56 PM, "Michael Glavassevich" wrote:
>
>There has been some work done on the trunk [1] to make it easier for
>users
>to protect themselves but it isn't likely to change any defaults. Users
>need to configure XML parsers appropriately for their scenario and there
>are plenty of w
On 3/4/15, 5:08 PM, "Jim Manico" wrote:
>With respect, XXE is a massive vulnerability that is turned off by
>default in Java 8 as well as IBM parsers. Is there any proof or risk
>model I could provide to convince Xerces to turn this off by default?
+1
And it's not the only unfixed vulnerabi
On 3/4/15, 5:21 PM, "Jim Manico" wrote:
>How can I help? I'm happy to submit a patch if you like... This is a
>fairly critical security issue and I'm willing to get my hands dirty and
>help code? wash your car? free trips to Hawaii? What do need?
If you're directing that question to me,
On 3/4/15, 6:10 PM, "Michael Glavassevich" wrote:
>
>The defect you're referring to had nothing to do with DTDs or entities.
Which I acknowledged. You still have an unreleased security fix that is
*not* a function of "applications configuring the parser correctly".
-- Scott
On 3/4/15, 6:23 PM, "Michael Glavassevich" wrote:
>
>-1. XXE is not a vulnerability in the parser. It may be a vulnerability
>for an application/product, but that is the developer's responsibility to
>apply proper configuration to protect themselves in the right context.
The issue is a trade-
On 3/4/15, 6:34 PM, "Michael Glavassevich" wrote:
>
>And I was pointing out that it's irrelevant to Jim's concern.
I'm betting Jim's concern is with the parser being secure, period, not
just in one specific way, but he can speak for himself.
>If you're interested in seeing a release which rol
> is there a procedure for reporting security-related bugs in Xerces-J? I
> suspect
> that bugs reported through Jira are directly visible to everyone, so that this
> approach might not be suitable for security issues.
http://apache.org/security/
-- Scott
--
On 1/14/18, 10:30 PM, "Will Herrmann" wrote:
> I’m interested in becoming a committer, although admittedly, I’m only
> interested in building a new release that fixes
> this bug (which was previously stated to already be in the code). What do I
> need to do to make that happen?
Probably the b
On 1/15/18, 5:41 PM, "Will Herrmann" wrote:
> It’s necessary to get my employer on file even if I’m not doing it on company
> time?
That depends on the jurisdiction, I couldn't answer that for you. Most US
states are, I think, work for hire, meaning your employer owns anything you do
that is
On 1/15/18, 5:47 PM, "Will Herrmann" wrote:
> Alright, in that case, how do I go about getting an Apache CLA on file with
> my employer being involved?
Well, the CLA files are split into the two types.
http://apache.org/dev/new-committers-guide#cla
The Corporate one is the one that would hand
+1 from me (re-sending to j-users, I may not be on j-dev).
Scott Cantor
canto...@osu.edu
Digital Security and Trust
The Ohio State University
Thanks Mukul. Here's my +1.
Michael Glavassevich
Software Development
IBM Toronto Lab
E-mail: mrgl...@ca.ibm.com
13 matches
Mail list logo
