Re: [QUERY] Regarding project websites containing release candidates

[Eric Covener]

I think the URL is only used in a trivial part of the release process
(vote email), I will ask for help from users@infra in a few days if
this thread is quiet.

On Mon, Sep 11, 2023 at 11:49 AM Daniel Gruno  wrote:
>
> Hello, APR and Perl projects,
> During a review of project websites, it was found that both
> apr.apache.org and perl.apache.org have copies of release candidates
> from dist.apache.org pulled into the website, at
> https://apr.apache.org/dev/ and https://perl.apache.org/dev/ respectively.
>
> As we'd very much like to avoid mixing the two distinct services
> (websites and project artifacts), the infra team would appreciate it if
> these URLs could instead just redirect to their dist.apache.org
> location. If the projects need assistance in making this change, they
> are of course welcome to contact us at us...@infra.apache.org
>
> With regards,
> Daniel on behalf of ASF Infra.
>


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

Re: svn commit: r1909176 - in /apr/site/trunk/xdocs: download.xml index.xml

[Eric Covener]

I missed this email somehow, but it seems the same was reported and
fixed by rpluem. I updated the scripts for the missing pattern/steps
for next time. Thanks.

On Tue, Apr 18, 2023 at 12:37 AM Christophe JAILLET
 wrote:
