You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William Kimball Jr." <ww...@kimballstuff.com> on 2023/01/25 18:54:01 UTC
HOLD apr-1.7.1-rc2
Eric Covener has instructed me to spin this discussion off to another
thread, so here it is.
Way back in 2018, I submitted
https://bz.apache.org/bugzilla/show_bug.cgi?id=62342 (apr_dbd_mysql
Lacks TLS Support). Data exfiltration is a serious threat to
businesses. I found that MySQL connections using APR were exposed and
there was no way to encrypt them via the library. So, I volunteered my
time to offer the necessary patch to close this serious security risk.
New to the APR list and process, I asked for guidance as to how to
submit my work. I followed every instruction provided to me, even when
I was instructed to submit a second patch for a future APR 2.x. Now
going on 5 years later, my contribution is still missing from APR.
I can't state this enough: this is a serious security threat. MySQL
connections need TLS support from APR. This isn't a "feature"; it is a
"security" issue. We should all care very deeply about this.
I'm asking that the next release of APR be held until this important fix
is merged in.
Thank you all very much for your time,
William Kimball, Jr. MBA, MSIS
Re: HOLD apr-1.7.1-rc2
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jan 25, 2023 at 4:51 PM William Kimball Jr.
<ww...@kimballstuff.com> wrote:
>
> On 1/25/2023 3:16 PM, Eric Covener wrote:
>
>
> I can't state this enough: this is a serious security threat. MySQL connections need TLS support from APR. This isn't a "feature"; it is a "security" issue. We should all care very deeply about this.
>
> I think it is/can be both a feature and a security issue. I don't
> think the project can handle it as a vulnerability.
>
> The title of "vulnerable" is shifted to any organization which uses APR in its present state for MySQL connections where the client and server are on different machines/interfaces. That's not a vulnerability in APR itself but it is a serious security issue that can be fixed only within APR.
>
>
> I'm asking that the next release of APR be held until this important fix is merged in.
>
> DBD is part of apr-util, so this is more about the proposed
> apr-util-1.6.2 release. I am not sure it meets the (admittedly
> unusual) project versioning rules for to be included in a micro
> update. It is both new function and changed interpretation of
> arguments. Others may know/feel differently here.
>
> This is confusion that has stymied every attempt I've so far made to get this patch merged in. I'll do whatever is necessary to see this through if anyone can offer a clear path to do so. I've been at this same issue for five years.
>
> Regardless, I don't think it meets the bar to hold up a release. It is
> not a regression.
>
> APR releases are so rare. I fear that this serious security issue will remain open for years to come.
>
> Some high level feedback on the patch:
> - is the example argument to cipher really correct? It is a single
> protocol (tlsversion?) and not a "list of ciphers".
> - The license should not be displaced by the comments added to the top
> of the file
> - I think a small percent of the top-of-file comment should be moved
> in-line to wherever it's useful and the rest left for the bugzilla
> entry.
> - I think the parameters should be mentioned in doxygen in apr_dbd.h
> - Should it fail if TLS parms are provided but the mysql version macro
> will ignore it?
> - Is there any impact to mariadb?
> - c99 comments (//) should not be used
>
> Wow; thanks! I'd have addressed any and all such feedback so many years ago had it been given! Is there a PR process I can initiate to handle feedback like this at the file-line level? Many years ago, I didn't have access to such a mechanism. Since then, I believe I've seen some traffic indicating a "new" GitHub avenue. I have a handful of projects on GitHub and would be perfectly comfortable using it for this.
There is a system where pull requests can be submitted against e.g.
https://github.com/apache/apr/tree/trunk
https://github.com/apache/apr-util/tree/1.7.x
https://github.com/apache/apr-util/tree/1.6.x
They can be reviewed on GH, but are merged an ASF-specific way because
the authoritative source is SVN.
Re: HOLD apr-1.7.1-rc2
Posted by "William Kimball Jr." <ww...@kimballstuff.com>.
On 1/25/2023 3:16 PM, Eric Covener wrote:
>
>> I can't state this enough: this is a serious security threat. MySQL connections need TLS support from APR. This isn't a "feature"; it is a "security" issue. We should all care very deeply about this.
> I think it is/can be both a feature and a security issue. I don't
> think the project can handle it as a vulnerability.
The title of "vulnerable" is shifted to any organization which uses APR
in its present state for MySQL connections where the client and server
are on different machines/interfaces. That's not a vulnerability in APR
itself but it is a serious security issue that can be fixed only within APR.
>
>> I'm asking that the next release of APR be held until this important fix is merged in.
> DBD is part of apr-util, so this is more about the proposed
> apr-util-1.6.2 release. I am not sure it meets the (admittedly
> unusual) project versioning rules for to be included in a micro
> update. It is both new function and changed interpretation of
> arguments. Others may know/feel differently here.
This is confusion that has stymied every attempt I've so far made to get
this patch merged in. I'll do whatever is necessary to see this through
if anyone can offer a clear path to do so. I've been at this same issue
for five years.
> Regardless, I don't think it meets the bar to hold up a release. It is
> not a regression.
APR releases are so rare. I fear that this serious security issue will
remain open for years to come.
> Some high level feedback on the patch:
> - is the example argument to cipher really correct? It is a single
> protocol (tlsversion?) and not a "list of ciphers".
> - The license should not be displaced by the comments added to the top
> of the file
> - I think a small percent of the top-of-file comment should be moved
> in-line to wherever it's useful and the rest left for the bugzilla
> entry.
> - I think the parameters should be mentioned in doxygen in apr_dbd.h
> - Should it fail if TLS parms are provided but the mysql version macro
> will ignore it?
> - Is there any impact to mariadb?
> - c99 comments (//) should not be used
Wow; thanks! I'd have addressed any and all such feedback so many years
ago had it been given! Is there a PR process I can initiate to handle
feedback like this at the file-line level? Many years ago, I didn't have
access to such a mechanism. Since then, I believe I've seen some
traffic indicating a "new" GitHub avenue. I have a handful of projects
on GitHub and would be perfectly comfortable using it for this.
Re: HOLD apr-1.7.1-rc2
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jan 25, 2023 at 1:53 PM William Kimball Jr.
<ww...@kimballstuff.com> wrote:
>
> Eric Covener has instructed me to spin this discussion off to another thread, so here it is.
>
> Way back in 2018, I submitted https://bz.apache.org/bugzilla/show_bug.cgi?id=62342 (apr_dbd_mysql Lacks TLS Support). Data exfiltration is a serious threat to businesses. I found that MySQL connections using APR were exposed and there was no way to encrypt them via the library. So, I volunteered my time to offer the necessary patch to close this serious security risk.
>
> New to the APR list and process, I asked for guidance as to how to submit my work. I followed every instruction provided to me, even when I was instructed to submit a second patch for a future APR 2.x. Now going on 5 years later, my contribution is still missing from APR.
>
> I can't state this enough: this is a serious security threat. MySQL connections need TLS support from APR. This isn't a "feature"; it is a "security" issue. We should all care very deeply about this.
I think it is/can be both a feature and a security issue. I don't
think the project can handle it as a vulnerability.
> I'm asking that the next release of APR be held until this important fix is merged in.
DBD is part of apr-util, so this is more about the proposed
apr-util-1.6.2 release. I am not sure it meets the (admittedly
unusual) project versioning rules for to be included in a micro
update. It is both new function and changed interpretation of
arguments. Others may know/feel differently here.
Regardless, I don't think it meets the bar to hold up a release. It is
not a regression.
Some high level feedback on the patch:
- is the example argument to cipher really correct? It is a single
protocol (tlsversion?) and not a "list of ciphers".
- The license should not be displaced by the comments added to the top
of the file
- I think a small percent of the top-of-file comment should be moved
in-line to wherever it's useful and the rest left for the bugzilla
entry.
- I think the parameters should be mentioned in doxygen in apr_dbd.h
- Should it fail if TLS parms are provided but the mysql version macro
will ignore it?
- Is there any impact to mariadb?
- c99 comments (//) should not be used