minfrin commented on code in PR #8:
URL: https://github.com/apache/serf/pull/8#discussion_r2160234074
##
buckets/ssl_buckets.c:
##
@@ -1567,14 +1626,214 @@ static int ssl_need_client_cert(SSL *ssl, X509 **cert,
EVP_PKEY **pkey)
return 1;
}
+#if defined(SERF_HAVE
dsahlberg-apache-org commented on code in PR #6:
URL: https://github.com/apache/serf/pull/6#discussion_r2160236466
##
.github/workflows/windows-cmake.yml:
##
@@ -44,21 +44,29 @@ jobs:
- uses: actions/checkout@v3
+ - name: Prepare Environment (Windows)
+if
dsahlberg-apache-org commented on code in PR #7:
URL: https://github.com/apache/serf/pull/7#discussion_r2160121836
##
buckets/ssl_buckets.c:
##
@@ -890,6 +890,10 @@ validate_server_certificate(int cert_valid, X509_STORE_CTX
*store_ctx)
case X509_V_ERR_UNABLE_TO_GET
On 22. 6. 25 02:11, brainy (via GitHub) wrote:
brainy commented on PR #6:
URL:https://github.com/apache/serf/pull/6#issuecomment-2993831947
> (GitHub merge completely destroyed the branch for some reason, and I
didn't initially noticed that. So commits are a bit messed up. Sorry :-S)
brainy commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993831947
> (GitHub merge completely destroyed the branch for some reason, and I
didn't initially noticed that. So commits are a bit messed up. Sorry :-S)
I propose to close this pull request and go ba
brainy commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993831073
> I think this was discussed on the list. I can't really judge the
implications of one over the other. It was mentioned onlist where @rinrab had
some arguments in favour of moving to Ninja.
>
chemodax commented on code in PR #6:
URL: https://github.com/apache/serf/pull/6#discussion_r2160171234
##
.github/workflows/windows-cmake.yml:
##
@@ -44,21 +44,29 @@ jobs:
- uses: actions/checkout@v3
+ - name: Prepare Environment (Windows)
+if: runner.os
rinrab commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993798759
(GitHub merge completely destroyed the branch for some reason, and I didn't
initially noticed that. So commits are a bit messed up. Sorry :-S)
--
This is an automated message from the Apache Git
rinrab commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993797979
@chemodax The main reason why I decided to use Ninja **Multi-Config** is
because before VC.Net generator was used to build both (debug and release)
versions. So, when using Ninja Multi-Config we be
rinrab commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993620179
@dsahlberg-apache-org, this PR also contains Ninja usage in the github
workflow which wasn't committed yet.
--
This is an automated message from the Apache Git Service.
To respond to the message,
chemodax commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993718011
I would like to suggest use Ninja (not multi-config generator) for Windows
build:
1. It's fast.
2. It's default.
3. This is how vcpkg and other typical consumer will use Serf.
Just
chemodax commented on code in PR #7:
URL: https://github.com/apache/serf/pull/7#discussion_r2160116439
##
serf_bucket_types.h:
##
@@ -583,6 +583,8 @@ serf_bucket_t *serf_bucket_limit_create(
#define SERF_SSL_OCSP_RESPONDER_ERROR 0x0200
#define SERF_SSL_OCSP_RESPONDER
dsahlberg-apache-org commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993636263
I think this was discussed on the list. I can't really judge the
implications of one over the other. It was mentioned onlist where @rinrab had
some arguments in favour of moving to Ni
Den fre 20 juni 2025 kl 08:12 skrev Branko Čibej :
> Hi Bert,
>
> I've been going through the Serf code on trunk, trying to fix compiler
> warnings, and found something that I don't understand and don't want to
> just "fix" and possibly introduce a bug. I'm asking for your help, as
> you're the au
dsahlberg-apache-org commented on PR #7:
URL: https://github.com/apache/serf/pull/7#issuecomment-2993630397
@brainy Are you happy with the new SERF_SSL_SIGNATURE_FAILURE error code?
I intend to commit this in two more batches:
- SERF_SSL_SIGNATURE_FAILURE, basically buckets/ssl_buck
dsahlberg-apache-org commented on PR #6:
URL: https://github.com/apache/serf/pull/6#issuecomment-2993617465
@rinrab, are you happy with r1926240:1926243, ie: should we close this PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to G
brainy commented on code in PR #8:
URL: https://github.com/apache/serf/pull/8#discussion_r2160046553
##
buckets/ssl_buckets.c:
##
@@ -1567,14 +1626,214 @@ static int ssl_need_client_cert(SSL *ssl, X509 **cert,
EVP_PKEY **pkey)
return 1;
}
+#if defined(SERF_HAVE_
Author: dsahlberg
Date: Sat Jun 21 13:29:19 2025
New Revision: 1926623
URL: http://svn.apache.org/viewvc?rev=1926623&view=rev
Log:
Make script compatible with Py3.
* test/certs/create_certs.py
(create_key): decode string when writing to file
(create_pkcs12): write file in binary mode
(creat
dsahlberg-apache-org commented on PR #7:
URL: https://github.com/apache/serf/pull/7#issuecomment-2993586060
I've committed the py3 changes in r1926623.
However, as Brane has already written, it would be good to update it to
python-cryptography. In particular I had problems with crypto.PKC
Author: brane
Date: Sat Jun 21 06:09:56 2025
New Revision: 1926610
URL: http://svn.apache.org/viewvc?rev=1926610&view=rev
Log:
* .github/workflows/linux-old-scons.yml: Add temporary debugging steps.
Modified:
serf/trunk/.github/workflows/linux-old-scons.yml
Modified: serf/trunk/.github/workf
Author: brane
Date: Sat Jun 21 12:20:39 2025
New Revision: 1926622
URL: http://svn.apache.org/viewvc?rev=1926622&view=rev
Log:
Use a newer version of SCons in the linux-old-scons workflow.
We need it to support -isystem in env.ParseConfig() for GSSAPI.
* .github/workflows/linux-old-scons.yml: Use
On 20 Jun 2025, at 21:49, Branko Čibej wrote:
> Misunderstanding here. It's clearly possible to do this without exposing the
> URIs in the public API, and it's what we should do. I agree it's unlikely
> that a user would want to, e.g., request certs from the macOS Keychain
> instead of the Win
Author: dsahlberg
Date: Sat Jun 21 09:31:09 2025
New Revision: 1926615
URL: http://svn.apache.org/viewvc?rev=1926615&view=rev
Log:
Remove inconsistent trailing witespace. No functional change.
* test/certs/create_certs.py
(*): As above
Modified:
serf/trunk/test/certs/create_certs.py
Modif
On 20 Jun 2025, at 20:43, Ivan Zhakov wrote:
> I didn't look at the patch yet, but I have general concern: serf doesn't
> depend on OpenSSL. E.g. it may use Crypto API on Windows in future. So I
> think we should avoid exposing OpenSSL in public serf API. Is it possible
> to abstract URI somehow?
24 matches
Mail list logo