>
> Le 16/04/2023 à 16:35, cove...@apache.org a écrit :
> > Author: covener
> > Date: Sun Apr 16 14:35:27 2023
> > New Revision: 1909176
> >
> > URL: http://svn.apache.org/viewvc?rev=1909176=rev
> > Log:
> > publishing release apr-1.7.4
> >
> > Modified:
> >  apr/site/trunk/xdocs/download.xml
> >  apr/site/trunk/xdocs/index.xml
> >
> > Modified: apr/site/trunk/xdocs/download.xml
> > URL: 
> > http://svn.apache.org/viewvc/apr/site/trunk/xdocs/download.xml?rev=1909176=1909175=1909176=diff
> > ==
> > --- apr/site/trunk/xdocs/download.xml (original)
> > +++ apr/site/trunk/xdocs/download.xml Sun Apr 16 14:35:27 2023
> > @@ -50,28 +50,28 @@ list of mirrors.
> >
> >   
> >
> > -APR 1.7.3 is the best available version
> > +APR 1.7.4 is the best available version
> >
> >   APR is the base portability library.
> >
> >   
> >
> >   Unix Source:
> > -apr-1.7.3.tar.gz
> > -[https://www.apache.org/dist/apr/apr-1.7.3.tar.gz.asc;>PGP]
> > -[ > href="https://www.apache.org/dist/apr/apr-1.7.3.tar.gz.sha256;>SHA256]
> > +apr-1.7.4.tar.gz
> > +[https://www.apache.org/dist/apr/apr-1.7.4.tar.gz.asc;>PGP]
> > +[ > href="https://www.apache.org/dist/apr/apr-1.7.4.tar.gz.sha256;>SHA256]
> >   
> >
> >   Unix Source:
> > -apr-1.7.3.tar.bz2
> > -[https://www.apache.org/dist/apr/apr-1.7.3.tar.bz2.asc;>PGP]
> > -[ > href="https://www.apache.org/dist/apr/apr-1.7.3.tar.bz2.sha256;>SHA256]
> > +apr-1.7.4.tar.bz2
> > +[https://www.apache.org/dist/apr/apr-1.7.4.tar.bz2.asc;>PGP]
> > +[ > href="https://www.apache.org/dist/apr/apr-1.7.4.tar.bz2.sha256;>SHA256]
> >   
> >
> >   Win32 Source:
> > - > href="[preferred]/apr/apr-1.7.3-win32-src.zip">apr-1.7.3-win32-src.zip
> > -[ > href="https://www.apache.org/dist/apr/apr-1.7.3-win32-src.zip.asc;>PGP]
> > -[ > href="https://www.apache.org/dist/apr/apr-1.7.3-win32-src.zip.sha256;>SHA256]
> > + > href="[preferred]/apr/apr-1.7.4-win32-src.zip">apr-1.7.4-win32-src.zip
> > +[ > href="https://www.apache.org/dist/apr/apr-1.7.4-win32-src.zip.asc;>PGP]
> > +[ > href="https://www.apache.org/dist/apr/apr-1.7.4-win32-src.zip.sha256;>SHA256]
> >   
> >
> >   Other files
> >
> > Modified: apr/site/trunk/xdocs/index.xml
> > URL: 
> > http://svn.apache.org/viewvc/apr/site/trunk/xdocs/index.xml?rev=1909176=1909175=1909176=diff
> > ==
> > --- apr/site/trunk/xdocs/index.xml (original)
> > +++ apr/site/trunk/xdocs/index.xml Sun Apr 16 14:35:27 2023
> > @@ -24,7 +24,7 @@ or features.
> >   libraries are
> >
> >   
> > -  APR 1.7.3, released February 1, 2023
> > +  APR 1.7.4, released April 16, 2023
> > APR-util 1.6.3, released February 1, 2023
> > APR-iconv 1.2.2, released October 22, 2017
> >   
> > @@ -32,7 +32,7 @@ libraries are
> >   
> >
> >   
> > -Apache Portable Runtime 1.7.3 Released
> > +Apache Portable Runtime 1.7.4 Released
> >
> >   
> >  The Apache Software Foundation and the Apache Portable Runtime
> >
> >
> >
>
> Hi,
>
> I don't know if something went wrong or if more time is needed, but
> theses changes are not yet visible on:
> https://apr.apache.org/
>
> CJ
>


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

Re: [VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

[Eric Covener]

vote passes with following binding +1 and no other votes:

steffenal, ylavic, kotkov, covener, jailletc36

On Wed, Apr 12, 2023 at 10:25 PM Eric Covener  wrote:
>
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/apr/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball apr-1.7.4-rc1 as 1.7.4:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
>
>
> The SVN candidate source is found at tags/1.7.4-rc1-candidate.
>
> --
> Eric Covener
> cove...@gmail.com



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

Re: [VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

[Eric Covener]

On Wed, Apr 12, 2023 at 10:25 PM Eric Covener  wrote:
>
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/apr/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball apr-1.7.4-rc1 as 1.7.4:
> [x] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.


my +1 aix/xlc/ppc64

usual suspects only

Failed TestsTotal   FailFailed %
===
testprocmutex   6  2 33.33%
testsock   17  1  5.88%

Re: [VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

[Eric Covener]

On Thu, Apr 13, 2023 at 1:08 PM Evgeny Kotkov
 wrote:
>
> Eric Covener  writes:
>
> > Hi all,
> >
> > Please find below the proposed release tarball and signatures:
> >
> > https://dist.apache.org/repos/dist/dev/apr/
>
> First time voting for an APR release, but isn't apr-1.7.4-rc1-win32-src.zip
> missing from the set of artifacts?

yes, omission in porting the httpd automation. I manually added now.

Re: [VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

[Eric Covener]

New for this release we are only toggling it on the release tag (sic),
similar to httpd release process.

On Thu, Apr 13, 2023, 6:42 AM Yann Ylavic  wrote:

> On Thu, Apr 13, 2023 at 12:16 PM SteffenAL  wrote:
> >
> > it's me.  I build from svn, and there is :
> >
> > #define APR_IS_DEV_VERSION
>
> Yeah, this is restored immediately after tagging to not let a branch
> in a "release" state.
> You could checkout tags/apr-1.7.4-rc1 rather than branches/1.7.x for
> testing, the vote is about the tarballs but I suppose testing the tag
> is fine too if it helps (maybe related with Windows' CRLF vs tarball's
> LF in the source files in your case..).
>
>
> Regards;
> Yann.
>

[VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

[Eric Covener]

Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/apr/

I would like to call a VOTE over the next few days to release
this candidate tarball apr-1.7.4-rc1 as 1.7.4:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:


The SVN candidate source is found at tags/1.7.4-rc1-candidate.

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

Re: Release APR 1.7.4?

[Eric Covener]

On Wed, Apr 12, 2023 at 11:12 AM Evgeny Kotkov via dev
 wrote:
>
> Hi everyone,
>
> Unfortunately, one of the fixes in APR 1.7.3 that was authored by me has
> caused a significant regression, where writing to files opened with both
> APR_FOPEN_APPEND and APR_FOPEN_BUFFERED now may not properly append
> the data on Windows.  The issue has been reported in [1].
>
> Compared to the potential impact of the regression, the original fix seems to
> be of lesser concern, so I reverted the change in r1909088 [2] and backported
> it to 1.7.x in r1909095 [3].
>
> Would it be feasible to release 1.7.4 with a fix for this regression?
>
> (I can try to RM if needed, although in such a case it would be my first time
>  preparing an APR release.)

I will RM but it might be a bit piecemeal between now and the weekend.
  At the mercy of a lot of inflexible $bigco stuff.

Hoping to improve a little this time by porting more of icings amazing
httpd release work.

Re: [VOTE] Release apr-1.7.3

[Eric Covener]

On Mon, Mar 27, 2023 at 4:18 AM Ruediger Pluem  wrote:
>
> 1.7.3-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.3
>   [x]  +1 looks great!
>   [  ]  -1 something is broken
>
> I will let the vote run through end-of-week.

+1 AIX/xlc/ppc64 no regression

Re: svn commit: r1907634 - /apr/apr/trunk/include/apr_buckets.h

[Eric Covener]

> This is true, but I see only a low risk of making backports difficult for 
> structures that seem to be set and haven't been touched
> for a long time. And even if we need to touch them we can still backport. It 
> is just more work then.

+1

Re: apr-1.7.2/Apache shared memory now world readable?

[Eric Covener]

On Fri, Feb 10, 2023 at 11:49 AM Ruediger Pluem  wrote:
>
>
>
> On 2/10/23 2:42 AM, Eric Covener wrote:
> >> I think this should be revisited and changed to 600.
> >
> > It seems like all the methods use 0644.  After the change, it's just
> > accessible in the filesystem rather than in the sysv shm ether.
> >
> > It seems like an API gap, APR can't know what the caller expects to do
> > with it (other than it's not anonymous).
> > Today I guess a caller could run with a more conservative umask, or
> > toggle it around calls to apr_shm_create?
> >
>
> I would like to see a more restrictive default, but this cannot be reverted 
> via
> umask. Furthermore we are currently inconsistent as we use 600 for SysV SHM, 
> but 644
> for Posix one.

Thanks,  I see I was looking at the ones with explicit mode literals.

> Maybe time for an
>
> apr_shm_perms_set?

Sounds needed no matter where the default change ends up.  Is there
anything else waiting for a 1.8?

Re: apr-1.7.2/Apache shared memory now world readable?

[Eric Covener]

> I think this should be revisited and changed to 600.

It seems like all the methods use 0644.  After the change, it's just
accessible in the filesystem rather than in the sysv shm ether.

It seems like an API gap, APR can't know what the caller expects to do
with it (other than it's not anonymous).
Today I guess a caller could run with a more conservative umask, or
toggle it around calls to apr_shm_create?

Re: [VOTE] apr 1.7.2 and apr-util 1.6.3

[Eric Covener]

Vote passes with 4 binding votes (thanks to all who voted/reviewed)

+1: covener, rpluem, jorton, ylavic

On Wed, Feb 1, 2023 at 8:22 AM Eric Covener  wrote:
>
> Thanks for the quick votes everyone, I will just give it a couple more
> hours then proceed.
>
> On Wed, Feb 1, 2023 at 4:43 AM SteffenAL  wrote:
> >
> >  +1 All fine on Windows
> >
> > Thanks! Eric
> >
> >
> > --- Original message ---
> > Subject: [VOTE] apr 1.7.2 and apr-util 1.6.3
> > From: Eric Covener 
> > To: dev@apr.apache.org 
> > Date: Tuesday, 31/01/2023 22:23
> >
> > I hosed 1.7.1/1.6.2 and the archives have -rcX in them at the top
> > level. I would like to call for an expedited vote to replace them
> > with version bumps. I will proceed once we get 3 binding +1.
> >
> > I have re-tagged because I think the consensus will be that updating
> > the tarballs and signatures is too confusing.
> >
> > candidates are here:
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-1.7.2 AND apr-util-1.6.3
> >[ ] +1 looks great
> >[ ] -1 something is broken
> >
> >
>
>
> --
> Eric Covener
> cove...@gmail.com



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

Re: [VOTE] apr 1.7.2 and apr-util 1.6.3

[Eric Covener]

Thanks for the quick votes everyone, I will just give it a couple more
hours then proceed.

On Wed, Feb 1, 2023 at 4:43 AM SteffenAL  wrote:
>
>  +1 All fine on Windows
>
> Thanks! Eric
>
>
> --- Original message ---
> Subject: [VOTE] apr 1.7.2 and apr-util 1.6.3
> From: Eric Covener 
> To: dev@apr.apache.org 
> Date: Tuesday, 31/01/2023 22:23
>
> I hosed 1.7.1/1.6.2 and the archives have -rcX in them at the top
> level. I would like to call for an expedited vote to replace them
> with version bumps. I will proceed once we get 3 binding +1.
>
> I have re-tagged because I think the consensus will be that updating
> the tarballs and signatures is too confusing.
>
> candidates are here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.2 AND apr-util-1.6.3
>[ ] +1 looks great
>[ ] -1 something is broken
>
>


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

Re: [VOTE] apr 1.7.2 and apr-util 1.6.3

[Eric Covener]

> For the release of apr-1.7.2 AND apr-util-1.6.3
>   [x]  +1 looks great
>   [  ]  -1 something is broken

+1 for both

[VOTE] apr 1.7.2 and apr-util 1.6.3

[Eric Covener]

I hosed 1.7.1/1.6.2 and the archives have -rcX in them at the top
level.  I would like to call for an expedited vote to replace them
with version bumps.  I will proceed once we get 3 binding +1.

I have re-tagged because I think the consensus will be that updating
the tarballs and signatures is too confusing.

candidates are here:

https://apr.apache.org/dev/dist/

For the release of apr-1.7.2 AND apr-util-1.6.3
  [  ]  +1 looks great
  [  ]  -1 something is broken

bad dir structure in recent releases

[Eric Covener]

It was reported to me that the recent APR/APU uploads have the -rcX
prefix in the source archive.

I think it's too confusing to replace the source zips.
Should I just roll a replacement with a new version bump and call a short vote?

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

Fwd: CVE-2022-25147: Apache Portable Runtime (APR): out-of-bounds writes in the apr_base64 family of functions

[Eric Covener]

-- Forwarded message -
From: Eric Covener 
Date: Tue, Jan 31, 2023 at 10:13 AM
Subject: CVE-2022-25147: Apache Portable Runtime (APR): out-of-bounds
writes in the apr_base64 family of functions
To: , 


Severity: moderate

Description:

Integer Overflow or Wraparound vulnerability in apr_base64 functions
of Apache Portable Runtime Utility (APR-util) allows an attacker to
write beyond bounds of a buffer.\nThis issue affects Apache Portable
Runtime Utility (APR-util) 1.6.1 and prior versions.

Credit:

Ronald Crane (Zippenhop LLC) (reporter)

References:

https://apr.apache.org/
https://www.cve.org/CVERecord?id=CVE-2022-25147



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

CVE-2022-28331: Apache Portable Runtime (APR): Windows out-of-bounds write in apr_socket_sendv function

[Eric Covener]

Severity: moderate

Description:

On Windows, Apache Portable Runtime 1.7.0 and earlier may write beyond the end 
of a stack based buffer in apr_socket_sendv(). This is a result of integer 
overflow.

Credit:

Ronald Crane (Zippenhop LLC) (finder)

References:

https://apr.apache.org/
https://www.cve.org/CVERecord?id=CVE-2022-28331

CVE-2022-24963: Apache Portable Runtime (APR): out-of-bound writes in the apr_encode family of functions

[Eric Covener]

Severity: moderate

Description:

Integer Overflow or Wraparound vulnerability in apr_encode functions of Apache 
Portable Runtime (APR) allows an attacker to write beyond bounds of a buffer.
This issue affects Apache Portable Runtime (APR) version 1.7.0.

Credit:

Ronald Crane (Zippenhop LLC) (finder)

References:

https://apr.apache.org/
https://www.cve.org/CVERecord?id=CVE-2022-24963

Re: [VOTE] release apr-1.6.2-rc3 as APR 1.6.2

[Eric Covener]

On Mon, Jan 30, 2023 at 9:23 AM Eric Covener  wrote:
>
> On Fri, Jan 27, 2023 at 8:42 AM Eric Covener  wrote:
> >
> > 1.6.2-rc3 is here:
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-util-1.6.2
> >   [  ]  +1 looks great
> >   [  ]  -1 something is broken
> >
>
> +1 AIX/xlc/ppc64 no regression.
>
> Given the Friday re-roll, I will hold the vote open an extra 24h (3
> binding +1 as of now) to give time for more feedback.

Vote passes with three binding +1 (ylavic, rpluem, covener), i will
[slowly] proceed on APR and APU.

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

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

[Eric Covener]

RC2 is abandoned in favor of RC3

On Fri, Jan 27, 2023 at 8:45 AM Eric Covener  wrote:
>
> > I would be in favor of hearing further opinions on whether backporting this 
> > to APR-UTIL 1.6 complies with our versioning rules.
> > If it does we should do so and release apr-util 1.6.2 with it.
>
> In the spirit of minimizing further delays, I have backported and
> rolled RC3 so we can bank a vote on it separately from the versioning
> info.



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

Re: [VOTE] release apr-1.6.2-rc3 as APR 1.6.2

[Eric Covener]

On Fri, Jan 27, 2023 at 8:42 AM Eric Covener  wrote:
>
> 1.6.2-rc3 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-util-1.6.2
>   [  ]  +1 looks great
>   [  ]  -1 something is broken
>

+1 AIX/xlc/ppc64 no regression.

Given the Friday re-roll, I will hold the vote open an extra 24h (3
binding +1 as of now) to give time for more feedback.

Re: [VOTE] release apr-1.6.2-rc3 as APR 1.6.2

[Eric Covener]

On Fri, Jan 27, 2023 at 10:12 AM Ruediger Pluem  wrote:
>
>
>
> On 1/27/23 2:42 PM, Eric Covener wrote:
> > 1.6.2-rc3 is here:
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-util-1.6.2
> >   [  ]  +1 looks great
> >   [  ]  -1 something is broken
> >
> > I'd like to call a vote in parallel to the discussion around the
> > suitability for 1.6.x.
> >
> > If there is not a passing vote (or is no versioning consensus) in ~72H
> > I will proceed with rc2 and abandon rc3. Otherwise I will release rc3.
> >
> > I will assume +1'es are orthogonal to the versioning issue and will
> > just gauge the consensus in the two threads.
> >
>
> +1

Just to be sure, this is +1 for rc3 or just the plan?

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

[Eric Covener]

> I would be in favor of hearing further opinions on whether backporting this 
> to APR-UTIL 1.6 complies with our versioning rules.
> If it does we should do so and release apr-util 1.6.2 with it.

In the spirit of minimizing further delays, I have backported and
rolled RC3 so we can bank a vote on it separately from the versioning
info.

[VOTE] release apr-1.6.2-rc3 as APR 1.6.2

[Eric Covener]

1.6.2-rc3 is here:

https://apr.apache.org/dev/dist/

For the release of apr-util-1.6.2
  [  ]  +1 looks great
  [  ]  -1 something is broken

I'd like to call a vote in parallel to the discussion around the
suitability for 1.6.x.

If there is not a passing vote (or is no versioning consensus) in ~72H
I will proceed with rc2 and abandon rc3. Otherwise I will release rc3.

I will assume +1'es are orthogonal to the versioning issue and will
just gauge the consensus in the two threads.

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

Re: HOLD apr-1.7.1-rc2

[Eric Covener]

On Wed, Jan 25, 2023 at 4:51 PM William Kimball Jr.
 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: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

[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

[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

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

[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-util-1.6.2-rc2 as apr-util 1.6.2

[Eric Covener]

On Tue, Jan 24, 2023 at 7:09 AM 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?

I'm not especially tuned into this aspect but it seems OK to me.

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

[Eric Covener]

On Mon, 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
>

+1 aix/xlc/ppc64 no regression (testxlate has never worked)

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

[Eric Covener]

1.6.2-rc2 is here:

https://apr.apache.org/dev/dist/

For the release of apr-util-1.6.2
  [  ]  +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.
-- 
Eric Covener
cove...@gmail.com

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

[Eric Covener]

FYI holding finalization so APU vote can wrap up and be announced together.

On Thu, Jan 19, 2023 at 7:44 PM Eric Covener  wrote:
>
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
>   [  ]  +1 looks great!
>   [  ]  -1 something is broken
>
> I will let the vote run through mid-week.
>
> --
> Eric Covener
> cove...@gmail.com



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

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

[Eric Covener]

On Sat, Jan 21, 2023 at 4:21 PM William Kimball Jr.
 wrote:
>
> I'm sorry if this is not an appropriate thread to ask, but will this release 
> include https://bz.apache.org/bugzilla/show_bug.cgi?id=62342 (apr_dbd_mysql 
> Lacks TLS Support )?  I submitted that fix way back in 2018 and I don't know 
> how to tell whether it has "made it in".

It doesn't appear to be merged

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

[Eric Covener]

On Thu, Jan 19, 2023 at 7:44 PM Eric Covener  wrote:
>
> On Thu, Jan 19, 2023 at 7:44 PM Eric Covener  wrote:
> >
> > 1.7.1-rc1 is here:
>
> rc2 of course
>
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-1.7.1
> >   [  ]  +1 looks great!
> >   [  ]  -1 something is broken
> >
> > I will let the vote run through mid-week.
>
> +1 AIX/ppc64 (no regression) and Ubuntu 20.04/x86_64.

also 100% on solaris/sunstudio/sparc64

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

[Eric Covener]

On Thu, Jan 19, 2023 at 7:44 PM Eric Covener  wrote:
>
> 1.7.1-rc1 is here:

rc2 of course

>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
>   [  ]  +1 looks great!
>   [  ]  -1 something is broken
>
> I will let the vote run through mid-week.

+1 AIX/ppc64 (no regression) and Ubuntu 20.04/x86_64.

VOTE: Release apr-1.7.1-rc2 as 1.7.1

[Eric Covener]

1.7.1-rc1 is here:

https://apr.apache.org/dev/dist/

For the release of apr-1.7.1
  [  ]  +1 looks great!
  [  ]  -1 something is broken

I will let the vote run through mid-week.

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

Re: [VOTE] Release apr-1.7.1

[Eric Covener]

On Thu, Jan 19, 2023 at 12:20 PM Eric Covener  wrote:
>
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
>   [  ]  +1 looks great!
>   [  ]  -1 something is broken

-1 for AIX result.  I have opted-out for AIX in the change in 1906827
and will try a new rc later tonight.

Re: svn commit: r1901037 - in /apr/apr/trunk: CHANGES configure.in

[Eric Covener]

Any pointer to what the problem was?

On Wed, May 18, 2022 at 10:49 AM  wrote:
>
> Author: jim
> Date: Wed May 18 14:48:36 2022
> New Revision: 1901037
>
> URL: http://svn.apache.org/viewvc?rev=1901037=rev
> Log:
> Prefer posix shared mem over SysV in all cases:
>   Have name based order same as anon
>
> Modified:
> apr/apr/trunk/CHANGES
> apr/apr/trunk/configure.in
>
> Modified: apr/apr/trunk/CHANGES
> URL: 
> http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1901037=1901036=1901037=diff
> ==
> --- apr/apr/trunk/CHANGES [utf-8] (original)
> +++ apr/apr/trunk/CHANGES [utf-8] Wed May 18 14:48:36 2022
> @@ -1,10 +1,13 @@
>   -*- coding: utf-8 -*-
>  Changes for APR 2.0.0
>
> +  *) configure: Prefer posix name-based shared memory over SysV IPC.
> + [Jim Jagielski]
> +
>*) configure: Add --disable-sctp argument to forcibly disable SCTP
>   support, or --enable-sctp which fails if SCTP support is not
>   detected.  [Lubos Uhliarik , Joe Orton]
> -
> +
>*) apr_dbm: Add dedicated apr_dbm_get_driver() function that returns
>   details of the driver selected and any error encountered. Add the
>   apr_dbm_open2() function that references the driver. [Graham Leggett]
> @@ -68,7 +71,7 @@ Changes for APR 2.0.0
>   [Oleg Liatte ]
>
>*) Test %ld vs. %lld to avoid compiler emits using APR_OFF_T_FMT, in the
> - case of apparently equivilant long and long long types. [William Rowe]
> + case of apparently equivilant long and long long types. [William Rowe]
>
>*) Recognize APPLE predefined macros as equivilant to DARWIN. [Jim 
> Jagielski]
>
> @@ -210,7 +213,7 @@ Changes for APR 2.0.0
>   [Tom Donovan]
>
>*) Changes to apr_pollset_method_e enum value of APR_POLLSET_POLL and
> - APR_POLLSET_AIO_MSGQ.  Restore APR_POLLSET_POLL to its pre-r1308910
> + APR_POLLSET_AIO_MSGQ.  Restore APR_POLLSET_POLL to its pre-r1308910
>   (April 2012) value, and move APR_POLLSET_AIO_MSGQ ahead. This restores
>   ABI compat with released branches.  [Eric Covener]
>
> @@ -226,7 +229,7 @@ Changes for APR 2.0.0
>*) Add support code to teach valgrind about APR pools, allocators, and
>   bucket allocators. [Stefan Fritsch]
>
> -  *) apr_socket_accept_filter(): The 2nd and 3rd arguments are now
> +  *) apr_socket_accept_filter(): The 2nd and 3rd arguments are now
>   const char * instead of char *.  [Jeff Trawick]
>
>*) apr_brigades: add a check to prevent infinite while loop in case
>
> Modified: apr/apr/trunk/configure.in
> URL: 
> http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?rev=1901037=1901036=1901037=diff
> ==
> --- apr/apr/trunk/configure.in (original)
> +++ apr/apr/trunk/configure.in Wed May 18 14:48:36 2022
> @@ -1235,6 +1235,10 @@ havebeosarea="0"
>  haveos2shm="0"
>  havewin32shm="0"
>  APR_BEGIN_DECISION([namebased memory allocation method])
> +APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
> + func:shmget func:shmat func:shmdt func:shmctl,
> + [haveshmget="1"
> +  APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()])])
>  APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
>   [havemmaptmp="1"
>APR_DECIDE(USE_SHMEM_MMAP_TMP,
> @@ -1244,10 +1248,6 @@ APR_IFALLYES(header:sys/mman.h func:mmap
>   [havemmapshm="1"
>APR_DECIDE(USE_SHMEM_MMAP_SHM,
>[mmap() via POSIX.1 shm_open() on temporary file])])
> -APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
> - func:shmget func:shmat func:shmdt func:shmctl,
> - [haveshmget="1"
> -  APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()])])
>  APR_IFALLYES(header:kernel/OS.h func:create_area,
>   [havebeosshm="1"
>APR_DECIDE(USE_SHMEM_BEOS, [BeOS areas])])
>
>


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

Re: [VOTE] Release apr-1.7.1

[Eric Covener]

On Thu, Jan 19, 2023 at 3:29 PM Eric Covener  wrote:
>
> On Thu, Jan 19, 2023 at 12:20 PM Eric Covener  wrote:
> >
> > 1.7.1-rc1 is here:
> >
> > https://apr.apache.org/dev/dist/
> >
> > For the release of apr-1.7.1
> >   [  ]  +1 looks great!
> >   [  ]  -1 something is broken
> >
> > I will let the vote run through mid-week.
> >
> > I've got no idea what I'm doing here, so I've adopted the -rcX style
> > from recent httpd releases as it's likely many version numbers would
> > be burned otherwise.
> >
> > I am working from
> > https://svn.apache.org/repos/asf/apr/site/trunk/tools/release.sh
> > plus what I can sort out from
> > https://svn.apache.org/repos/asf/httpd/dev-tools/release
>
> Some issues on AIX, 3 tests failing in testshm that worked in 1.7.0
> (no other regressions)
>
> $  grep -ri USE_SHMEM apr-1.7.*/include/apr.h
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_SHM 0
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_ZERO0
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_SHMGET_ANON  0
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_SHMGET   1
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_ANON1
> apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_BEOS 0
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_SHM 1
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_ZERO0
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_SHMGET_ANON  0
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_SHMGET   0
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_ANON1
> apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_BEOS 0
>
> Which is from http://svn.apache.org/viewvc?view=revision=1901038


The failing tests are the name-based tests.

>From the AIX manual (lseek via apr_file_trunc)

   If the FileDescriptor parameter refers to a shared memory
object, the lseek subroutine fails with EINVAL.

...

   EINVAL
The resulting offset would be greater than the maximum
offset allowed for the file or device associated with FileDescriptor.
The lseek subroutine was used with a file
descriptor obtained from a call to the shm_open subroutine.


#if APR_USE_SHMEM_MMAP_SHM
/* FIXME: SysV uses 0600... should we? */
tmpfd = shm_open(shm_name, O_RDWR | O_CREAT | O_EXCL, 0644);
if (tmpfd == -1) {
return errno;
}

status = apr_os_file_put(, ,
 APR_READ | APR_WRITE | APR_CREATE | APR_EXCL,
 pool);
if (status != APR_SUCCESS) {
return status;
}

status = apr_file_trunc(file, new_m->realsize);
if (status != APR_SUCCESS && status != APR_ESPIPE) {
shm_unlink(shm_name); /* we're failing, remove the object */
return status;
}
new_m->base = mmap(NULL, new_m->realsize, PROT_READ | PROT_WRITE,
   MAP_SHARED, tmpfd, 0);

/* FIXME: check for errors */

status = apr_file_close(file);
if (status != APR_SUCCESS) {
return status;
}

Re: [VOTE] Release apr-1.7.1

[Eric Covener]

On Thu, Jan 19, 2023 at 12:20 PM Eric Covener  wrote:
>
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
>   [  ]  +1 looks great!
>   [  ]  -1 something is broken
>
> I will let the vote run through mid-week.
>
> I've got no idea what I'm doing here, so I've adopted the -rcX style
> from recent httpd releases as it's likely many version numbers would
> be burned otherwise.
>
> I am working from
> https://svn.apache.org/repos/asf/apr/site/trunk/tools/release.sh
> plus what I can sort out from
> https://svn.apache.org/repos/asf/httpd/dev-tools/release

Some issues on AIX, 3 tests failing in testshm that worked in 1.7.0
(no other regressions)

$  grep -ri USE_SHMEM apr-1.7.*/include/apr.h
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_SHM 0
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_ZERO0
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_SHMGET_ANON  0
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_SHMGET   1
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_MMAP_ANON1
apr-1.7.0/include/apr.h:#define APR_USE_SHMEM_BEOS 0
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_SHM 1
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_ZERO0
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_SHMGET_ANON  0
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_SHMGET   0
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_MMAP_ANON1
apr-1.7.1-rc1/include/apr.h:#define APR_USE_SHMEM_BEOS 0

Which is from http://svn.apache.org/viewvc?view=revision=1901038

Will have to look further.



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



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

[VOTE] Release apr-1.7.1

[Eric Covener]

1.7.1-rc1 is here:

https://apr.apache.org/dev/dist/

For the release of apr-1.7.1
  [  ]  +1 looks great!
  [  ]  -1 something is broken

I will let the vote run through mid-week.

I've got no idea what I'm doing here, so I've adopted the -rcX style
from recent httpd releases as it's likely many version numbers would
be burned otherwise.

I am working from
https://svn.apache.org/repos/asf/apr/site/trunk/tools/release.sh
plus what I can sort out from
https://svn.apache.org/repos/asf/httpd/dev-tools/release

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

Intent to RM 1.7.1/1.6.2 next week

[Eric Covener]

I intend to take my first crack at RM'ing APR/APU next week.

If anyone has private notes or hints about what happens before/after
release.sh in https://svn.apache.org/repos/asf/apr/site/trunk it would
be appreciated. Otherwise, I will try to stick close to what I can see
in HTTPD:
https://svn.apache.org/repos/asf/httpd/dev-tools/release

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

Re: Remaining breakage on apr-1.7.x branch

[Eric Covener]

On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr  wrote:
>
> Hello friends and collaborators,
>
> I'm still rather certain this change is ABI and API contract-breaking
> on the apr-1.7.x branch, which holds the project hostage for providing
> a well-understood security fix on the legacy branch. Such things
> can't persist, our individual maintenance branches must also observe
> semver, such that anyone could consume a maintenance branch and
> not be API nor ABI broken against the prior sub-version release;
>
> https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf
>
> I'd propose a radical solution, either all of include/* excluding most
> of private / arch/* have no adverse effects on a rebuild, or we revert
> the whole branch to the last stable release, in 7 days. Allow a 7 day
> window to reintroduce critical and desired changes that don't break
> our dev guidelines;
>
> https://apr.apache.org/versioning.html.
>
> All other questions were resolved at least 4 weeks ago, as can
> be observed from include/* changes which alter the incremental
> consumer's observations, github makes this simple;
>
> https://github.com/apache/apr/compare/1.7.0...1.7.x#
>
> So I think we are nearly ready 14 days from now to tag 1.7.1
> and solve this conundrum. If it can be proven than the existing
> 1.7.0 or 1.7.1 builds would be entirely compatible and not break
> developer's expectations when deployed against either 1.7.1
> or 1.7.0 in the next 7 days, my objection is withdrawn and we
> will tag this code in one week, not waiting for 2 weeks.
>
> Who wants to help prove up or down that it should persist and
> work out the back-out as needed? Otherwise I ask the project
> member's permissions to work from a new 1.7.x-rebuild branch
> for the following week based on 1.7.0, and replace 1.7.x with
> the 1.7.x-rebuild branch one week later.

Should we just back out r1896748 (ring strict aliasing thing) out at
this stage?  I think the radical solution is too labor intensive and
unlikely to progress.

Re: svn commit: r1902297 - in /apr/apr/branches/thread-name: include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/

[Eric Covener]

On Tue, Jun 28, 2022 at 3:54 PM Yann Ylavic  wrote:
>
> On Tue, Jun 28, 2022 at 9:24 PM Eric Covener  wrote:
> >
> > Ran out of time but I added a crude check to the branch in 1902326.
>
> Argh, I missed your message (which showed up after I sent mine..).
> Well, two solutions are better than none :)

That is much nicer, I had never seen those checks.
But I think it would trip up on Mac:

NAME
 pthread_setname_np – set the thread name

SYNOPSIS
 #include 

 void
 pthread_setname_np(const char *name);

DESCRIPTION
 The pthread_setname_np() function sets the internal name for the
calling thread to string value specified by name argument.


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

Re: svn commit: r1902297 - in /apr/apr/branches/thread-name: include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/

[Eric Covener]

Ran out of time but I added a crude check to the branch in 1902326.

I noticed at the last moment that Mac has the set function but it is
only for the current thread.

On Tue, Jun 28, 2022 at 2:06 PM Ivan Zhakov via dev  wrote:
>
> On Tue, 28 Jun 2022 at 14:45, Yann Ylavic  wrote:
> >
> > On Tue, Jun 28, 2022 at 1:13 AM  wrote:
> > >
> > > Author: ivan
> > > Date: Mon Jun 27 23:13:52 2022
> > > New Revision: 1902297
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1902297=rev
> > > Log:
> > > On 'thread-name' branch: Add apr_thread_name_get() and 
> > > apr_thread_name_set()
> > > API to get/set thread name.
> > >
> > []
> > > --- apr/apr/branches/thread-name/threadproc/unix/thread.c (original)
> > > +++ apr/apr/branches/thread-name/threadproc/unix/thread.c Mon Jun 27 
> > > 23:13:52 2022
> > []
> > > @@ -277,6 +282,48 @@ APR_DECLARE(apr_thread_t *) apr_thread_c
> > >  #endif
> > >  }
> > >
> > > +APR_DECLARE(apr_status_t) apr_thread_name_set(const char *name,
> > > +  apr_thread_t *thread,
> > > +  apr_pool_t *pool)
> > > +{
> > > +pthread_t td;
> > > +
> > > +size_t name_len;
> > > +if (!name) {
> > > +return APR_BADARG;
> > > +}
> > > +
> > > +if (thread) {
> > > +td = *thread->td;
> > > +}
> > > +else {
> > > +td = pthread_self();
> > > +}
> > > +
> > > +name_len = strlen(name);
> > > +if (name_len >= TASK_COMM_LEN) {
> > > +name = name + name_len - TASK_COMM_LEN + 1;
> > > +}
> > > +
> > > +return pthread_setname_np(td, name);
> >
> > We probably need to check for HAVE_PTHREAD_SETNAME_NP since it's _np
> > (non-portable).
> Thanks for the suggestion!
>
> I'm not so familiar with autoconf stuff (that's why I created branch):
> can I just check for HAVE_PTHREAD_SETNAME_NP or do I need some
> autoconf magic to set it?
>
>
>
> --
> Ivan Zhakov



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

Re: svn commit: r1902297 - in /apr/apr/branches/thread-name: include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/

[Eric Covener]

On Tue, Jun 28, 2022 at 7:45 AM Yann Ylavic  wrote:
>
> On Tue, Jun 28, 2022 at 1:13 AM  wrote:
> >
> > Author: ivan
> > Date: Mon Jun 27 23:13:52 2022
> > New Revision: 1902297
> >
> > URL: http://svn.apache.org/viewvc?rev=1902297=rev
> > Log:
> > On 'thread-name' branch: Add apr_thread_name_get() and apr_thread_name_set()
> > API to get/set thread name.
> >
> []
> > --- apr/apr/branches/thread-name/threadproc/unix/thread.c (original)
> > +++ apr/apr/branches/thread-name/threadproc/unix/thread.c Mon Jun 27 
> > 23:13:52 2022
> []
> > @@ -277,6 +282,48 @@ APR_DECLARE(apr_thread_t *) apr_thread_c
> >  #endif
> >  }
> >
> > +APR_DECLARE(apr_status_t) apr_thread_name_set(const char *name,
> > +  apr_thread_t *thread,
> > +  apr_pool_t *pool)
> > +{
> > +pthread_t td;
> > +
> > +size_t name_len;
> > +if (!name) {
> > +return APR_BADARG;
> > +}
> > +
> > +if (thread) {
> > +td = *thread->td;
> > +}
> > +else {
> > +td = pthread_self();
> > +}
> > +
> > +name_len = strlen(name);
> > +if (name_len >= TASK_COMM_LEN) {
> > +name = name + name_len - TASK_COMM_LEN + 1;
> > +}
> > +
> > +return pthread_setname_np(td, name);
>
> We probably need to check for HAVE_PTHREAD_SETNAME_NP since it's _np
> (non-portable).

FWIW: AFAICT missing on AIX but present on z/OS and "IBM I".  Kind of
a surprising result.

Re: apr_atomic_casptr2() in apr-1.8.x ?

[Eric Covener]

On Fri, Jun 24, 2022 at 10:34 AM Yann Ylavic  wrote:
>
> Daniel proposed in [1] that we introduce apr_atomic_casptr2() to
> resolve the defect in the apr_atomic_casptr() API.
> Namely the correct:
> 1. APR_DECLARE(void*) apr_atomic_casptr(void *volatile *mem, ...);
> Versus the broken:
> 2. APR_DECLARE(void*) apr_atomic_casptr(volatile void **mem, ...);
>
> The problem with 2 is that it does not prevent the compiler from
> caching *mem into a local variable, which would break atomicity.
>
> This is fixed in trunk already where we could change the API to 1, but
> not in 1.x.
> Anyone opposed to the attached patch (for 1.8.x only then)?
>
> Regards;
> Yann.
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=50731#c2

+1

Re: svn commit: r1902176 - /apr/apr/trunk/build/xml.m4

[Eric Covener]

On Thu, Jun 23, 2022 at 3:03 AM Ruediger Pluem  wrote:
>
>
>
> On 6/23/22 1:46 AM, cove...@apache.org wrote:
> > Author: covener
> > Date: Wed Jun 22 23:46:43 2022
> > New Revision: 1902176
> >
> > URL: http://svn.apache.org/viewvc?rev=1902176=rev
> > Log:
> > set -lxml2 in non xml2-config case
> >
> > Closes #36
> >
> > Modified:
> > apr/apr/trunk/build/xml.m4
> >
> > Modified: apr/apr/trunk/build/xml.m4
> > URL: 
> > http://svn.apache.org/viewvc/apr/apr/trunk/build/xml.m4?rev=1902176=1902175=1902176=diff
> > ==
> > --- apr/apr/trunk/build/xml.m4 (original)
> > +++ apr/apr/trunk/build/xml.m4 Wed Jun 22 23:46:43 2022
> > @@ -177,6 +177,7 @@ AC_ARG_WITH([libxml2],
> >  else
> >xml2_CPPFLAGS="-I$withval/include/libxml2"
> >xml2_LDFLAGS="-L$withval/lib64 -L$withval/lib"
> > +  xml2_LIBS="-lxml2"
> >  fi
> >
> >  APR_ADDTO(CPPFLAGS, [$xml2_CPPFLAGS])
> > @@ -186,6 +187,7 @@ AC_ARG_WITH([libxml2],
> >  AC_CHECK_HEADERS(libxml/parser.h, AC_CHECK_LIB(xml2, 
> > xmlCreatePushParserCtxt, [apu_has_libxml2=1]))
> >fi
> >], [
> > +xml2_LIBS="-lxml2"
>
> Why do we need this and if we need it why don't we need
>
> APR_ADDTO(LIBS, [$xml2_LIBS])
>
> as well?
>
> >  AC_CHECK_HEADERS(libxml/parser.h, AC_CHECK_LIB(xml2, 
> > xmlCreatePushParserCtxt, [apu_has_libxml2=1]))
> >  ])
> >  AC_SUBST(apu_has_libxml2)

Just past the diff context this flat block exists:

if test ${apu_has_libxml2} = "1" ; then
  APR_ADDTO(APRUTIL_CPPFLAGS, [$xml2_CPPFLAGS])
  APR_ADDTO(APRUTIL_PRIV_INCLUDES, [$xml2_CPPFLAGS])
  APR_ADDTO(APRUTIL_LIBS, [$xml2_LIBS])
fi

Re: GitHub Actions CI

[Eric Covener]

On Wed, Jun 22, 2022 at 7:53 PM Yann Ylavic  wrote:
>
> On Thu, Jun 23, 2022 at 1:14 AM Eric Covener  wrote:
> >
> > On Wed, Jun 22, 2022 at 10:30 AM Yann Ylavic  wrote:
> > >
> > > On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev  
> > > wrote:
> > > >
> > > > As far I understand Apache Infra recommends to migrate Continuous 
> > > > Integration builds from Travis to GitHub Actions.
> > > >
> > > > I've added initial configuration for GitHub Actions for APR project:
> > > > https://svn.apache.org/repos/asf/apr/apr/trunk/.github/workflows/
> > > >
> > > > GitHub supports Linux, macOS and Windows runners.
> > >
> > > Nice work Ivan, thanks a bunch!
> > >
> > > Regards;
> > > Yann.
> > >
> > > PS: now the macos guys have some work
> > > (https://github.com/apache/apr/runs/7004338300?check_suite_focus=true)
> >
> > I think on mac we do not have xml2-config and build/xml.m4 does not
> > actually set xml2_LIBS to anything when xml2 is auto-detected.
> > I think a similar path is wrong when --with-xml2 passes a dir instead
> > of a path to xml2-config.
> >
> > I am testing this which seemed to just work for the no xml2 args at
> > all case w/ no xml2-config:
>
> Looks good to me, though I can't test on macos..
>
> apr_file_datasync() is failing in test_datasync_on_stream() with errno=45:
> https://github.com/apache/apr/runs/7014421531?check_suite_focus=true#step:6:297
> We already ignore EINVAL which is returned by Linux (meaning ENOTIMPL
> there IIRC), any idea what errno=45 is on macos?

ENOTSUP
45: Operation not supported

Re: GitHub Actions CI

[Eric Covener]

On Wed, Jun 22, 2022 at 10:30 AM Yann Ylavic  wrote:
>
> On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev  
> wrote:
> >
> > As far I understand Apache Infra recommends to migrate Continuous 
> > Integration builds from Travis to GitHub Actions.
> >
> > I've added initial configuration for GitHub Actions for APR project:
> > https://svn.apache.org/repos/asf/apr/apr/trunk/.github/workflows/
> >
> > GitHub supports Linux, macOS and Windows runners.
>
> Nice work Ivan, thanks a bunch!
>
> Regards;
> Yann.
>
> PS: now the macos guys have some work
> (https://github.com/apache/apr/runs/7004338300?check_suite_focus=true)

I think on mac we do not have xml2-config and build/xml.m4 does not
actually set xml2_LIBS to anything when xml2 is auto-detected.
I think a similar path is wrong when --with-xml2 passes a dir instead
of a path to xml2-config.

I am testing this which seemed to just work for the no xml2 args at
all case w/ no xml2-config:

Index: build/xml.m4
===
--- build/xml.m4 (revision 1902172)
+++ build/xml.m4 (working copy)
@@ -177,6 +177,7 @@
 else
   xml2_CPPFLAGS="-I$withval/include/libxml2"
   xml2_LDFLAGS="-L$withval/lib64 -L$withval/lib"
+  xml2_LIBS="-lxml2"
 fi

 APR_ADDTO(CPPFLAGS, [$xml2_CPPFLAGS])
@@ -186,6 +187,7 @@
 AC_CHECK_HEADERS(libxml/parser.h, AC_CHECK_LIB(xml2,
xmlCreatePushParserCtxt, [apu_has_libxml2=1]))
   fi
   ], [
+xml2_LIBS="-lxml2"
 AC_CHECK_HEADERS(libxml/parser.h, AC_CHECK_LIB(xml2,
xmlCreatePushParserCtxt, [apu_has_libxml2=1]))
 ])
 AC_SUBST(apu_has_libxml2)

Maybe an autoconf guru can take a look?

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

Re: Named shared memory on macOS Monterey

[Eric Covener]

Is this what breaks the test framework with heartmonitor loaded? I've
lost the errors, ended up commenting out the mod and re-running
Makefiles.PL to get unblocked.

On Tue, May 17, 2022 at 3:26 PM Jim Jagielski  wrote:
>
> Anyone else notice that the later version of macOS really prefer
> that APR use posix for shared memory for both anon and name-based,
> instead of posix for anon and sysv/ipc for name?
>
> The issue seems to be that the kernel params are much lower than
> previous versions as well as it being nigh-impossible to reset
> those sysctl params on each boot, due to SIP.
>
> Shouldn't we prefer posix over sysv in any case?



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

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

[Eric Covener]

> Code that will compile on 1.7.1 release
> still won't compile on 1.7.0, unless I misunderstand something.

Is it a requirement in this direction?
https://apr.apache.org/versioning.html says "later versions"

Re: apr/trunk netware and os2

[Eric Covener]

On Mon, Jan 17, 2022 at 8:15 PM Yann Ylavic  wrote:
>
> On Tue, Jan 18, 2022 at 2:08 AM Yann Ylavic  wrote:
> >
> > On Tue, Nov 30, 2021 at 11:46 PM Mladen Turk  wrote:
> > >
> > > According to Wikipedia NetWare was discontinued in 2009
> > > and OS/2 in 2001, so if anyone can explain why we have
> > > those in trunk/apr-2 (that will be hopefully released one day).
> >
> > What about BeOS? We have some specifics for that too.
>
> Ditto for os390, also present in include/arch.

os390 aka z/OS is still used and still has new/supported OS releases.

Re: svn commit: r1896510 - in /apr/apr/branches/1.7.x: ./ file_io/win32/ include/arch/unix/ include/arch/win32/ network_io/os2/ poll/os2/ poll/unix/

[Eric Covener]

> I also have a high-level objection against backporting this change to
> APR 1.7.x: IMHO APR 1.7.x is a stable branch and I think that only
> regression fixes should be backported to the stable branch. r1896510
> is a significant change and as far as I understand it's not a
> regression fix. So I think it would be better to revert r1896510 and
> release it as part of APR 2.0 (or 1.8.x).

No comment on the scale/significance here, but IMO fixes to
non-regression defects are suitable for a patch/micro releases of APR.

Re: apr/trunk Minimum version is Windows 10!?

[Eric Covener]

On Wed, Dec 1, 2021 at 3:55 PM Mladen Turk  wrote:
>
> My proposal is to use 0x0603 (aka windows 8.1, windows server 2012r2)
> Those are still supported until 2023

A little conservative for trunk but still reasonable to me

Re: svn commit: r1833525 - in /apr/apr/trunk: crypto/apr_crypto.c crypto/apr_crypto_internal.c test/testcrypto.c util-misc/apu_dso.c

[Eric Covener]

my crypto adventure was short-lived and didn't ship (and now LRU'ed
from my brain).

I had this simpler change to our bundled APU 1.5.2 if it helps at all.

index 0f169b4f..958aa068 100644
--- srclib/apr-util/crypto/apr_crypto.c
+++ srclib/apr-util/crypto/apr_crypto.c
@@ -173,10 +173,11 @@ APU_DECLARE(apr_status_t) apr_crypto_get_driver(
 return APR_SUCCESS;
 }

-#if APU_DSO_BUILD
 /* The driver DSO must have exactly the same lifetime as the
  * drivers hash table; ignore the passed-in pool */
 pool = apr_hash_pool_get(drivers);
+#if APU_DSO_BUILD

 #if defined(NETWARE)
 apr_snprintf(modname, sizeof(modname), "crypto%s.nlm", name);


On Sun, Sep 12, 2021 at 12:56 PM Yann Ylavic  wrote:
>
> On Fri, Aug 23, 2019 at 2:35 PM Eric Covener  wrote:
> >
> > I have a question in this area, not necessarily a result of this commit.
> >
> > I have been playing with a new crypto provider, in a non-DSO build,
> > intended to be used with httpd.
> >
> > The provider does have both an initialization and termination API.
> >
> > My issue is a result of the "rootp" being used for the driver hashmap
> > but "pconf" (in the httpd/mod_session_crypto case) being passed to the
> > drivers init() function the first time it's loaded.  This means at
> > graceful restart, cleanups registered by the drivers init() function
> > will run, but apr_crypto_term will not, and the next call to get the
> > driver will not re-run the init().
> >
> > Making the lifetimes match either way fixes my test -- either moving
> > the "rootp" stuff to DSO-only for apr_crypto_init or by passing
> > "rootp" to the DRIVER_LOAD macro for non-DSO init.
> >
> > Any opinions?
>
> Was this resolved?
>
> It seems to me that in the !DSO case we should init the driver with
> the given pool and call init each time like in the DSO case.
> Something like the attached patch?
>
>
> Cheers;
> Yann.



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

Re: Setting up GitHub mirror for apr-util

[Eric Covener]

On Wed, Aug 11, 2021 at 7:45 AM Michael Osipov  wrote:
>
> Hi folks,
>
> today I have unfortunately noticed that the GH mirror for apr-util is
> defunct while working on 1.6.x. Opened an issue with INFRA: INFRA-22189
> It really turned out that the mirror is not active anymore.
> Given that large projects like Subversion or HTTPd require it, and
> people like to clone from GitHub, I think that we either should have an
> uptodate mirror or none.
> I'd like to file a new issue with INFRA to make this work again if you
> don't object.
>

+1

Re: svn:ignore a few more paths to help TortoiseSVN's build system

[Eric Covener]

Seems reasonable to me even on the release branches, will let it stew
a bit here.

On Wed, Jul 21, 2021 at 8:18 AM Daniel Sahlberg
 wrote:
>
> Hi,
>
> TortoiseSVN is importing APR and APR-util via an svn:externals definition:
> [[[
> https://svn.apache.org/repos/asf/apr/apr/tags/1.6.5 apr
> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.6.1 apr-util
> ]]]
>
> The build system creates a few new directories within the apr and apr-util 
> directories for temporary build files. These clutter svn status and makes it 
> more difficult to see if there are any real changes.
>
> I would propose to add a few more folders in svn:ignore. (I have already done 
> similar modifications in the Subversion repository, see r1891003).
>
> [[[
> Index: apr
> ===
> --- apr (revision 1891700)
> +++ apr (working copy)
>
> Property changes on: apr
> ___
> Modified: svn:ignore
> ## -14,8 +14,16 ##
>  LibNTR
>  Debug
>  DebugNT
> +debug_win32
> +debug_win32_static
> +debug_x64
> +debug_x64_static
>  Release
>  ReleaseNT
> +release_win32
> +release_win32_static
> +release_x64
> +release_x64_static
>  *.ncb
>  *.opt
>  *.plg
> Index: apr-util
> ===
> --- apr-util(revision 1891700)
> +++ apr-util(working copy)
>
> Property changes on: apr-util
> ___
> Modified: svn:ignore
> ## -17,7 +17,15 ##
>  apu-*-config
>  apu-config.out
>  Debug
> +debug_win32
> +debug_win32_static
> +debug_x64
> +debug_x64_static
>  Release
> +release_win32
> +release_win32_static
> +release_x64
> +release_x64_static
>  LibD
>  LibR
>  aprutil.opt
> ]]]
>
> An alternative approach would be to ignore debug_* and release_*, this might 
> help in case there is a future architecture (eg arm).
>
> (I realise this will be made on /trunk and not affect the tags that 
> TortoiseSVN is pulling in until there is a new release, but it will be better 
> in the future).
>
> Kind regards,
> Daniel Sahlberg
>


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

Re: svn commit: r1833525 - in /apr/apr/trunk: crypto/apr_crypto.c crypto/apr_crypto_internal.c test/testcrypto.c util-misc/apu_dso.c

[Eric Covener]

v=1833525=1833524=1833525=diff
> ==
> --- apr/apr/trunk/crypto/apr_crypto_internal.c (original)
> +++ apr/apr/trunk/crypto/apr_crypto_internal.c Thu Jun 14 16:34:49 2018
> @@ -284,8 +284,8 @@ const char *apr__crypto_mscng_version(vo
>  }
>
>  apr_status_t apr__crypto_mscng_init(const char *params,
> -   const apu_err_t **result,
> -   apr_pool_t *pool)
> +const apu_err_t **result,
> +apr_pool_t *pool)
>  {
>  return APR_ENOTIMPL;
>  }
>
> Modified: apr/apr/trunk/test/testcrypto.c
> URL: 
> http://svn.apache.org/viewvc/apr/apr/trunk/test/testcrypto.c?rev=1833525=1833524=1833525=diff
> ==
> --- apr/apr/trunk/test/testcrypto.c (original)
> +++ apr/apr/trunk/test/testcrypto.c Thu Jun 14 16:34:49 2018
> @@ -559,7 +559,10 @@ static void test_crypto_init(abts_case *
>
>  apr_pool_create(, NULL);
>
> -rv = apr_crypto_init(pool);
> +/* Use root pool (top level init) so that the crypto lib is
> + * not cleanup on pool destroy below (e.g. openssl can't re-init).
> + */
> +rv = apr_crypto_init(apr_pool_parent_get(pool));
>  ABTS_ASSERT(tc, "failed to init apr_crypto", rv == APR_SUCCESS);
>
>  apr_pool_destroy(pool);
> @@ -1680,7 +1683,7 @@ abts_suite *testcrypto(abts_suite *suite
>  {
>  suite = ADD_SUITE(suite);
>
> -/* test simple init and shutdown */
> +/* test simple init and shutdown (keep first) */
>  abts_run_test(suite, test_crypto_init, NULL);
>
>  /* test key parsing - openssl */
>
> Modified: apr/apr/trunk/util-misc/apu_dso.c
> URL: 
> http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apu_dso.c?rev=1833525=1833524=1833525=diff
> ==
> --- apr/apr/trunk/util-misc/apu_dso.c (original)
> +++ apr/apr/trunk/util-misc/apu_dso.c Thu Jun 14 16:34:49 2018
> @@ -106,6 +106,11 @@ apr_status_t apu_dso_init(apr_pool_t *po
>  return ret;
>  }
>
> +struct dso_entry {
> +    apr_dso_handle_t *handle;
> +apr_dso_handle_sym_t *sym;
> +};
> +
>  apr_status_t apu_dso_load(apr_dso_handle_t **dlhandleptr,
>apr_dso_handle_sym_t *dsoptr,
>const char *module,
> @@ -118,11 +123,14 @@ apr_status_t apu_dso_load(apr_dso_handle
>  apr_array_header_t *paths;
>  apr_pool_t *global;
>  apr_status_t rv = APR_EDSOOPEN;
> +struct dso_entry *entry;
>  char *eos = NULL;
>  int i;
>
> -*dsoptr = apr_hash_get(dsos, module, APR_HASH_KEY_STRING);
> -if (*dsoptr) {
> +entry = apr_hash_get(dsos, module, APR_HASH_KEY_STRING);
> +if (entry) {
> +*dlhandleptr = entry->handle;
> +*dsoptr = entry->sym;
>  return APR_EINIT;
>  }
>
> @@ -199,7 +207,10 @@ apr_status_t apu_dso_load(apr_dso_handle
>  }
>  else {
>  module = apr_pstrdup(global, module);
> -apr_hash_set(dsos, module, APR_HASH_KEY_STRING, *dsoptr);
> +entry = apr_palloc(global, sizeof(*entry));
> +entry->handle = dlhandle;
> +entry->sym = *dsoptr;
> +apr_hash_set(dsos, module, APR_HASH_KEY_STRING, entry);
>  }
>  return rv;
>  }
>
>


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

Re: Was this a bug in APR from 2008?

[Eric Covener]

On Fri, Nov 30, 2018 at 11:00 AM William A Rowe Jr  wrote:
>
> The comment here makes no sense (unix, not windows). But the patch itself 
> seems reasonable. There is a performance hit, but nothing compared to the 
> call into stat/lstat. Other's opinions?

Seems risky from regression POV.  Safer to map errno of ENAMETOOLONG
to the APR_ENAMETOOLONG, in case APR_NAMEMAX is lower than actual
limit at runtime.

Not sure about httpd patch though, IIUC it only helps a faulty config
or module (dirwalk happening for long URI that won't actually be
served off disk)

Re: APR 1.6.5 on Solaris 10 SPARC won't pass or even complete tests

[Eric Covener]

On Fri, Sep 14, 2018 at 6:07 PM Dennis Clarke  wrote:
>
>
> So I have gone in circles a number of times here and the results across
>   a few servers look like so :
>
> .
> .
> .
> testatomic  :  SUCCESS
> testdir :  SUCCESS
> testdso :  SUCCESS
> testdup :  SUCCESS
> testenv :  SUCCESS
> testescape  :  SUCCESS
> testfile:  SUCCESS
> testfilecopy:  SUCCESS
> testfileinfo:  SUCCESS
> testflock   :  SUCCESS
> testfmt :  SUCCESS
> testfnmatch :  SUCCESS
> testargs:  SUCCESS
> testhash:  SUCCESS
> testipsub   :  Line 209: expected , but saw <%eth>
> FAILED 1 of 6
> testlock:  SUCCESS
> testcond:  SUCCESS
> testlfs :  Line 349: LFS support a no-op in 64-bit builds
> SUCCESS
> testmmap:  SUCCESS
> testnames   :  SUCCESS
> testoc  :  SUCCESS
> testpath:  SUCCESS
> testpipe:  SUCCESS
> testpoll:
>
>
> Nothing ever happens after that point.
>
> I am using Oracle Studio 12.6 and c99 and not very interesting CFLAGS
> with CPPFLAGS to provide -D_EXTENSIONS_ and also -D__EXTENSIONS__ or
> the compile fails fast.
>
> Some process called "./testall -v" is running and also doing nothing.
> Zero activity there. Truss says so.
>
> # ps -ef | grep 29868
>   dclarke 29868 26961   0 19:48:54 pts/14  0:00 /usr/bin/bash -c
> teststatus=0; \progfailed=""; \for prog in testlockperf test
>  root  5561 12826   0 22:05:05 pts/8   0:00 grep 29868
>   dclarke 29900 29868   0 19:51:17 pts/14  0:07 ./testall -v
>
> So I am curious about how to get some more information here.
>

It is passing for me on an an old system with very old sun studio. The
testpoll test
only takes about 2 seconds for me.

You can do e.g.

truss -u ::apr_poll\* -o truss.out test/testall  testpoll

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

[Eric Covener]

On Fri, Aug 31, 2018 at 12:20 PM Rainer Jung  wrote:
>
> To clarify: the CI build failures only send a summary email to the dev
> list. If you want to see the output, you need to visit the CI build page
> (link included in the failure mail) and there clock on the appropriate
> "stdio" link. That's probably from where Bill took the log snippet.

for posterity, I was getting the summaries, but hadn't seen them
forever don't see them unless I explicitly go into an apr/ label in
gmail.

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

[Eric Covener]

On Fri, Aug 31, 2018 at 10:04 AM Yann Ylavic  wrote:
>
> On Fri, Aug 31, 2018 at 3:29 PM William A Rowe Jr  wrote:
> >
> > I presume you are subscribed to the commits list, which broadcasts our CI 
> > results?
>
> Hmm, I'm supposed to be subscribed to commits@ list but somehow I
> didn't receive this one (yet?).
> Or is it a special list?

I don't get it either!

Re: Release schedule of APR-1.6.4?

[Eric .]

Yes, I'm looking for that Solaris patch.

On Wed, 29 Aug 2018 at 17:53, Nick Kew  wrote:

>
> > On 29 Aug 2018, at 09:25, Eric .  wrote:
> >
> > Hi all,
> >
> > May I have an idea approximately when APR-1.6.4 will be released?
> > Thank you very much.
>
> If you read this list, you know exactly the same as all of us.
> Are you running on Solaris and looking for that poll patch,
> or do you have some other interest?
>
> --
> Nick Kew
>

Release schedule of APR-1.6.4?

[Eric .]

Hi all,

May I have an idea approximately when APR-1.6.4 will be released?
Thank you very much.

Re: 1.6 release?

[Eric Covener]

On Fri, Aug 24, 2018 at 12:37 PM Dennis Clarke  wrote:
>
> On 08/24/2018 09:16 AM, Eric Covener wrote:
> > Starting a new thread as potential RM's may be filtering bugzilla emails.
> >
> > There are a lot of reports of PR62644 from solaris users of httpd, can
> > anyone RM?
> >
>
> I am running a few versions of httpd on solaris and have not seen any
> issues.  Is there a bug report somewhere ?

https://bz.apache.org/bugzilla/show_bug.cgi?id=62644

1.6 release?

[Eric Covener]

Starting a new thread as potential RM's may be filtering bugzilla emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?

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

Fwd: [Bug 62644] Apache httpd hangs after a few days on Solaris i386

[Eric Covener]

Looks like we need a 1.6 release to pickup this pollset hang issue on Solaris.

-- Forwarded message -
From: 
Date: Tue, Aug 21, 2018 at 6:35 AM
Subject: [Bug 62644] Apache httpd hangs after a few days on Solaris i386
To: 


https://bz.apache.org/bugzilla/show_bug.cgi?id=62644

Eric Covener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Covener  ---


*** This bug has been marked as a duplicate of bug 61786 ***

--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



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

Re: New Random Number Generator (RNG)?

[Eric Covener]

On Thu, Jun 7, 2018 at 11:59 AM, Yann Ylavic  wrote:
> I'd like to propose a new RNG for APR, based on a design from D.J.
> Bernstein ([1]).
>
> Called "Fast-key-erasure random-number generators" by the author, it
> requires 256bits (32 bytes) of initial entropy only, is fast, and
> ensures Forward Secrecy.
>
> The current RNGs available in APR are:
> 1/ apr_generate_random_bytes(); the wrapper around the system call,
> 2/ apr_random_(in)secure_bytes(); the ones from "random/unix/apr_random.c".
>
> Both are obviously considered secure, but 1/ is usually not very fast
> (and could block on some systems), and 2/ requires kilos of initial
> entropy (taken from 1/ thus possibly blocking too).
> Also the system RNG wrapped by 1/ is unlikely to return a great number
> of bytes at once (256 max on some systems like BSDs), and better suits
> as a source of entropy (like in 2/).
> Neither ensures forward secrecy (AFAICT).
>

I think the guts of 2) really needs to go, it is totally orphaned.

Re: svn commit: r1828369 - in /apr/apr/trunk: include/apr_reslist.h util-misc/apr_reslist.c

[Eric Covener]

On Mon, Apr 16, 2018 at 6:04 AM, Yann Ylavic <ylavic@gmail.com> wrote:
> On Mon, Apr 16, 2018 at 8:45 AM, Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 04/14/2018 02:32 AM, Yann Ylavic wrote:
>>>
>>> IOW, this simple patch would work equally for me (and could go in any 
>>> version):
>>>
>>> Index: util-misc/apr_reslist.c
>>> ===
>>> --- util-misc/apr_reslist.c(revision 1829106)
>>> +++ util-misc/apr_reslist.c(working copy)
>>> @@ -61,13 +61,13 @@ struct apr_reslist_t {
>>>  };
>>>
>>>  /**
>>> - * Grab a resource from the front of the resource list.
>>> + * Grab a resource from the back of the resource list.
>>>   * Assumes: that the reslist is locked.
>>>   */
>>>  static apr_res_t *pop_resource(apr_reslist_t *reslist)
>>>  {
>>>  apr_res_t *res;
>>> -res = APR_RING_FIRST(>avail_list);
>>> +res = APR_RING_LAST(>avail_list);
>>>  APR_RING_REMOVE(res, link);
>>>  reslist->nidle--;
>>>  return res;
>>> --
>>
>> Hm, but this would change this to become a fifo list instead of the current 
>> lifo list or do I miss something?
>
> Yes clearly, I suggested that reslists be changed to FIFO
> unconditionnaly, because I find that LIFO and expiry don't mix well
> w.r.t. starvation..
>
> That would be the simpler patch too (not that
> apr_reslist_acquire_fifo() is hard to implement, but I wonder who
> needs LIFO in the firtst place with such a structure...).
>

Looks like it could cause some subtle/sneaky system behavior changes.

IIUC consider  mod_dbd which may even have functional issues.
How many times should a caller call ap_dbd_open()? 1, 3, or until it
hopefully stops returning NULL?

OTOH I do agree that FIFO looks a lot more sensible as a default, but
I think that ship has sailed.

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

Re: svn commit: r1820755 - /apr/apr/trunk/misc/unix/rand.c

[Eric Covener]

I think that's right, the thing it's correcting is trunk-only (I
checked 1.7 had no grep -ri arc4random_buf)

On Tue, Apr 3, 2018 at 3:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Eric,
>
> Confirming; this is a trunk-only change? I don't see 1.7/1.6 commits.
>
> On Wed, Jan 10, 2018 at 8:53 AM,  <cove...@apache.org> wrote:
>> Author: covener
>> Date: Wed Jan 10 14:53:43 2018
>> New Revision: 1820755
>>
>> URL: http://svn.apache.org/viewvc?rev=1820755=rev
>> Log:
>> fix ifdef for arc4random
>>
>> r1814239 added:
>>   AC_CHECK_FUNCS(arc4random_buf)
>>
>> Which only defines HAVE_ARC4RANDOM_BUF
>>
>>
>>
>>
>> Modified:
>> apr/apr/trunk/misc/unix/rand.c
>>
>> Modified: apr/apr/trunk/misc/unix/rand.c
>> URL: 
>> http://svn.apache.org/viewvc/apr/apr/trunk/misc/unix/rand.c?rev=1820755=1820754=1820755=diff
>> ==
>> --- apr/apr/trunk/misc/unix/rand.c (original)
>> +++ apr/apr/trunk/misc/unix/rand.c Wed Jan 10 14:53:43 2018
>> @@ -224,7 +224,7 @@ APR_DECLARE(apr_status_t) apr_generate_r
>>  length -= rc;
>>  } while (length > 0);
>>
>> -#elif defined(HAVE_ARC4RANDOM)
>> +#elif defined(HAVE_ARC4RANDOM_BUF)
>>
>>  arc4random_buf(buf, length);
>>
>>
>>



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

Re: [PATCH] arc4random support

[Eric Covener]

On Thu, Oct 26, 2017 at 6:56 AM, Stefan Sperling <s...@apache.org> wrote:
> This patch adds support for using the arc4random API as an entropy source.
>
> The arc4random API originates from OpenBSD where it supersedes random(3),
> rand(3), and files in the /dev filesystem: http://man.openbsd.org/arc4random
> The arc4random_buf() function maps 1:1 onto apr_generate_random_bytes().
>
> This patch was written by Christian Weisgerber, who asked me to push
> this work upstream on his behalf.
>
> Index: configure.in
> ===
> --- configure.in(revision 1813380)
> +++ configure.in(working copy)
> @@ -2453,6 +2453,8 @@ else
>  fi
>
>  dnl - Checking for /dev/random
> +AC_CHECK_FUNCS(arc4random_buf)
> +
>  AC_MSG_CHECKING(for entropy source)
>
>  why_no_rand=""
> @@ -2471,6 +2473,13 @@ AC_ARG_WITH(egd,
>])
>
>  if test "$rand" != "1"; then
> +  if test "$ac_cv_func_arc4random_buf" = yes; then
> +AC_MSG_RESULT(arc4random)
> +rand="1"
> +  fi
> +fi
> +
> +if test "$rand" != "1"; then
>AC_ARG_WITH(devrandom,
>  [  --with-devrandom[[=DEV]]  use /dev/random or compatible [[searches by 
> default]]],
>  [ apr_devrandom="$withval" ], [ apr_devrandom="yes" ])
> Index: misc/unix/rand.c
> ===
> --- misc/unix/rand.c(revision 1813380)
> +++ misc/unix/rand.c(working copy)
> @@ -87,8 +87,12 @@ APR_DECLARE(apr_status_t) apr_os_uuid_get(unsigned
>  APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char *buf,
>  apr_size_t length)
>  {
> -#ifdef DEV_RANDOM
> +#ifdef HAVE_ARC4RANDOM
>
> +    arc4random_buf(buf, length);
> +
> +#elif defined(DEV_RANDOM)
> +
>  int fd = -1;
>
>  /* On BSD/OS 4.1, /dev/random gives out 8 bytes at a time, then

Don't we need to check for HAVE_ARC4RANDOM_BUF rather than HAVE_ARC4RANDOM?

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

Re: svn commit: r1819858 - /apr/apr/trunk/poll/unix/port.c

[Eric Covener]

On Tue, Jan 2, 2018 at 12:51 PM, Eric Covener <cove...@gmail.com> wrote:
> On Tue, Jan 2, 2018 at 12:37 PM, Yann Ylavic <ylavic@gmail.com> wrote:
>> On Tue, Jan 2, 2018 at 6:28 PM,  <yla...@apache.org> wrote:
>>> Author: ylavic
>>> Date: Tue Jan  2 17:28:53 2018
>>> New Revision: 1819858
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1819858=rev
>>> Log:
>>> poll, port: re-add the wakeup pipe to the pollset after it triggered.
>>>
>>> Just like user fds (file, socket), otherwise it's one shot only (PR-61786).
>>
>> I can't really compile/test this (no Solaris at hand), reasoning based
>> on code inspection...
>>
>>>
>>> Corresponding test committed in r1819857.
>>
>> May someone with the {hard,soft}ware test at r1819857 and then at
>> r1819858 (this commit) to see if it makes a difference?
>> I expect "testpoll" to wait indefinitely before at r1819857, and work
>> as usual at r1819858...
>>
>> Thanks!
>
> I am testing this now on Solaris/x64 and will report back. Thanks for
> the great work on event!

testpoll hangs at 1819857 and works at 1819861 (latest)

Re: svn commit: r1819858 - /apr/apr/trunk/poll/unix/port.c

[Eric Covener]

On Tue, Jan 2, 2018 at 12:37 PM, Yann Ylavic <ylavic@gmail.com> wrote:
> On Tue, Jan 2, 2018 at 6:28 PM,  <yla...@apache.org> wrote:
>> Author: ylavic
>> Date: Tue Jan  2 17:28:53 2018
>> New Revision: 1819858
>>
>> URL: http://svn.apache.org/viewvc?rev=1819858=rev
>> Log:
>> poll, port: re-add the wakeup pipe to the pollset after it triggered.
>>
>> Just like user fds (file, socket), otherwise it's one shot only (PR-61786).
>
> I can't really compile/test this (no Solaris at hand), reasoning based
> on code inspection...
>
>>
>> Corresponding test committed in r1819857.
>
> May someone with the {hard,soft}ware test at r1819857 and then at
> r1819858 (this commit) to see if it makes a difference?
> I expect "testpoll" to wait indefinitely before at r1819857, and work
> as usual at r1819858...
>
> Thanks!

I am testing this now on Solaris/x64 and will report back. Thanks for
the great work on event!



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

Re: [users@httpd] Problems building httpd-2.4.26 with apr-1.6.2 and apr-util-1.6.0

[Eric Covener]

On Fri, Jun 23, 2017 at 10:55 AM, Martin Knoblauch <kn...@knobisoft.de> wrote:
>  Apparently apr-util no longer bundles "expat". So my question: what is the
> correct/intended way to work around this?


apr-util accepts a --with-expat.  If you build apr-util under httpd's
srclib/ --with-expat can be specified at the top and it will be passed
down.


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

Re: [VOTE] Release APR 1.6.2

[Eric Covener]

+1 AIX/xlc/ppc64

longstanding failure in apr_sockaddr_is_wildcard() only

On Sat, Jun 10, 2017 at 8:50 AM, Jim Jagielski <j...@jagunet.com> wrote:
> +1
>> On Jun 9, 2017, at 9:09 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> With good fortune, all architecture-specific issues are fixed,
>> and we are ready to bless a 1.6 initial release. Usual
>> http://apr.apache.org/dev/dist/ path contains the candidate.
>>
>>  +/- votes please
>>  [  ] Release apr 1.6.2
>



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

Re: [VOTE] Release APR-UTIL 1.6.0

[Eric Covener]

+1 AIX/xlc/ppc64

Longstanding mystery testxlate crash, no regression.

On Sat, Jun 10, 2017 at 8:40 AM, Jim Jagielski <j...@jagunet.com> wrote:
> +1.
>> On Jun 9, 2017, at 9:07 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> As I mention in parent post, this is a distinct thread for any
>> final votes and to tally vote count of apr-util 1.6.0 release.
>> Usual http://apr.apache.org/dev/dist/ path for candidates.
>>
>>  +/- votes please
>>  [  ] Release apr-util 1.6.0
>



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

Re: svn commit: r1797422 - /apr/apr/trunk/memcache/apr_memcache.c

[Eric Covener]

On Mon, Jun 5, 2017 at 4:32 PM, William A Rowe Jr  wrote:
> What happens if two different threads attempt this poll in parallel? I
> presumed pollsets are copied to prevent two threads from clashing.

>>  pollfds = apr_pcalloc(temp_pool, apr_hash_count(server_queries) *
>> sizeof(apr_pollfd_t));
>>
>> -rv = apr_pollset_create(, apr_hash_count(server_queries),
>> temp_pool, 0);
>> +rv = apr_pollset_create(, apr_hash_count(server_queries),
>> temp_pool,
>> +APR_POLLSET_NOCOPY);

Looks kosher, the pollfds that will be added to this pollset have the
same lifetime / same pool (beginning of the diff context), and the
pollset does not escape this function.

Re: SHA256 and friends.

[Eric Covener]

On Fri, Jan 20, 2017 at 10:52 AM, Yann Ylavic  wrote:
> On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
>  wrote:
>>
>> Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark 
>> up the 2 or 3 places
>> that we know we need a real MD5 - we could have a 'fiddle' mode where we 
>> silently return a better 'md5'
>> in the places where we would like to use a SHA256 but it is just too much 
>> hassle to adjust things.
>
> MD5 *is* MD5, preferably used (and not recommended) for
> non-cryptographic purpose, but still I think apr_md5()'s result
> shouldn't differ from whatelse_md5()'s.
>
> We can't break users silently, if they use MD5, well they have it.

+1

Re: Question re: build of (64-bit) httpd and issue with apr_password_validate

[Eric Covener]

On Fri, Aug 19, 2016 at 7:14 AM, Michael Felt <mamf...@gmail.com> wrote:
> root@x064:[/data/prj/apache/httpd-2.4.23]nm /opt/modules/mod_authn_file.so |
> grep apr_password_validate


Are you sure that the libapr you're scrutinizing is being loaded at runtime?

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

Re: CVE-2016-0718

[Eric Covener]

Here's a manual fix of the merge conflicts, needs -p4 since I did it
in a httpd sandbox.

http://people.apache.org/~covener/patches/apu-expat-CVE-2016-0718.diff

I confirmed a simple webdav test worked.  To double-check the merge, I
did see that the patch did not change every call to xmlConvert and we
have the same number of calls and changes as they do.


On Fri, May 27, 2016 at 10:12 AM, Eric Covener <cove...@gmail.com> wrote:
> On Fri, May 27, 2016 at 9:48 AM, David Dillard <davidedill...@gmail.com> 
> wrote:
>> Did anyone see
>> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0718?  "Expat
>> allows context-dependent attackers to cause a denial of service (crash) or
>> possibly execute arbitrary code via a malformed input document, which
>> triggers a buffer overflow."
>>
>> A patch used for Debian can be found at
>> http://www.openwall.com/lists/oss-security/2016/05/17/12
>
> Thanks David.
>
> As reported by Seulbae Kim from the Center for Software Security and
> Assurance (CSSA), we either need to spend a lot of time on a bundled
> expat or rip it out from releases. I think one more release with an
> updated expat might be prudent, given the severity of the issue shared
> above.
>
> --
> Eric Covener
> cove...@gmail.com



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

Re: CVE-2016-0718

[Eric Covener]

On Fri, May 27, 2016 at 9:48 AM, David Dillard <davidedill...@gmail.com> wrote:
> Did anyone see
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0718?  "Expat
> allows context-dependent attackers to cause a denial of service (crash) or
> possibly execute arbitrary code via a malformed input document, which
> triggers a buffer overflow."
>
> A patch used for Debian can be found at
> http://www.openwall.com/lists/oss-security/2016/05/17/12

Thanks David.

As reported by Seulbae Kim from the Center for Software Security and
Assurance (CSSA), we either need to spend a lot of time on a bundled
expat or rip it out from releases. I think one more release with an
updated expat might be prudent, given the severity of the issue shared
above.

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

Re: Mailing list semantics

[Eric Covener]

On Thu, Jan 28, 2016 at 11:06 AM, Jeff Trawick  wrote:
> [X] Change to reply-to-list default reply semantics
>
me too

Re: ap_init_rng / apr_random question

[Eric Covener]

Maybe another topic for 1.6. Is it wise to keep this code around?

On Sun, Nov 1, 2015 at 10:20 AM, Eric Covener <cove...@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <ylavic@gmail.com> wrote:
>> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <cove...@gmail.com> wrote:
>>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>>
>>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>>> (32*32*32)
>>>
>>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>>
>>> I am working on a platform where access to the crypto facility
>>> underneath /dev/random is sometimes audited.  Does anyone have any
>>> hints about whether larger reads from /dev/random would be better
>>> elsewhere? Or if the startup requirement is really this high for data
>>> from /dev/random?
>>
>> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
>> (secret) entropy to be secure (cryptographically strong), so I don't
>> think more would be needed for httpd (or APR).
>> It seems to me that asking for more than 32 bytes of random bytes by
>> something like a minute is not very sound (both for the requester AND
>> the "others"), so IMHO we should really take that into consideration.
>
> Adding Ben directly (sorry Ben).Ben, you might recall the APR PRNG
> http://svn.apache.org/viewvc/apr/apr/trunk/random/unix/apr_random.c?view=log
>
> We noticed it is awfully /dev/random hungry at startup because the
> bytes fed to it (AFAICT) get  sprayed across 32 pools that need to be
> reseeded 32 times each to be able to reach 32 generations to flip over
> to being ready to provide insecure bytes.  I'm wondering if any of
> those factors is somehow inadvertent or if there's any other light you
> can shed on it (defaults optimized for hypothetical daemon mode, etc)
>
> (My original report was exacerbated by httpd feeding in entropy 8
> bytes at a time)



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

Re: EBCDIC bug(s?) in our apr-util//crypto/crypt_blowfish.c implementation

[Eric Covener]

FWIW I had recently disabled this on my own EBCDIC port when I saw too
late that it doesn't even pass the self-test.  Will not be able to dig
into it though.

On Wed, Jan 6, 2016 at 1:37 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> This doesn't look good.  Does an EBCDIC architecture fan want to whip up the
> fix?
>
>
> static char *BF_crypt(const char *key, const char *setting,
> char *output, int size,
> BF_word min)
> {
> ... static const unsigned char flags_by_subtype[26] =
> {2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 4, 0};
> ... if (setting[0] != '$' ||
>setting[1] != '2' ||
>setting[2] < 'a' || setting[2] > 'z' ||
>!flags_by_subtype[(unsigned int)(unsigned char)setting[2] - 'a'] ||



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

Re: ap_init_rng / apr_random question

[Eric Covener]

On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <ylavic@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <cove...@gmail.com> wrote:
>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>
>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>> (32*32*32)
>>
>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>
>> I am working on a platform where access to the crypto facility
>> underneath /dev/random is sometimes audited.  Does anyone have any
>> hints about whether larger reads from /dev/random would be better
>> elsewhere? Or if the startup requirement is really this high for data
>> from /dev/random?
>
> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
> (secret) entropy to be secure (cryptographically strong), so I don't
> think more would be needed for httpd (or APR).
> It seems to me that asking for more than 32 bytes of random bytes by
> something like a minute is not very sound (both for the requester AND
> the "others"), so IMHO we should really take that into consideration.

Adding Ben directly (sorry Ben).Ben, you might recall the APR PRNG
http://svn.apache.org/viewvc/apr/apr/trunk/random/unix/apr_random.c?view=log

We noticed it is awfully /dev/random hungry at startup because the
bytes fed to it (AFAICT) get  sprayed across 32 pools that need to be
reseeded 32 times each to be able to reach 32 generations to flip over
to being ready to provide insecure bytes.  I'm wondering if any of
those factors is somehow inadvertent or if there's any other light you
can shed on it (defaults optimized for hypothetical daemon mode, etc)

(My original report was exacerbated by httpd feeding in entropy 8
bytes at a time)

Re: ap_init_rng / apr_random question

[Eric Covener]

On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <ylavic@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <cove...@gmail.com> wrote:
>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>
>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>> (32*32*32)
>>
>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>
>> I am working on a platform where access to the crypto facility
>> underneath /dev/random is sometimes audited.  Does anyone have any
>> hints about whether larger reads from /dev/random would be better
>> elsewhere? Or if the startup requirement is really this high for data
>> from /dev/random?
>
> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
> (secret) entropy to be secure (cryptographically strong), so I don't
> think more would be needed for httpd (or APR).
> It seems to me that asking for more than 32 bytes of random bytes by
> something like a minute is not very sound (both for the requester AND
> the "others"), so IMHO we should really take that into consideration.

Addng dev@apr in case anyone with knowledge in this area is only watching there.

Re: APR Buffer NullPointer Error

[Eric Covener]

Probably more relevant to the tomcat users mailing list.

On Wed, May 20, 2015 at 1:12 PM, Maxim Neshcheret
maxim.neshche...@cma.ru wrote:
 Dear All

 I am deploying application (Tomcat 8.0.22, JDK 1.7.79, Solaris, SPARC, APR
 1.5.2) and observing multiple erros while its communicates with client
 software (error presented below). It looks like that error happens while
 application writes output buffer. Any suggestion what is going wrong? Might
 it be resources limitation on OS level (was configured based on Oracle
 recommendations already).

 java.lang.NullPointerException
 at
 org.apache.coyote.http11.InternalAprOutputBuffer.addToBB(InternalAprOutputBuffer.java:186)
 ~[tomcat-coyote.jar:8.0.21]
 at
 org.apache.coyote.http11.InternalAprOutputBuffer.access$000(InternalAprOutputBuffer.java:40)
 ~[tomcat-coyote.jar:8.0.21]
 at
 org.apache.coyote.http11.InternalAprOutputBuffer$SocketOutputBuffer.doWrite(InternalAprOutputBuffer.java:349)
 ~[tomcat-coyote.jar:
 at
 org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:116)
 ~[tomcat-coyote.jar:8.0.21]
 at
 org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:256)
 ~[tomcat-coyote.jar:8.0.21]
 at org.apache.coyote.Response.doWrite(Response.java:503)
 ~[tomcat-coyote.jar:8.0.21]
 at
 org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:388)
 ~[catalina.jar:8.0.21]
 at
 org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426)
 ~[tomcat-util.jar:8.0.21]
 at
 org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:471)
 ~[catalina.jar:8.0.21]
 at
 org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:393)
 ~[tomcat-util.jar:8.0.21]
 at
 org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:339)
 ~[catalina.jar:8.0.21]
 at
 org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:317)
 ~[catalina.jar:8.0.21]
 at
 org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:94)
 ~[catalina.jar:8.0.21]
 at se.highex.core.gw.GWSession.sendMsgs(GWSession.java:1568)
 ~[GWSession.class:?]
 at se.highex.core.gw.GWSession.takeNotifyQueue(GWSession.java:1668)
 ~[GWSession.class:?]

 BR,
 Maxim



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

Re: [VOTE] Release APR 1.5.2

[Eric Covener]

On Tue, Apr 28, 2015 at 10:34 AM, Jeff Trawick traw...@gmail.com wrote:
 Does anyone else plan on testing/voting in the next 10 hours?  I'd like to
 see the CVE fix for Windows on its way to the mirrors, or at least find out
 that we have more serious problems to deal with.  Tentative plan: Hold the
 vote open until 8:30 PM EDT, roughly 10 hours from now.  TIA!

shooting for this afternoon

Re: [VOTE] Release APR 1.5.2

[Eric Covener]

move to dev@apr

On Tue, Apr 28, 2015 at 12:18 PM, Eric Covener cove...@gmail.com wrote:
 On Sat, Apr 25, 2015 at 8:13 AM, Jeff Trawick traw...@gmail.com wrote:
 +/-1
 [  ] Release APR 1.5.2 as GA


 +1 for release.  Tested on AIX/PPC32, HPUX/IA64 and Solaris/x64.

 HPUX and AIX had non-regression long standing failure in testxlate.



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

Re: http2 support

[Eric Covener]

On Fri, Apr 24, 2015 at 9:53 AM, Joshua Marantz jmara...@google.com wrote:
 I was curious what the plans for HTTP2 support in Apache look like.  I know
 Apache now owns mod_spdy. Also it appears someone is looking at building a
 mod_http2: http://marc.info/?l=apache-httpd-devm=142660802332383w=2 .

 Is it expected that Apache will support http2 in its kernel?  Or that it
 will be a contributed module?

Probably better discussed on dev@httpd vs APR.

My guess would be http2 as a module with changes to accommodate it in
the core, if that approach turns out to be practical.  Standard caveat
of if people are willing to work on it applies.

Odd install behaviour

[Eric F]

Hi list,
I just installed Apache 2.4.10 the other night*. When I first installed
apr{,-utils} I had som issues.

Made myself a custom layout, and used that one with:
./configure --enable-layout=Srv24

“Installbuilddir” doesn't end up where it was suppose to be, it
relfected to the datadir (I think it was). Had to manually specify the
path in my config line.
./configure --enable-layout=Srv24
--with-installbuilddir=/usr/lib/httpd/build-1

Anyway, I thought I should report that, 'cause it can't be the intended
behaviour. :)
(perhaps it's been diiscussed before. Didn't read very far back.)

// * on a Mac Pro, 10.7.5

- Eric

Re: [VOTE] Release APR-util 1.5.4

[Eric Covener]

On Tue, Sep 16, 2014 at 7:47 PM, Jeff Trawick traw...@gmail.com wrote:


 Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

 Shortcut to CHANGES files:

 http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
 http://apr.apache.org/dev/dist/CHANGES-APR-1.5
 http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
 http://apr.apache.org/dev/dist/CHANGES-APR-1.5.4

 autoconf version: 2.69 (same as recent apr and apr-util)
 libtool version: 2.4.2 (same as recent apr and apr-util)

 +/-1
 [  ] Release apr-util 1.5.4 as GA


​+1
AIX/xlc/ppc32: non-regression failure in testxlate
Solaris/sunstudio/sparc32: 100%

Re: svn commit: r1604598 - in /apr/apr/trunk: CHANGES tables/apr_skiplist.c

[Eric Covener]

all synched up to 1.5 and 1.6

On Tue, Jun 24, 2014 at 11:38 AM, Eric Covener cove...@gmail.com wrote:
 On Tue, Jun 24, 2014 at 10:57 AM, Jim Jagielski j...@jagunet.com wrote:
 Is this suitable for 1.5 and 1.6 as well?

 Yes, thanks for reminder, I paused to give Takashi time to verify it
 is sufficient and he has already confirmed in bugzilla.

 I did see a weird conflict backporting the skiplist test. I did not
 look in detail, but it seemed like even 1.6 had far fewer tests.

 I will backport soon.



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

Re: svn commit: r1604598 - in /apr/apr/trunk: CHANGES tables/apr_skiplist.c

[Eric Covener]

On Tue, Jun 24, 2014 at 10:57 AM, Jim Jagielski j...@jagunet.com wrote:
 Is this suitable for 1.5 and 1.6 as well?

Yes, thanks for reminder, I paused to give Takashi time to verify it
is sufficient and he has already confirmed in bugzilla.

I did see a weird conflict backporting the skiplist test. I did not
look in detail, but it seemed like even 1.6 had far fewer tests.

I will backport soon.

Re: my messages get queued

[Eric Covener]

 I haven't seen a notice of problems from infrastructure, but I have seen
 terrible mailing list delays over the last week.  For example, just now I
 saw a commit message from 8 days ago.  Normally I might see a delay of up to
 a few hours.

 I don't know whether or not this addresses your exact problem.

I have seen some ASF-wide emails on it. Mail is all over the floor for
more than a week.

Re: digest functions and validation - part 2

[Eric Covener]

On Fri, May 9, 2014 at 3:53 PM, Helmut Tessarek tessa...@evermeet.cx wrote:
 The sha*crypt functions are basically a standard, are
 they not? Thus it would make sense to include them in APR.

I think there's some disconnect about the role of APR.

But setting that aside, what's missing is someone doing the actual
work, not some principle keeping it out.

Re: configuring apr-util --with-ldap against idsldap (aka tivoli)

[Eric Covener]

I (IBM) have some patches in this area that didn't make it to APR or HTTPD :(

Unortunately Tivoli SSL initialization doesn't fit into how APU
initializes SSL and we are currently using hacks in both APU and
HTTPD.

On Tue, Feb 18, 2014 at 2:46 PM, Michael Felt mamf...@gmail.com wrote:
 After running the idslink -l 32 (will look at 64 bit later, one thing at a
 time) and adding symbolic links in /usr/include to the version currently
 installed ./configure does complete, and says that ldap support is enabled -
 HOWEVER - i expect it is not going to support ldaps because configure is
 only checking for ldap_sslinit() and not for ldap_ssl_init() which is what
 is in the idsldap library:

 root@x093:[/opt/IBM/ldap/V6.1/lib]nm /opt/IBM/ldap/V6.1/lib/libibmldap.a |
 grep ldap_ | grep init
 .ldap_create_password_policy_bind_init_request T  261032
 .ldap_init   T 884
 .ldap_init_all_global_mutex T   53576
 .ldap_init_all_mutex_once T   53200
 .ldap_init_iconv T   41260
 .ldap_krb_init_tkt   T  271232
 .ldap_lc_initT  48
 .ldap_msg_table_init T4888
 .ldap_msginitT   21052
 .ldap_ssl_client_init T  249848
 .ldap_ssl_environment_init T  249824
 .ldap_ssl_init   T  249872
 .ldap_ssl_pkcs11_client_init T  249728
 .ldap_ssl_pkcs11_environment_init T  249752
 /project/aus61ldap/build/aus61ldapsb/src/libraries/libldap/ldap_init.c f
 -
 ldap_create_password_policy_bind_init_request D   58384  12
 ldap_initD   53752  12
 ldap_init_all_global_mutex D   57556  12
 ldap_init_all_mutex_once D   53620  12
 ldap_init_all_mutex_once d   60292   4
 ldap_init_iconv  D   58552  12
 ldap_krb_init_tktD   60148  12
 ldap_lc_init D   53608  12
 ldap_msg_table_init  D   53812  12
 ldap_msginit D   54316  12
 ldap_ssl_client_init D   57268  12
 ldap_ssl_environment_init D   57256  12
 ldap_ssl_initD   57280  12
 ldap_ssl_pkcs11_client_init D   57208  12
 ldap_ssl_pkcs11_environment_init D   57220  12

 Just thought I would list any routine in the library that has init in the
 name.

 1) Am I correct is assumming that ldap connectivity over ssl is not going to
 be recognized?

 See include/apr_ldap.h created... attachment

 Thank you for your consideration.




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