Apache CLA for small contributions
Hi Scott, I wanted to check with you what the policy was regarding the requirement for an Apache CLA for code contributions. Does this apply for the case of simple and obvious one-liners and other fairly trivial fixes as opposed to more substantial work which is actually creative? Are there any official Apache guidelines here? Is there any allowable discretion? In the case of some of the open PRs on GitHub, like https://github.com/apache/xerces-c/pull/7/files and https://github.com/apache/xerces-c/pull/8/filesfor example, is there a requirement to insist on a CLA for these? Were we to independently redo this, the solutions would be exactly the same. And https://github.com/apache/xerces-c/pull/3/files boils down to a single #if addition along with a trivial documentation update. Thanks, Roger
Re: Branching for 3.3 work?
On 3/6/20, 9:56 AM, "Boris Kolpackov" wrote: > I am not aware though from the names internal/ and dom/impl/ should be > off-limits while everything else is probably fair game. I'm happy if we decide we just say that since it addresses this particular case, but names aside I don't think there was a formal page saying it. If we agree on that, I can do an update the release policy material to expand it to "Versioning and API policy". > The documentation is in "What are the release policies for Xerces-C++?": Right, but it's the question of what actually is an API that I didn't think was formally addressed, leaving one to assume all of it is. -- Scott
Re: Branching for 3.3 work?
Cantor, Scott writes: > I may have mispoke in that issue too: is there any formal definition of > which include directories are "API" and which should be off limits for > library clients? I am not aware though from the names internal/ and dom/impl/ should be off-limits while everything else is probably fair game. > I'm not aware of any such documentation so my impression is compatibly > changing any callable or inheritable API (thus the ABI) would be a minor > bump. The documentation is in "What are the release policies for Xerces-C++?": https://xerces.apache.org/xerces-c/faq-contributing-3.html#faq-2 In summary, patch releases are ABI-compatible, minor -- API compatible but not necessarily ABI-compatible (thus dependents must be recompiled), and major are API-breaking. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Branching for 3.3 work?
On 3/6/20, 9:23 AM, "Boris Kolpackov" wrote: > Ok, makes sense, thanks. There's also apparently some movement on 2188 from the Debian team, they may have a fix for the open security issue, but it may require a 3.3 anyway. I may have mispoke in that issue too: is there any formal definition of which include directories are "API" and which should be off limits for library clients? I'm not aware of any such documentation so my impression is compatibly changing any callable or inheritable API (thus the ABI) would be a minor bump. -- Scott
[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053458#comment-17053458 ] Scott Cantor commented on XERCESC-2188: --- My impression is that your proposed fix is probably a good one, but seems like it's likely to require a bump to 3.3 unless the push method is private. The Xerces project has no proper API definition/policy, so there's no allowance for anything being "internal" if it's callable unfortunately. But we were just talking about possibly branching for that. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Branching for 3.3 work?
Cantor, Scott writes: > Normally I wouldn't be keen to branch now if the next patch was to 3.2, > but because the changes are so minimal now, maintaining patches to two > branches would not be very much work. Ok, makes sense, thanks. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053450#comment-17053450 ] Scott Cantor commented on XERCESC-2188: --- I was not aware, thank you. I'm happy to look, but the simple fact is that I don't know this code and so I can't even begin to evaluate any proposed fix with any confidence. I don't use the DTD code, so I can't do any independent testing either. I think Red Hat's position that a denial of service via memory leak is superior to a crash is defensible too, but they didn't make that argument, they simply silently did it without any explanation to their deployers. > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Branching for 3.3 work?
On 3/6/20, 12:01 AM, "Boris Kolpackov" wrote: > Just to confirm my understanding, you would like to create the 3.2-series > branch in order to release 3.2.3 with some cherry-picked commits, correct? That's the intended branch, but the purpose isn't to immediately release a 3.2.3, it's to enable some amount of future work that would have to be done as a 3.3, without preventing another 3.2 patch. > If so, I am wondering why not instead go ahead and release master as 3.3? There isn't any specific ommitment to do the work on a particular schedule. Since the current set of committers are all largely not able to work steadily on Xerces, it was a way of allowing work that somebody wanted to do to happen on whatever schedule they can manage so that if they happen to have some time, there's nothing stopping them. Normally I wouldn't be keen to branch now if the next patch was to 3.2, but because the changes are so minimal now, maintaining patches to two branches would not be very much work. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053366#comment-17053366 ] Sylvain Beucler commented on XERCESC-2188: -- For the record, there is another patch attempt from Debian: [https://lists.debian.org/debian-lts/2020/01/msg00055.html ]though it didn't make it to the xerces c-dev mailing list (despite several attempts). I'd be happy to provide a formalized patch here - is there upstream interest in fixing/reviewing this issue? > Use-after-free on external DTD scan > --- > > Key: XERCESC-2188 > URL: https://issues.apache.org/jira/browse/XERCESC-2188 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, > 3.1.4, 3.2.1, 3.2.2 >Reporter: Scott Cantor >Priority: Major > Attachments: Apache-496067-disclosure-report.pdf > > > This is a record of an unfixed bug reported in 2018 in the DTD scanner, per > the attached PDF, corresponding to CVE-2018-1311. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053133#comment-17053133
]
Rasmus Thomsen commented on XERCESC-2194:
-
https://github.com/apache/xerces-c/pull/8
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] Cogitri opened a new pull request #8: cmake: use HAVE_SIZE_OF_S{, S}IZE_T to check if it's available
Cogitri opened a new pull request #8: cmake: use HAVE_SIZE_OF_S{,S}IZE_T to
check if it's available
URL: https://github.com/apache/xerces-c/pull/8
Previously if(SIZE_OF_S{,S}IZE_T) was used, which apparently isn't
reliable on some platforms/CMake versions. See XERCESC-2194
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053130#comment-17053130
]
Rasmus Thomsen commented on XERCESC-2194:
-
So I just tested this on our Windows machine and it appears that
SIZE_OF_SSIZE_T is an empty string, but somehow CMake still evaluates that as
true (?). We're using CMake 3.12.1. I'll open a PR for it :)
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
