Re: svn commit: r1917266 - in /apr/apr/trunk: buffer/apr_buffer.c include/apr_buffer.h test/testbuffer.c

On 24 Apr 2024, at 14:03, Yann Ylavic wrote: >> -#define APR_BUFFER_MAX APR_SIZE_MAX/2 >> +#define APR_BUFFER_MAX (APR_SIZE_MAX/2-1) > > It seems that the ->size does include the terminating NUL byte so > APR_BUFFER_MAX could be APR_SIZE_MAX/2 no? Why -1 here? > Also maybe ->size should be

Update doxygen site

Hi all, Updating the doxygen site at https://apr.apache.org/docs/apr/2.0/modules.html - is it as simple as replacing the files under https://svn.apache.org/repos/asf/apr/site/trunk/docs/docs/apr/trunk/ or is there more to the process than that? Regards, Graham --

Re: RFC: APR 2.0 modularization

On 22 Apr 2024, at 14:30, Ivan Zhakov wrote: > Can you confirm why xlate/iconv cannot be moved to a module? (No expectation > for you to do such a move, just want to understand what makes it impossible). >> > I think it can be done in theory, but I see potential problem: API should be >

Re: svn commit: r1917050 - in /apr/apr/trunk: CHANGES crypto/apr_crypto.c dbd/apr_dbd.c dbm/apr_dbm.c include/private/apu_internal.h util-misc/apu_dso.c

On 22 Apr 2024, at 14:05, Ruediger Pluem wrote: >>> Now the caller needs to allocate memory even if it is not interested in the >>> error or if there is no error at all. >>> Wouldn't it be better to add an apu_err_t **err instead (which can be NULL) >>> and in case of an error allocate an >>>

Re: svn commit: r1917266 - in /apr/apr/trunk: buffer/apr_buffer.c include/apr_buffer.h test/testbuffer.c

