You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Evgeny Kotkov <ev...@visualsvn.com.INVALID> on 2023/05/26 10:53:18 UTC
[VOTE] Release Apache Serf 1.3.10
Hi all,
Please find below the proposed release artifacts:
https://dist.apache.org/repos/dist/dev/serf/
I would like to call a VOTE to release these as Apache Serf 1.3.10.
[ ] +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.
As an additional note, I would like to propose that we keep just the single
current RM's signature in the .asc files, as this seems to be a common
practice, and also to avoid the "gpg: WARNING: multiple signatures detected"
warning during verification. In other words, a +1 posted in this email
thread should suffice.
The changelog for version 1.3.10 is included below:
- Support for OpenSSL 3
- Fix issue #171: Win32: Running tests fails with "no OPENSSL_Applink" error
- Fix issue #194: Win32: Linking error when building against OpenSSL 1.1+
- Fix issue #198: OpenSSL BIO control method incorrectly handles
unknown requests
- Fix issue #202: SSL tests are not passing with OpenSSL 3
- Fix error handling when reading the outgoing request body
- Fix handling of invalid chunk lengths in the dechunk bucket
- Fix an endless loop in the deflate bucket with truncated input
- Fix BIO control handlers to support BIO_CTRL_EOF
- Fix a CRT mismatch issue caused by using certain OpenSSL functions
- Build changes to support VS2017, VS2019 and VS2022
- Build changes to support Python 3
Thanks,
Evgeny Kotkov
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Lieven Govaerts <lg...@mobsol.be>.
Thanks for getting this release out Evgeny!
L.
On Wed, 31 May 2023 at 10:43, Evgeny Kotkov
<ev...@visualsvn.com.invalid> wrote:
>
> Evgeny Kotkov <ev...@visualsvn.com> writes:
>
> > Hi all,
> >
> > Please find below the proposed release artifacts:
> >
> > https://dist.apache.org/repos/dist/dev/serf/
> >
> > I would like to call a VOTE to release these as Apache Serf 1.3.10.
> >
> > [ ] +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.
>
> Vote passes with three binding +1 and no negative votes:
>
> +1: jerenkrantz, stsp, ivan
>
> I will finalize the release some time over the next day or two.
>
>
> Thanks,
> Evgeny Kotkov
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Evgeny Kotkov <ev...@visualsvn.com.INVALID>.
Evgeny Kotkov <ev...@visualsvn.com> writes:
> Hi all,
>
> Please find below the proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/serf/
>
> I would like to call a VOTE to release these as Apache Serf 1.3.10.
>
> [ ] +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.
Vote passes with three binding +1 and no negative votes:
+1: jerenkrantz, stsp, ivan
I will finalize the release some time over the next day or two.
Thanks,
Evgeny Kotkov
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 29, 2023 at 01:59:31PM -0400, Sven F. wrote:
> could you guys push something like
>
> -#ifdef USE_OPENSSL_1_1_API
> +#if defined(USE_OPENSSL_1_1_API) && !defined(LIBRESSL_VERSION_NUMBER)
>
> so OPENSSL_malloc_init() is not use with other ssl libs ?
You probably found this patch in the OpenBSD ports tree. It is not
supposed to be upstreamed like this. Spraying around more #ifdefs
won't improve the situation in the long term.
It is a quick hack that fixes the build on OpenBSD but it is a bad
approach for upstream code because upstream would now hardcode not
just one, but two specific SSL libraries. While other SSL libraries
which provide compatible interfaces exist.
There is already a better fix in the queue which detects these interfaces
in a vendor-neutral fashion. Serf will then use OPENSSL_malloc_init() only
if this function exists. Serf shouldn't have to care whether this function
really comes from OpenSSL 1.1 or from some other implementation or version.
Standard configure scripts have worked this way for years. As an analogy,
nobody cares whether malloc() comes from glibc or musl or another C library,
for good reasons. OpenSSL is a de-facto standard API and it should thus be
treated in the same responsible way as other standard libraries.
And in any case, it is too late to merge more changes into this release.
Re: [VOTE] Release Apache Serf 1.3.10
Posted by "Sven F." <sv...@gmail.com>.
could you guys push something like
-#ifdef USE_OPENSSL_1_1_API
+#if defined(USE_OPENSSL_1_1_API) && !defined(LIBRESSL_VERSION_NUMBER)
so OPENSSL_malloc_init() is not use with other ssl libs ?
On Mon, May 29, 2023 at 12:46 PM Ivan Zhakov <iv...@apache.org> wrote:
>
> On 2023/05/26 10:53:18 Evgeny Kotkov wrote:
> > Hi all,
> >
> > Please find below the proposed release artifacts:
> >
> > https://dist.apache.org/repos/dist/dev/serf/
> >
> > I would like to call a VOTE to release these as Apache Serf 1.3.10.
> >
> > [X] +1: It's not just good, it's good enough!
>
> Tested on Windows 10 (OpenSSL 1.1.1t) x86 & x64.
--
--
---------------------------------------------------------------------------------------------------------------------
Knowing is not enough; we must apply. Willing is not enough; we must do
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Ivan Zhakov <iv...@apache.org>.
On 2023/05/26 10:53:18 Evgeny Kotkov wrote:
> Hi all,
>
> Please find below the proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/serf/
>
> I would like to call a VOTE to release these as Apache Serf 1.3.10.
>
> [X] +1: It's not just good, it's good enough!
Tested on Windows 10 (OpenSSL 1.1.1t) x86 & x64.
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Evgeny Kotkov <ev...@visualsvn.com.INVALID>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> Of note, I did run into the EADDRINUSE issue on the context checks when
> running test_all. I added some debug lines to confirm that's what's going
> on, but it does eventually complete in about 10 minutes. FWIW, at least on
> my Ubuntu install, putting in REUSEADDR as a socket opt seems to be
> fine...so, maybe we don't need to remove it everywhere? But, this
> shouldn't block a release.
I tend to think that enabling SO_REUSEADDR is a hack that we should probably
avoid re-introducing (even for some platforms), because it opens a possibility
of improper reuse/connecting to a wrong server, and can possibly result in
rarely occurring test failures that are hard to diagnose.
On trunk we have a better solution for the EADDRINUSE issue where the test
server just picks the next available port. Ideally, we'd want the same to
happen on the 1.3.x branch as well, but for 1.3.x that would mean rewriting
almost all of the tests, because they use the hardcoded port number.
When I committed r1909311, I considered the option of rewriting the tests, but
preferred to add a retry loop instead — because, as far as I know, the only
issue with the retry loop is that the tests now run longer on some platforms,
whereas having to change all tests in the stable branch seemed to be a quite
destabilizing change.
(In case anyone stumbles across this discussion, more details are available
in the commit message for https://svn.apache.org/r1909311)
Thanks,
Evgeny Kotkov
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
+1 for release.
Confirmed GPG sigs and SHA512 hashes.
Tested on Ubuntu 22.04.2 (has OpenSSL 3). All checks passed.
Of note, I did run into the EADDRINUSE issue on the context checks when
running test_all. I added some debug lines to confirm that's what's going
on, but it does eventually complete in about 10 minutes. FWIW, at least on
my Ubuntu install, putting in REUSEADDR as a socket opt seems to be
fine...so, maybe we don't need to remove it everywhere? But, this
shouldn't block a release.
Thanks! -- justin
On Fri, May 26, 2023 at 6:54 AM Evgeny Kotkov
<ev...@visualsvn.com.invalid> wrote:
> Hi all,
>
> Please find below the proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/serf/
>
> I would like to call a VOTE to release these as Apache Serf 1.3.10.
>
> [ ] +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.
>
> As an additional note, I would like to propose that we keep just the single
> current RM's signature in the .asc files, as this seems to be a common
> practice, and also to avoid the "gpg: WARNING: multiple signatures
> detected"
> warning during verification. In other words, a +1 posted in this email
> thread should suffice.
>
> The changelog for version 1.3.10 is included below:
>
> - Support for OpenSSL 3
> - Fix issue #171: Win32: Running tests fails with "no OPENSSL_Applink"
> error
> - Fix issue #194: Win32: Linking error when building against OpenSSL 1.1+
> - Fix issue #198: OpenSSL BIO control method incorrectly handles
> unknown requests
> - Fix issue #202: SSL tests are not passing with OpenSSL 3
> - Fix error handling when reading the outgoing request body
> - Fix handling of invalid chunk lengths in the dechunk bucket
> - Fix an endless loop in the deflate bucket with truncated input
> - Fix BIO control handlers to support BIO_CTRL_EOF
> - Fix a CRT mismatch issue caused by using certain OpenSSL functions
> - Build changes to support VS2017, VS2019 and VS2022
> - Build changes to support Python 3
>
>
> Thanks,
> Evgeny Kotkov
>
Re: [VOTE] Release Apache Serf 1.3.10
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 26, 2023 at 01:53:18PM +0300, Evgeny Kotkov wrote:
> Hi all,
>
> Please find below the proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/serf/
>
> I would like to call a VOTE to release these as Apache Serf 1.3.10.
>
> [ ] +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.
+1
It is a bit unfortunate that the libressl build fixes did not make it.
But it is not worth holding up the release over, either. I can keep papering
over the issue in the OpenBSD ports tree and hope that the 1.4 series will
eventually ship a fix for this. Build-time checks for features and function
names rather than specific version numbers or project names are a better way
of handling cross-platform portability. It also prevents vendor lock-in (where
in this case the vendor is a widely used open source project that should
have such interests at heart as a matter of principle... go figure).