Re: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

2023-01-25 Thread Noel Butler

On 24/01/2023 22:08, Graham Leggett via dev wrote:


On 24 Jan 2023, at 02:02, Noel Butler  wrote:

This is a result of apr-util 1.6 STILL NOT patched for mariadb or 
mysql 10 plus


https://bz.apache.org/bugzilla/show_bug.cgi?id=61517#c5


If you prepare a patch for 1.6 I can take a look.

Is it possible to backport this to v1.6 given our rules?

Regards,
Graham


The patch referenced, works on 1.6.1, its the same patch IIRC being 
applied by RedHat, is applied by PV at Slackware, and probably Debian 
too because modern (past few years of apru using *sql) wont build 
otherwise.


The "comment linked" indicates you yourself applied this to 1.7 trunk 
for APRU, I'm dismayed you didn't apply it to 1.6 line as well if its 
still supported, apr/apru devs may all run trunk version, but the 
general-populaces do not, they tend not to run "alphas or betas" in 
production networks :)


I'm at a loss to comprehend the project is about to release a new APRU 
after 5 years or so that is still so outdated its pretty much useless to 
all current supported recent distros because it wont build without them 
patching what should be patched here two years ago or so.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

2023-01-25 Thread Helmut K. C. Tessarek

On 2023-01-23 13:57, Eric Covener wrote:

1.6.2-rc2 is here:


I think this release should be on hold until the patch that has been available 
for 5 years made it into the code base.


While the main devs are happy with svn, most other devs prefer git and PRs for 
development. In this regard httpd and apr/apr-util make it rather complicated 
to actually contribute. This is my personal opinion. I don't want to start a 
flame war here. I just wanted to express my opinion.


However, the fact that someone has been trying to get something merged for 5 
years, let me please say that again, for 5 years, is a joke.


Anyone who is responsible for this project should be ashamed.

I understand that SW projects all have differrent styles, rules and cadence, 
but this is just not acceptable.


It's not that there is an apr-util release every 6 weeks.

I have thought long and hard, whether I should even voice my opinion, but I 
think it is important that you get some honest feedback.


Sorry, if I sounded harsh and offended anyone.

Cheers,
  K. C.

--
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature


Re: HOLD apr-1.7.1-rc2

2023-01-25 Thread William Kimball Jr.

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: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

2023-01-25 Thread Eric Covener
I only count two binding (PMC) votes, in case anyone can be enticed.

On Tue, Jan 24, 2023 at 9:37 AM Jim Jagielski  wrote:
>
>
>
> > On Jan 23, 2023, at 1:57 PM, Eric Covener  wrote:
> >
> > 1.6.2-rc2 is here:
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-util-1.6.2
> >  [X]  +1 looks great!
> >  [  ]  -1 something is broken
> >
> > I will let the vote run through mid-week and then try to finalize APR
> > and APU on Thursday if I can, else early the week after.
>
> +1: macOS/Xcode
>
> Thx for RMing!
>


-- 
Eric Covener
cove...@gmail.com


Re: HOLD apr-1.7.1-rc2

2023-01-25 Thread Eric Covener
On Wed, Jan 25, 2023 at 1:53 PM William Kimball Jr.
 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


HOLD apr-1.7.1-rc2

2023-01-25 Thread William Kimball Jr.
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: VOTE: Release apr-1.7.1-rc2 as 1.7.1

2023-01-25 Thread Eric Covener
On Tue, Jan 24, 2023 at 2:49 PM William Kimball Jr.
 wrote:
>
> I'm sorry to pester, but I've been supporting this patch by hand for several 
> years; I'd really like to get this fix into APR so I no longer need to.  This 
> is an important security fix; it adds long-missing TLS to MySQL DB 
> connections.
>
> When I last followed all instructions given to me, I was led to believe that 
> opening the BZ and providing the patch -- and then providing a second patch 
> by request from this list -- was everything I was expected to do.  Several 
> years later, what more can I do to get this security patch"merged"?
>
> Thank you all, very much for your patience and any guidance,

Probably best to spin off to another thread.


Re: VOTE: Release apr-1.7.1-rc2 as 1.7.1

2023-01-25 Thread Yann Ylavic
On Fri, Jan 20, 2023 at 1:44 AM Eric Covener  wrote:
>
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1

[X]  +1 looks great!

Testing on Debian 11 and 12+ (bookwork/sid) using apr-1.7.1(-rc2).

No test failure, checksum/signature ok.

Thanks Eric!

Regards;
Yann.