On 22 Apr 2024, at 14:13, Ruediger Pluem wrote: >> @@ -322,7 +287,17 @@ APR_DECLARE(int) apr_buffer_ncmp(const a >> return 1; >> } > > There was a proposal from Yann to simplify the above block to > >if (!src) { >return dst ? 1 : 0; >} >if (!dst) { >

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

On 18 Apr 2024, at 17:07, Yann Ylavic wrote: > If so maybe: > > typedef struct > { >union { >char *str; >void *mem; >} d; > #if APR_SIZEOF_VOIDP == 8 > # define APR_BUFFER_SIZE_WIDTH 63 > #else > # define APR_BUFFER_SIZE_WIDTH 31 > #endif > apr_size_t

Re: RFC: APR 2.0 modularization

On 22 Apr 2024, at 12:52, Ivan Zhakov wrote: >> The question is, is it worth it for such a marginal change? >> Have you looked in to the practicalities and verified no major stumbling >> blocks, >> bearing in mind that developer effort tends to be thin on the ground? >> > > Take the Apache

Re: RFC: APR 2.0 modularization

On 20 Apr 2024, at 11:38, Ivan Zhakov wrote: > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing. At the time, and with time and hindsight, I never understood what the point was at combining APR and APR-util. The reason is because... > But we also merged everything

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

On 18 Apr 2024, at 15:57, Yann Ylavic wrote: >> could be: >> APR_DECLARE(apr_status_t) apr_buffer_str_set(apr_buffer_t *buf, >> char *str, apr_size_t len) >> { >>if (len == APR_BUFFER_STRING) { >>len = str ? strlen(str) : 0; >>} >>

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

On 18 Apr 2024, at 13:15, Yann Ylavic wrote: > Indeed at least APR_BUFFER_MAX and buf->size of should be of the same > signedness. APR_BUFFER_MAX represents the size limit visible outside the API. This is always positive. buf->size is an internal implementation detail. This is invisible. The

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

On 18 Apr 2024, at 12:14, Ruediger Pluem wrote: >> +#define APR_BUFFER_MAX APR_SIZE_MAX/2 > > Why no longer APR_OFF_MAX? As was pointed out, apr_off_t is always 64 bits would still break on Windows. Inside the API, we need a very big, signed, value, and apr_off_t is perfect. Outside the API,

Re: svn commit: r1917099 - /apr/apr/trunk/test/testldap.c

On 18 Apr 2024, at 08:48, minf...@apache.org wrote: > URL: http://svn.apache.org/viewvc?rev=1917099=rev > Log: > Add the LDAP test case. I am getting a failure on Windows about a missing symbol, I am assuming the changes to cmake are incomplete. Would it be possible for someone to look at the

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

On 17 Apr 2024, at 08:12, Ruediger Pluem wrote: >> I need some advice on handling Windows 32 bit. apr_int64_t for size is too >> big, and tests are failing. >> >> Technically apr_ssize_t is the right size, but the definition of ssize_t is >> [-1, SSIZE_MAX]. I need a signed very big number.

Re: svn commit: r1917050 - in /apr/apr/trunk: CHANGES crypto/apr_crypto.c dbd/apr_dbd.c dbm/apr_dbm.c include/private/apu_internal.h util-misc/apu_dso.c

On 17 Apr 2024, at 08:07, Ruediger Pluem wrote: >> Modified: apr/apr/trunk/util-misc/apu_dso.c >> URL: >> http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apu_dso.c?rev=1917050=1917049=1917050=diff >> == >> ---

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

On 17 Apr 2024, at 07:52, Ruediger Pluem wrote: >> +APR_DECLARE(apr_buffer_t *) apr_buffer_str_make(apr_pool_t *pool, >> +char *str, apr_ssize_t len) >> +{ >> +apr_buffer_t *buf; >> +apr_int64_t size; >> +apr_size_t slen; >> + >> +

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

Hi all, > +/** > + * Structure for efficiently tracking a buffer that could contain > + * a zero terminated string, or a fixed length non zero string. > + */ > +typedef struct > +{ > +/** pointer to the data, which could be a string or a memory block. */ > +union { > +char *str; >

Re: svn commit: r1914814 - in /apr/apr/trunk: CHANGES encoding/apr_escape.c include/apr_escape.h test/testescape.c tools/gen_test_char.c

On 21 Dec 2023, at 06:11, Ruediger Pluem wrote: >> +APR_DECLARE(apr_status_t) apr_escape_json(char *escaped, const char *str, >> +apr_ssize_t slen, int quote, apr_size_t *len) > > Shouldn't we provide a length for the escaped buffer to be able to do some > sanity checking against

Re: getopt error message with a bare "-"

On 28 Nov 2023, at 07:46, Daniel Sahlberg wrote: > Subversion is using APR's apr_getopt_long for command line processing. > > A user tried to supply "-" for the filename with the intention of using stdin > (Subversion has support for this in our code). However the user got the > following

Re: POC: updated LDAP support for apr-util 1.7

On 19 Sep 2023, at 11:34, Ruediger Pluem wrote: >> /* For DSO builds, export the table of entry points into the apr_ldap DSO > > In the end I think this effort only makes sense if we find a way to get LDAP > back into trunk. > I cannot remember if these enhancements would be enough to address

Re: Cross compiling APR

On 02 May 2023, at 08:16, Stephen Webb wrote: > Does cross compilation work in theory? > > Am I wasting my time attempting to add support for cross compilation to the > conan package manager? As I recall the cross complication I got to work was for the benefit of openwrt, which a while back

POC: updated LDAP support for apr-util 1.7

() and + apr_ldap_set_option_ex() with support for the apr_ldap_t type. + [Graham Leggett] + *) apr_crypto_openssl: Compatibility with OpenSSL 3. [Yann Ylavic] *) configure: Fix configure for compilers which don't accept implicit Index: build/apu-conf.m4

Re: apr_dbm API and BerkleyDB

Hi, Let’s try this again. apr_dbm API. Regards, Graham —

apr_dbd API and BerkleyDB

Hi all, BerkleyDB is gone in SUSE and going away in RHEL[1]. How does this practically affect the apr-dbd API? We support gdbm, but that’s GPLv3. Do we need a new implementation? [1] https://access.redhat.com/articles/6464541 Regards, Graham —

Release apr-util v1.7.0

Hi all, I’d like to see a release of apr-util v1.7.0. Does anyone know of any problems outstanding that might need fixing? Regards, Graham —

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

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

Re: Dropping Netware code from Windows apr/trunk

On 08 Dec 2021, at 14:37, Nick Kew wrote: > If you can do that cleanly then great! > > Should we draw a clean line under released branches, > so anything later than 1.7.x drops Netware, regardless > of whether it's a 1.8 or a 2.0? For v2.0 and above it’s fine to remove support for old

Re: svn commit: r1894551 - in /apr/apr/trunk: buckets/apr_brigade.c configure.in include/apr.h.in include/apr.hnw include/apr.hw include/apr.hwc

On 25 Oct 2021, at 12:30, Ruediger Pluem wrote: >> begin is unused. Will fix. >> + >> +while ((hay = memchr(hay, *(char *)needle, len))) { > > Does memchr have a defined behaviour for len == 0? This can happen if > *(char *)needle is found at hay[len -1 ] but the memcmp below is not

Re: svn commit: r1894423 - /apr/apr/trunk/buckets/apr_brigade.c

On 21 Oct 2021, at 12:57, Ruediger Pluem wrote: >> * >> * Bump one byte off, and loop round to search again. >> */ >> -apr_bucket_split(e, 1); >> -APR_BUCKET_REMOVE(e); >> -APR_BRIGADE_INSERT_TAIL(bbOut, e); >> - >> -outbytes++; >> +

Re: svn commit: r1894380 - in /apr/apr/trunk: buckets/apr_brigade.c include/apr_buckets.h test/testbuckets.c

On 20 Oct 2021, at 10:43, Yann Ylavic wrote: > apr_strnstr() maybe, strnstr() is non-standard AFAICT and possibly not > available on all platforms (Windows)? This needs to be memmem really, as the boundary isn’t always a string. Memmem is non portable and old versions are buggy. Is there

Re: svn commit: r1890952 - in /apr/apr/trunk: CHANGES dbm/apr_dbm.c dbm/apr_dbm_berkeleydb.c dbm/apr_dbm_gdbm.c dbm/apr_dbm_ndbm.c dbm/apr_dbm_sdbm.c include/apr_dbm.h include/private/apr_dbm_private.

On 22 Jun 2021, at 16:39, Yann Ylavic wrote: > Maybe use : > apr_status_t rv = APR_ENOTIMPL; > char *buffer = apr_psprintf(pool, "%pm", ); > > to avoid arbitrary ERROR_SIZE allocation? Pulled on a thread with this one. The function apr_dso_error() returns a standard APR

apr_proc_create() clobbers stdin in the parent

Hi all, I am using apr_proc_create() to run a process in the middle of parsing a command line (think something similar to bash completion), and have run into a problem. Key to both the replxx and the libedit libraries is that stdin has to be set unbuffered so that key bindings can be

Re: Proposal: apr-tools project

On 18 Jan 2021, at 12:43, Graham Leggett wrote: > Moving from the theory to making this real: > > https://github.com/minfrin/apr-tools > > The first tool is called “endec”[1], and exposes all the APR apr_encode.h and > apr_escape.h functions. Generated man page i

Re: Proposal: apr-tools project

On 27 Jul 2019, at 21:29, William A Rowe Jr wrote: > I'd think that the APT Project (Apache Portable Tools?) would be a good > community to kick off, and it should be independent and self organizing. It > should follow its own versioning and release schema, since what is best > practice for

Re: svn commit: r1883868 - /apr/apr/trunk/encoding/apr_encode.c

On 27 Nov 2020, at 18:54, yla...@apache.org wrote: > URL: http://svn.apache.org/viewvc?rev=1883868=rev > Log: > apr_encode_base32: fix estimated output *len (when called with src == NULL). A small detail - the API returns exact lengths across all apr_encode calls, none of these are estimates.

Re: Xcode 12

On 29 Oct 2020, at 14:05, Jim Jagielski wrote: > Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system at least > it is throwing errors about -Werror,-Wimplicit-function-declaration, and not > enabling IPv6: > >checking if APR supports IPv6... no -- no working getaddrinfo >

Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expa

On 24 Jul 2020, at 17:03, Nick Kew wrote: >> Another ping on this one - the apr-util 1.7 build is still broken. > > Whoops! I'd completely forgotten that. > > Thanks for the partial patch. Do you want to commit it? I’ve just committed http://svn.apache.org/viewvc?rev=1880286=rev

Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expa

On 06 Aug 2019, at 15:55, Rainer Jung wrote: > Just a reminder, that APR-UTIL 1.7.x still doesn't compile due to the wrong > handling of INCLUDES. Another ping on this one - the apr-util 1.7 build is still broken. Tried a number of options to fix it, the includes sort of works if you try the

Re: apr_jose_decode.c gcc warnings

On 27 Mar 2020, at 21:20, Ruediger Pluem wrote : > Why are functions that are supposed to be static in the apr_ namespace? > IMHO this is confusing when reading code. Are you asking the actual question why, or are you just pointing out that they shouldn’t be in the apr_ namespace? Regards,

Re: apr_jose_decode.c gcc warnings

On 27 Mar 2020, at 10:48, Joe Orton wrote: > I assume all these functions should be declared static but haven't > looked at the code. branches/1.7.x as at r1875766 - If they’re not in the header file they should be static, yes. Cut and paste is fun. Regards, Graham — smime.p7s

Re: svn commit: r1836445 [1/3] - in /apr/apr-util/branches/1.7.x: ./ crypto/ include/ include/private/ test/

On 07 Aug 2019, at 00:55, Rainer Jung wrote: > Solaris(10) provides NSS support but it is somewhat outdated. Especially it > does not know about SEC_OID_SHA224, so compilation (linking) fails. > > So currently APR trunk and APR-UTIL 1.7.x no longer compile on Solaris (1.7.x > has more

Re: svn commit: r1836445 [1/3] - in /apr/apr-util/branches/1.7.x: ./ crypto/ include/ include/private/ test/

On 07 Aug 2019, at 00:55, Rainer Jung wrote: > Solaris(10) provides NSS support but it is somewhat outdated. Especially it > does not know about SEC_OID_SHA224, so compilation (linking) fails. > > So currently APR trunk and APR-UTIL 1.7.x no longer compile on Solaris (1.7.x > has more

Re: [PATCH] Add configure variable for strerror_r check

On 05 Feb 2020, at 21:14, Sebastian Kemper wrote: > APR's configure script uses AC_TRY_RUN to detect whether the return type > of strerror_r is int. When cross-compiling this defaults to no. > > This commit adds an AC_CACHE_CHECK so users who cross-compile APR may > influence the outcome with a

Re: [PATCH] Add configure variable for /dev/zero mmap check

On 05 Feb 2020, at 21:40, Sebastian Kemper wrote: > APR's configure script uses AC_TRY_RUN to detect whether /dev/zero can > be mmaped. When cross-compiling this defaults to no. While APR compiles > fine like this (since r1873594 in the APR 1.7 branch), the apr_lock > implementation method falls

Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/ build/apr_threads.m4 configure.in locks/unix/proc_mutex.c

On 03 Jan 2020, at 12:37, Yann Ylavic wrote: >> Looking at the PTHREAD matches in apr.h: >> >> #define APR_USE_PROC_PTHREAD_SERIALIZE1 >> #define APR_HAS_PROC_PTHREAD_SERIALIZE0 > > Inconsistent :/ > > I can think of two ways to fix it: > 1. don't check for /dev/zero for PROC_PTHREAD

Re: svn commit: r1856051 - in /apr/apr/branches/1.7.x: ./ build/ build/apr_threads.m4 configure.in locks/unix/proc_mutex.c

On 22 Mar 2019, at 15:21, yla...@apache.org wrote: > Author: ylavic > Date: Fri Mar 22 13:21:27 2019 > New Revision: 1856051 > > URL: http://svn.apache.org/viewvc?rev=1856051=rev > Log: > Merge r1856022 from trunk: > > Use proc mutex pthread by default when robust[_np] > > On platforms that

Re: Backports to consider for 1.6.4?

On 30 Aug 2018, at 05:30, William A Rowe Jr wrote: > Second; > Are we comfortable adding a dependency on autoconf-archive? > This macro below dates back to 2010. If we are not, I can > revert this. In any case, I think it would be unwise to introduce > this before 1.7, we generally haven't

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

On 23 Aug 2019, at 14:34, 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

Re: Proposal: apr-tools project

On 25 Jul 2019, at 14:26, Nick Kew wrote: > Would that be purely in C, or could it be a mix, perhaps including scripting > languages? Purely in C. Exposing APR to other languages through something like swig also sounds useful, but that’s not my goal here. > First thought: harmless, but how

Proposal: apr-tools project

Hi all, Disclaimer: I don’t have time to do this right now, but at some point soon I would like to get something like this done. I propose the creation of, in addition to apr and apr-util, the apr-tools project. apr-tools would contain a series of command line tools that correspond with many

Re: svn commit: r1833421 - in /apr/apr/trunk: ./ build/ crypto/ include/ include/private/ test/

On 24 Jul 2018, at 16:12, Graham Leggett wrote: > On 24 Jul 2018, at 15:26, Yann Ylavic <mailto:ylavic@gmail.com>> wrote: > >>> Having looked at this in more detail, I am -1 on this change on the >>> following basis: >>> >>> - We crea

Re: svn commit: r1860980 - /apr/apr/trunk/build/crypto.m4

On 11 Jun 2019, at 17:55, William A Rowe Jr wrote: > I'm totally confused, these libs have been installed across three paths? Potentially (and confusingly), yes. > - nss_LDFLAGS="-L$withval/lib " > + nss_LDFLAGS="-L$withval/lib -L$withval/lib/nss -L$withval/lib/nspr “ NSS depends on

Re: The case for apr-util-2.0

On 06 Jun 2019, at 07:07, Mladen Turk wrote: > Then, at some point of time, apr-util introduced modules and > become wrapper around third party libraries. > Suddenly it got bloated to extremes. It become a dump spot for > whatever database, crypto library ... whatever wrapper. Remember that

Re: [vote] Release apr-1.7.0 ?

On 01 Apr 2019, at 20:01, William A Rowe Jr wrote: > Candidate tarballs are at the usual location; > https://apr.apache.org/dev/dist/ > > For the release of apr-1.7.0 > [ ] +1 looks great! > [ ] -1 something is broken > > This vote will conclude April

Re: apr_json object key doublons

On 01 Sep 2018, at 13:13, Yann Ylavic wrote: > So how about the attached patch too, allowing for case sensitive apr_tables? > :p > apr_json could then use apr_table_make_ex()… I like the idea of a case sensitive apr_table, it’s something that would have been useful to me in the past. Using

Re: svn commit: r1839779 - in /apr/apr/trunk/json: apr_json.c apr_json_decode.c

On 01 Sep 2018, at 13:06, Yann Ylavic wrote: >> Looking at 1839779 and 1839755, both of these need to be reverted as they >> break RFC compliance with respect to the JSON RFC and JOSE RFCs (I’m -1 on >> these changes). > > There is probably another solution, see below. > >> >> Please can

Re: svn commit: r1839779 - in /apr/apr/trunk/json: apr_json.c apr_json_decode.c

On 31 Aug 2018, at 19:56, yla...@apache.org wrote: > Author: ylavic > Date: Fri Aug 31 17:56:40 2018 > New Revision: 1839779 > > URL: http://svn.apache.org/viewvc?rev=1839779=rev > Log: > apr_json: follow up to r1839755: preserve formatting when decoding object > valueT > > The object

Re: apr_json object key doublons

On 31 Aug 2018, at 22:19, Yann Ylavic wrote: > Actually this updated patch, rather. > There is no more copy with an apr_table than with an apr_hash (we > still point to the given key). > I also added apr_json_object_add() for explicitely allowing doublons, > while apr_json_object_set() still

Re: apr_json object key doublons

On 31 Aug 2018, at 14:26, Yann Ylavic wrote: > I wonder if we shouldn't change the apr_hash_t (currently used to > handle JSON objects) to an apr_table_t, such that key doublons are not > an issue (this isn't one in JSON specification AFAICT). > > Then we could get rid of 'klen' handling in

Re: svn commit: r1833421 - in /apr/apr/trunk: ./ build/ crypto/ include/ include/private/ test/

On 24 Jul 2018, at 17:26, Yann Ylavic wrote: >>> This is being discussed in the other, so I won't my arguments here. >> >> Just to clarify, I’m -1 (veto). > > So I have to convince you (let's try again :p ) or revert, this is it? > I'd like to ear what others think though… Rather than

Re: svn commit: r1833359 - in /apr/apr/trunk: CHANGES CMakeLists.txt build.conf build/crypto.m4 crypto/apr_crypto.c crypto/apr_crypto_prng.c include/apr.h.in include/apr_crypto.h test/testcrypto.c thr

On 24 Jul 2018, at 14:25, Yann Ylavic wrote: >> I’m not seeing that this functionality being PRNG, or the apparent >> simplicity of it being relevant in any way. >> >> We’ve created a hard link between APR and OpenSSL, in a system where >> we already have a clean DSO based system to interface

Re: svn commit: r1833421 - in /apr/apr/trunk: ./ build/ crypto/ include/ include/private/ test/

On 24 Jul 2018, at 15:26, Yann Ylavic wrote: >> Having looked at this in more detail, I am -1 on this change on the >> following basis: >> >> - We create a hard link between our crypto libraries and APR itself, >> which both breaks and renders pointless the existing DSO mechanism, >> and makes

Re: svn commit: r1833421 - in /apr/apr/trunk: ./ build/ crypto/ include/ include/private/ test/

On 12 Jun 2018, at 22:11, yla...@apache.org wrote: > Author: ylavic > Date: Tue Jun 12 20:11:09 2018 > New Revision: 1833421 > > URL: http://svn.apache.org/viewvc?rev=1833421=rev > Log: > apr_crypto: follow up to r1833359. > > Link underlying crypto libraries (openssl, nss, and commoncrypto)

Re: svn commit: r1836439 [2/3] - in /apr/apr/trunk: ./ crypto/ include/ include/private/ test/

On 23 Jul 2018, at 01:26, Yann Ylavic wrote: > On Sun, Jul 22, 2018 at 3:11 PM, wrote: >> --- apr/apr/trunk/crypto/apr_crypto_openssl.c (original) >> +++ apr/apr/trunk/crypto/apr_crypto_openssl.c Sun Jul 22 13:11:32 2018 >> >> @@ -106,16 +143,87 @@ static apr_status_t crypto_error(const a >>

Re: svn commit: r1833359 - in /apr/apr/trunk: CHANGES CMakeLists.txt build.conf build/crypto.m4 crypto/apr_crypto.c crypto/apr_crypto_prng.c include/apr.h.in include/apr_crypto.h test/testcrypto.c thr

On 23 Jul 2018, at 01:10, Yann Ylavic wrote: >>> +/* XXX: APU_HAVE_CRYPTO_PRNG shoudn't be defined! */ >>> +#error apr_crypto_prng implemented with OpenSSL only for now >> >> The layout of the code goes against the established structure of the >> apr_crypto API, all of this openssl specific

Re: svn commit: r1833359 - in /apr/apr/trunk: CHANGES CMakeLists.txt build.conf build/crypto.m4 crypto/apr_crypto.c crypto/apr_crypto_prng.c include/apr.h.in include/apr_crypto.h test/testcrypto.c thr

On 12 Jun 2018, at 12:06 AM, yla...@apache.org wrote: > Author: ylavic > Date: Mon Jun 11 22:06:09 2018 > New Revision: 1833359 > > URL: http://svn.apache.org/viewvc?rev=1833359=rev > Log: > Cryptographic Pseudo Random Number Generator (CPRNG). > > New apr_crypto_prng API and

Re: svn commit: r1835348 - in /apr/apr/trunk: CHANGES build.conf include/apr_json.h json/ json/apr_json.c json/apr_json_decode.c json/apr_json_encode.c test/Makefile.in test/abts_tests.h test/testjson

On 08 Jul 2018, at 4:23 PM, Yann Ylavic wrote: >> +static apr_status_t apr_json_decode_boolean(apr_json_scanner_t * self, int >> *retval) >> +{ >> +if (self->p >= self->e) >> +return APR_EOF; >> + >> +if (self->e - self->p >= 4 && strncmp("true", self->p, 4) == 0 && >> +

Re: svn commit: r1835348 - in /apr/apr/trunk: CHANGES build.conf include/apr_json.h json/ json/apr_json.c json/apr_json_decode.c json/apr_json_encode.c test/Makefile.in test/abts_tests.h test/testjson

On 08 Jul 2018, at 3:31 PM, Yann Ylavic wrote: > Since the other apr_json_decode_*() functions are not thread-safe (and > shouldn't be), couldn't we (re)use a single self->ptemp here (cleared > before leaving)? > The locking potentially done by apr_pool_create() looks unnecessary, > or at least

Re: svn commit: r1835348 - in /apr/apr/trunk: CHANGES build.conf include/apr_json.h json/ json/apr_json.c json/apr_json_decode.c json/apr_json_encode.c test/Makefile.in test/abts_tests.h test/testjson

On 08 Jul 2018, at 2:55 PM, Yann Ylavic wrote: >> +if (*p == 'u') { >> +if (p + 4 >= e) { >> +status = APR_EOF; >> +goto out; >> +} >> +p += 5; >> +string.len += 4;/* an UTF-8

Re: Talking json

On 08 Jul 2018, at 2:28 PM, Graham Leggett wrote: > For the record, JSON support has landed in apr v2.0 and apr-util v1.7 > respectively: > > http://svn.apache.org/viewvc?rev=1835348=rev > <http://svn.apache.org/viewvc?rev=1835348=rev> > http://svn.apache.org/viewvc?

Re: Talking json

On 13 Mar 2016, at 2:03 AM, Nick Kew wrote: > I'm working on a module for HTTPD that needs to talk json: > read client requests, and send responses. > > Before I re-invent this particular wheel, is anyone aware > of existing code under apache-compatible license that parses > json to an APR

Re: buildbot failure in on apr-x64-macosx-trunk

On 25 Jun 2018, at 11:09 PM, build...@apache.org wrote: > > The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while > building . Full details are available at: >https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/109 > > Buildbot URL: https://ci.apache.org/ > >

Re: SHA256 and friends.

On 19 Jan 2017, at 18:29, Dirk-Willem van Gulik wrote: > Am wondering now it if makes sense to create a new directory with: > >hash/* > > section (or something in crypto) where I cull things/move out of the current > apr_random, sha256_glue and apr_md4/5 and apr_sha1

Re: Getting old - auto scrub version of palloc

On 19 Jan 2017, at 4:17 PM, Dirk-Willem van Gulik wrote: > I must be getting old - I am pretty sure I used in the past a pool alloc that > would nicely scrub any keys from memory upon pool clear down; along with some > locking of the page on unix & and some magic to make

Re: pool based base64 binary encode

On 19 Jan 2017, at 3:22 PM, Dirk-Willem van Gulik wrote: > Any reason we do not have such in APR-2 (as a compagnion to > apr_pbase64_encode) ? > > Dw. > > > > APR_DECLARE(char *) apr_pbase64_encode_binary(apr_pool_t *p, const unsigned > char *string, int len) > { >

Re: Right magic to test the crypto modules

On 19 Jan 2017, at 12:47 PM, Dirk-Willem van Gulik wrote: >>> What is the right/proper way to test the crypto modules (as they are not >>> copied into apr/.lib during a normal build) from 'test/testall' ? >> >> I've always used "make test" from the root, it seems to do

Re: Right magic to test the crypto modules

On 18 Jan 2017, at 22:14, Dirk-Willem van Gulik wrote: > What is the right/proper way to test the crypto modules (as they are not > copied into apr/.lib during a normal build) from 'test/testall' ? I've always used "make test" from the root, it seems to do the right

Re: apr_redis

On 02 Nov 2016, at 2:20 PM, Jim Jagielski wrote: > OK, so my plan is to start pulling the relevant bits out of Credis for > use in apr_redis. I was thinking initially about maybe just using the > library, but for parity w/ apr_memcache, that doesn't make sense. > > Here's the

Re: Redis and mod_cache/mod_socache

On 31 Oct 2016, at 5:05 PM, Jim Jagielski wrote: > Moving to APR: > > Query: Think it would be worth my time to work on a Redis > implementation for APR-util? I am working on a minimal Redis > lib, related to work, which is basically a soft reboot of Credis > from GoogleCode,

Fwd: DAV Option Patch

Hi all, I recently asked the author of mod_dav_acl whether they would donate their apr and apr-util patches to the APR project, and (in the following message) they said yes. Regards, Graham -- > Begin forwarded message: > > From: Graham Leggett <minf...@sharp.fm> > Subjec

Fwd: DAV Option Patch

Hi, Here is their response for the record. Regards, Graham — > Begin forwarded message: > > From: Jari Urpalainen <jari.urpalai...@nokia.com> > Subject: Re: Fwd: DAV Option Patch > Date: 31 May 2016 at 7:43:51 AM SAST > To: Graham Leggett <minf...@sharp.fm> >

apr_splice_io: A more modern approach to sendfile

Hi all, Various platforms have richer support for zero copy than they used to, no longer are we limited to just “send file to socket”. In order to support this portably, I propose the following API, with 4 simple function calls covering the 4 possible combinations of apr_file_t and

Re: Provide our own impl of str[n]casecmp()?

On 21 Nov 2015, at 12:11 AM, William A Rowe Jr wrote: > Any objections to picking this up for APR 1.next/2.0? > > It seems that httpd isn't the only one who wants to be strict about > case-insensitive token string recognition, and non-POSIX char case > gets weird quickly.

Re: expat upgrade to 2.1.0

On 31 Oct 2015, at 7:48 PM, Michael Felt wrote: > I would like to repspond positively on this suggestion that "something" be > done. > It could be updated, and fortunately expat is not a package with frequent > (security) updates, > but it is external. What may have been

Re: Lua co-routines

On 26 Sep 2015, at 9:11 PM, Branko Čibej wrote: > Whilst I agree that co-routines are useful, I don't see a good reason to > fold this into APR. I feel that APR has already departed far from its > "portable runtime" promise. With database connectors and whatnot it's > become a

Re: centos7 apr-1.5.1 rpmbuild fail

On 16 Feb 2015, at 3:20 AM, 河本和彦 kohm...@iris.eonet.ne.jp mailto:kohm...@iris.eonet.ne.jp wrote: I wonder if this error has been already known or reported, in the following conditions, rpmbuild does not work well. CentOS Linux release 7.0.1406 (Core) kernel 3.10.0-123.20.1.el7.x86_64

Re: [Patch] apr-crypto: support for symmetric keys (for HLS)

On 01 Dec 2014, at 2:58 AM, Graham Leggett minf...@sharp.fm wrote: The HLS protocol calls for the ability to do aes128 encryption using a symmetrical key. This updated patch caters for IV sizes that are not equal to the block size. Regards, Graham — apr-crypto-secretkey2.patch Description

[Patch] apr-crypto: support for symmetric keys (for HLS)

Hi all, The HLS protocol calls for the ability to do aes128 encryption using a symmetrical key. The attached patch introduces the apr_crypto_key() function that deprecates the apr_crypto_passphrase() function, and allows either passphrases or symmetrical secrets to be passed to the crypto

Re: What's need for http/2.0?

On 23 Sep 2014, at 9:45 PM, Jim Jagielski j...@jagunet.com wrote: APR: Considering that before we know it, http/2.0 will be here, and ignoring httpd for the time being, what features/additions do we see as being needed to support http/2.0 from an APR library level? How do we compare w/

Re: Sorting an apr_array

On 28 Apr 2014, at 1:06 PM, Nick Kew n...@apache.org wrote: I find myself wanting to sort an APR array. As it stands I can hack it using the array innards from apr_tables.h: qsort(arr-elts, arr-nelts, arr-elt_size, my_compare); Any interest in APR-izing that into an apr_array_sort

Re: svn commit: r1587750 - in /apr/apr/branches/1.5.x: ./ include/apr_errno.h

On 16 Apr 2014, at 1:22 AM, traw...@apache.org wrote: Author: trawick Date: Tue Apr 15 23:22:29 2014 New Revision: 1587750 URL: http://svn.apache.org/r1587750 Log: Revert the following, since it introduces a new API: Merge r1561040 from trunk: Using UDS, we sometime try ops not

Re: svn commit: r1587750 - in /apr/apr/branches/1.5.x: ./ include/apr_errno.h

On 25 Apr 2014, at 12:40 PM, Jeff Trawick traw...@gmail.com wrote: Would you like to apply this to v1.6? Not personally... I don't recall the use case, only that it didn't belong in 1.5.x. You should maintain the 1.6.x branch until others on their own terms find a compelling reason to

Re: No v1.6.x branch?

On 22 Apr 2014, at 3:04 PM, Jeff Trawick traw...@gmail.com wrote: IMHO as a httpd+apr dev: * If httpd trunk switches to apr escape API to the extent practical and throws out its own implementation, and unreleased APR features are the natural way to accommodate that, I think that is ample

No v1.6.x branch?

Hi all, I notice there is no APR v1.6.x branch, would the right thing to do to be to create one from the head of the v1.5.x branch? Regards, Graham --

Re: No v1.6.x branch?

On 21 Apr 2014, at 2:48 PM, Jeff Trawick traw...@gmail.com wrote: 1.5.x HEAD is the place to branch from. For example, see http://svn.apache.org/viewvc?view=revisionrevision=887002 ((Copied from apr/apr/branches/1.4.x, r887001)) I agree with Stefan's response in this previous thread

Re: No v1.6.x branch?

On 21 Apr 2014, at 3:00 PM, Jeff Trawick traw...@gmail.com wrote: I don't think so; regardless, the concern about maintaining another branch that isn't being released is pretty simple to resolve: Identify what additions you think are compelling reasons for another branch and approximately

Re: No v1.6.x branch?

On 21 Apr 2014, at 3:16 PM, Jeff Trawick traw...@gmail.com wrote: r1588878, and soon if practical, given we've just released v1.5.1. What does that commit have to do with having just released 1.5.1? The commit is an addition to the API, and as such as not eligible for backport to the v1.5.x

Re: APR-UTIL 1.5.3 rpmbuild error: File not found by glob: apr_dbd_pgsql*

On 12 Mar 2014, at 4:52 AM, WR - Widyachacra Rajapaksha | විද්‍යාචක්‍ර widyacha...@gmail.com wrote: I'm trying to build apr-util-1.5.3.tar.bz2 which I downloaded from your site. I'm getting the bellow error while building the RPM using rpmbuild -tb apr-util-1.5.3.tar.bz2 and I couldn't

Re: APR-UTIL 1.5.3 rpmbuild error: File not found by glob: apr_dbd_pgsql*

On 13 Mar 2014, at 8:23 AM, Nick Kew n...@webthing.com wrote: So while pgsql support is optional in apr-util's normal build, rpmbuild is treating the absence of the pgsql driver as a fatal error? The same logic appears to apply to all the DBD drivers. Isn't that a recipe for trouble when

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

On 18 Feb 2014, at 10:35 PM, Eric Covener cove...@gmail.com wrote: 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. I am

Re: APR Util Question

On 01 Feb 2014, at 3:55 PM, Jeff Trawick traw...@gmail.com wrote: APR folks, shouldn't users normally override the prefix when building the RPMs in order to leave the system-provided libraries and anything depending on them untouched? They shouldn't, no. RPMs are system libraries by

  1   2   3   4   5   6   7   >