[Seems that my first attempt didn't get through - maybe because I was not
yet subscribed? I didn't get a bounce message, however. Anyway, here it's
again.]
It's been almost 2 months since 2.0.53. Think it is time for 2.0.54 yet?
Any chances that the fix I proposed for PR#31302 (suexec doesn't
It's been almost 2 months since 2.0.53. Think it is time for 2.0.54 yet?
Any chances that the fix I proposed for PR#31302 (suexec doesn't execute
commands if they're not in the current dir) finds its way into 2.0.54? I
have followed Ryan Bloom's advice of how to fix the issue properly, trying
At 08:47 PM 6/2/2005, Bill wrote:
One more useful clue, keyword it PatchAvailable once you have
a solution (attached) so that committers seeking low-hanging fruit
can prune some off and close the bugs.
... this is what I was trying to do for PR 31302 (hoping that the fix would
find its way
At 11:23 PM 6/4/2005, William A. Rowe, Jr. wrote:
I'm actually concerned at a higher level that r-filename CANNOT
be relative. Was this the case coming out of mod_include??
r-filename is run up against Directory sections, so apparently
if r-filename is incomplete, mod_include was wrong.
Joe, many thanks for your review and valuable comments, first off! As
the person who contributed to the original SNI patch (authored by Peter
Sylvester/EdelWeb), I'll try to address your questions to the best of my
knowledge/ability.
An updated version of the patch (based on Guenter's latest
Kaspar Brand wrote:
Has a configuration
with an SSLVerifyClient specified in the named vhost been tested?
Yes, and one specific configuration actually made me tweak the code in
the servername callback further: [...]
It turns out that this change was too radical, actually - it prevented
per
Thanks for your review, Rüdiger.
+/* set SSL_CTX (if matched) */
+if (found (ssl = ((SSLConnRec *)myConnConfig(c))-ssl)
+(sc = mySrvConfig(s))) {
+SSL_set_SSL_CTX(ssl, sc-server-ssl_ctx);
+/*
+ * SSL_set_SSL_CTX() only deals with the server cert,
+
If I understand correctly, the current code is relying on
ssl_hook_Access to perform a *second* handshake which will ensure that
the named vhost's access control configuration is enforced, if
necessary?
No, that's probably due to a misunderstanding. In its current form, the
patch will set
While I was testing revocation checking for client certs in an SNI
configuration (Dirk, many thanks for make_sni.sh, btw!), I came across a
flaw in the current implementation when CRL information - i.e.
SSLCARevocationFile/SSLCARevocationPath - is set on a per-vhost basis
(don't know how much
Joe Orton wrote:
I hacked up a quick test based on Dirk's make_sni.sh; this adds
SSLVerifyClient SSLCACertificateFile to the second and third named
vhosts.
And this confirms my original suspicions: I can access those vhosts
without having to present a certificate, i.e. the configured
Joe Orton wrote:
http://svn.apache.org/viewvc?rev=662815view=rev
Changing the dirconf structure fields in-place seems ugly and may even
be thread-unsafe (not sure).
Thanks for pointing this out, I wasn't aware of the danger of doing so.
The same effect can be achieved with the attached,
Joe Orton wrote:
Access control is certainly the most important issue, but e.g. if
SSLCertificateChainFile is not supported properly for the named vhost
that's also a bug. Many configs depend on supplying the intermediate
certs.
True. I'm using such a configuration on my test host since
Joe Orton wrote:
A lot of the mod_ssl code will need to be
very carefully reviewed since some core assumptions are being broken by
supporting SNI. I would go through each of the config directive which
supports vhost context in turn.
So, as promised, I've looked further into it, based on
Coincidentally, I was about to finish the second part of my analysis
when I saw the SNI in which release? message earlier today.
So here it is, part two... Joe, your help in getting SNI into 2.2.10
(possibly) would be very much appreciated. Thanks if you find time for
looking into this.
We're
On Mon, Jun 18, 2008 at 05:27:17PM +0200, I wrote:
So, to support non-SNI clients as far as possible, let me propose the
attached (additional) patch. It corrects the shortcomings of my earlier
attempt (no longer changing dc-nVerify{Client,Depth} in-place), and
includes the changes to support
Ruediger Pluem wrote:
At the moment we have 9 entries in the CHANGES file for 2.2.10 and
there are 5 more proposals in the STATUS file that are missing only
one vote. I think if get these done we also have enough stuff from
pure httpd point of view that warrants a release. WDYT?
May I use
Ian G wrote:
Nick Kew [EMAIL PROTECTED]wrote:
...
It might be worth a --with-SNI configuration option, which
would label it as an experimental feature.
I imagine the use of SNI would need to be configured in
httpd.conf anyway, in the virtual host parts.
Making SNI support configurable
Oden Eriksson wrote:
However, the perl-framework tests barfs at:
t/ssl/v2# Failed test 1 in t/ssl/v2.t at line 16
The root cause for this failure could actually be the same as for a
different issue which was reported to me by private e-mail just
yesterday - in
I wrote:
When I added the second condition to the first if statement, I was
assuming that the default for auth.verify_depth is UNSET as well.
However, it's initialized to 1 (i.e. SSL_CVERIFY_OPTIONAL)
Wrong, of course - this macro
Making SNI support configurable at runtime also seems a more attractive
solution to me - it would basically mean that in ssl_init_ctx(), the SNI
callback is not registered unless it's explicitly configured. I would
suggest using something like
SSLEnableSNI port [port] ...
which would
Ruediger Pluem wrote:
On 02/27/2009 06:16 AM, scte...@apache.org wrote:
Author: sctemme
Date: Fri Feb 27 05:16:18 2009
New Revision: 748396
URL: http://svn.apache.org/viewvc?rev=748396view=rev
Log:
The development trunk of OpenSSL has tightened up the type safety of the
STACK construct
Ruediger Pluem wrote:
Going through the archive I noticed several attachments with the same
basename and and a version string attached. Are these patches
cumulative so that I only need to review the latest one?
sni_sslverifyclient-v5.diff includes all improvements to
Plüm, Rüdiger, VF-Group wrote:
A question regarding your patch:
@@ -427,29 +435,26 @@ int ssl_hook_Access(request_rec *r)
* function and not by OpenSSL internally (and our function is aware of
* both the per-server and per-directory contexts). So we cannot ask
* OpenSSL
Plüm, Rüdiger, VF-Group wrote:
Going through the follow ups the following question remains for me:
Where did you address to adjust the
SSLCARevocation{File,Path} and
SSLOCSP{Enable,DefaultResponder,OverrideResponder}
settings in the case of an non SNI client connecting to the non
Plüm, Rüdiger, VF-Group wrote:
I reviewed your patch and found some issues with it.
Thanks for your review and testing, Rüdiger. I assume you used and
adapted version of the sni_sslverifyclient-v5.diff patch, is that correct?
(All cases below use Name based virtual hosting and a non SNI
Thanks for your time and review - much appreciated.
+n = sslconn-verify_depth;
+sslconn-verify_depth = (dc-nVerifyDepth != UNSET) ?
+dc-nVerifyDepth : sc-server-auth.verify_depth;
+if ((sslconn-verify_depth n) ||
+((n == 0)
Ruediger Pluem wrote:
Looks good. Some minor nitpicks:
Reviewing the code again I don't think we need to have
+#ifndef OPENSSL_NO_TLSEXT
+ !(SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name))
+#endif
this condition at all.
Agreed. I have removed this part from the if
Ruediger Pluem wrote:
the next configuration *can* do security harm:
VirtualHost foo.example.com:443
SSLVerifyClient optional
SSLCACertificateFile foo-clientauth-bundle.pem
/VirtualHost
VirtualHost bar.example.com:443
SSLVerifyClient optional
SSLCACertificateFile
Plüm, Rüdiger, VF-Group wrote:
As I said further down below I see also good and valid use cases for the
combination
SSLVerifyClient optional
and
%{SSL_CLIENT_VERIFY}
And this combination should be safe even if this comes at the price that
some configuration are not possible without SNI. But
Plüm, Rüdiger, VF-Group wrote:
Comparing against anything else but 'SUCCESS' is IMHO a flaw in the
configuration. 'GENEROUS' IMHO only says that some kind of
certificate was sent at all.
That's also my interpretation. Depending on what the exact meaning of
'GENEROUS' should be in our
Mind to sent a version v9 of your patch such that I can review the
complete one again? Thanks for your efforts.
Sorry, please disregard v9 - it makes SSL_VERIFY_CLIENT report GENEROUS
even in cases where it could/should be SUCCESS, actually (if the CA list
stays the same; i.e., v9 doesn't
Plüm, Rüdiger, VF-Group wrote:
Committed v10 with some smaller tweaks as r768499.
Thanks - I'm fine with them!
Also, I'm glad to see that the proposed default for
SSLStrictSNIVHostCheck is off (and hope that it will stay like this :-).
A default of On would imply that users have to explicitly
Ruediger Pluem wrote:
I hope to get the SNI patches summarized in a backportable
way by then to have them included in 2.2.12.
Didn't want to rush things, but since there were no objections to the
recent trunk commits so far - here's an updated backport for 2.2
(including your improvements from
On 18.11.2011 22:21, Stefan Fritsch wrote:
in case any of you also have lots of test failures with libwww-perl 6.0.3,
setting these env vars fixes most of them for me:
PERL_NET_HTTPS_SSL_SOCKET_CLASS=Net::SSL
PERL_LWP_SSL_VERIFY_HOSTNAME=0
No idea why Net::SSL works but
On 23.11.2011 15:06, Joe Orton wrote:
On Wed, Nov 23, 2011 at 08:37:31AM +0100, Kaspar Brand wrote:
There are two approaches to fix 1): a) turn off verify_hostname
where needed (t/ssl/pr12355.t and t/ssl/pr43738.t are doing this
right now) or b) specify the CA cert (generated in t/conf/ca
On 29.11.2011 23:23, Stefan Fritsch wrote:
On Tuesday 29 November 2011, Kaspar Brand wrote:
I have committed the patches in r1207758 (for Apache::Test) and
r1207759 (adjustments to the t/ssl tests).
Nice, works here now. Thanks.
FYI: Torsten pointed out a potential problem with the solution
On 20.11.2011 11:37, Kaspar Brand wrote:
I see. What I don't completely understand yet, however, is the need /
use case for keeping multiple decryption keys around per
SSLSrvConfigRec. When switching to a new key (with a reload/restart),
session tickets encrypted with the previous keys should
On 03.12.2011 00:02, s...@apache.org wrote:
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_log.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_log.c?rev=1209766r1=1209765r2=1209766view=diff
On 05.08.2011 07:41, Kaspar Brand wrote:
On 03.08.2011 19:29, Dr Stephen Henson wrote:
In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
related structures opaque and only allow them to be accessed through
functions.
This is enabled by setting OPENSSL_NO_SSL_INTERN
On 22.12.2011 17:53, Dr Stephen Henson wrote:
I've added a few new controls and one new function which should resolve this,
see last few commits.
I deleted a couple of functions duplicating functionality too.
Let me know if you need further details or it needs fixing.
Thanks for the very
On 23.12.2011 18:13, Dr Stephen Henson wrote:
Your patch to trunk/2.4.x looks fine. You can simplify the clearing of the
extra
chain slightly by just unconditionally calling: [...]
Thanks, patch adapted and committed in r1222917 and r1222920, respectively.
Kaspar
On 08.01.2012 00:15, Michael Felt wrote:
Patches: maybe I'll have time, as it most are from one file.
[...]
mod_include.c, line 721.26: 1506-068 (W) Operation between types const
void* and const char*(*)(struct {...}*,const void*,const char*) is not
allowed.
mod_headers.c, line 898.43:
On 19.01.2012 03:28, Rainer Jung wrote:
OpenSSL should be 1.0.0f and the strange thing is, that the same tests
succeed on Solaris 10 using the same OpenSSL version. Something must be
different between my Linux systems, which all fail, and the Solaris box.
Could be details of the perl
On 19.01.2012 14:49, Rainer Jung wrote:
On 19.01.2012 07:14, Kaspar Brand wrote:
On 19.01.2012 03:28, Rainer Jung wrote:
Additional info: even on the failing systems, CRL checks done for other
tests in the suite do succeed. Example:
[Thu Jan 19 02:33:50.878506 2012] [ssl:debug] [pid 5240
On 02.02.2012 15:13, Dr Stephen Henson wrote:
So perhaps:
int SSL_CTX_set_config_string(SSL_CTX *ctx,
const char *name, const char *value);
Where the values of name can expand over time.
I'm more in favor of this one - i.e., allow configuration through
On 03.02.2012 20:55, Stefan Fritsch wrote:
On Thursday 02 February 2012, Jim Jagielski wrote:
[ ] +1: Bundle apr/apu w/ Apache httpd 2.4.x
[ ] +0: I don't care
[X] -1: Do not bundle apr/apu with Apache httpd 2.4.x
Provided that the --with-included-apr mechanism stays and the docs say
On 04.02.2012 15:27, Dr Stephen Henson wrote:
IMHO to avoid these problems it would be better if mod_ssl could send an
arbitrary number of certificates and keys to OpenSSL and leave it to OpenSSL
to
process them in an appropriate manner.
Would that mean supplying names of key/certificate
On 04.02.2012 20:50, William A. Rowe Jr. wrote:
Kaspar, your vote is very confusing,
Sorry about that. Trying again - this is my vote:
[ ] +1: Bundle apr/apu w/ Apache httpd 2.4.x
[ ] +0: I don't care
[X] -1: Do not bundle apr/apu with Apache httpd 2.4.x
as I agree with Stefan's
On 13.02.2012 14:56, Jim Jagielski wrote:
I'm calling a VOTE on releasing these as Apache httpd 2.4.1 GA.
NOTE: The -deps tarballs are included here *only* to make life
easier for the tester. They will not be, and are not, part
of the official release.
[X] +1: Good to go
[ ] +0: meh
On 23.03.2012 18:11, Rainer Jung wrote:
It should be RewriteRule not RewriteMap in my previous mail. I
simplified the config to a single RewriteRule but forgot to adjst
subject and intro of my mail. The problem remains the same.
Doesn't that ring a bell - namely the one of PR 52774?
Kaspar
On 07.04.2012 00:34, Daniel Ruggeri wrote:
I wanted to bring this up here - seems like a few things are going on
that are confusing to me. I'll try to look into it when time becomes
available, but I thought someone might have an opinion off the bat.
Original Message
On 10.04.2012 12:38, Tom Evans wrote:
On Tue, Apr 10, 2012 at 1:38 AM, Jie Gao j@sydney.edu.au wrote:
Hi All
Would it be possible to expand the scope of ProxyPreserveHost to Location?
Regards,
Jie
I don't understand; ProxyPreserveHost affects the proxying apache
server, and
On 16.04.2012 16:47, Michael Weiser wrote:
So implementation-wise this will most likely have two parts of code:
1. Determining the hostname to put into SNI data depending on
ProxyPreserveHost somewhere in the reverse proxy module.
2. Putting that value into the SNI data in mod_ssl's
On 23.04.2012 17:11, Michael Weiser wrote:
I don't think so: I'm not directing the Proxy to connect to a different
host. I just make it send different SNI data to the configured backend
server and accept a different CN in the server's certificate.
I guess it boils down to the question of what
On 07.05.2012 16:02, Daniel Gruno wrote:
With an impressive 8 x +1 binding votes and no -1's, as well as +2 from
other docs@ readers, I believe we can call this vote passed with flying
colors :).
Apologies for being late with this, but the specifics of the currently
used implementation
On 20.05.2012 14:47, Daniel Gruno wrote:
This will effectively make for two (or three) new votes for adopting
each piece:
- Adopt a privacy policy for the docs and refer to the various tracking
methods used as they get implemented - see the draft at
On 23.05.2012 17:42, jor...@apache.org wrote:
Author: jorton
Date: Wed May 23 15:42:33 2012
New Revision: 1341905
URL: http://svn.apache.org/viewvc?rev=1341905view=rev
Log:
suexec: Add support for logging to syslog as an alternative to a
logfile.
* support/suexec.c (err_output)
On 01.06.2012 21:36, s...@apache.org wrote:
Author: sf
Date: Fri Jun 1 19:36:37 2012
New Revision: 1345319
URL: http://svn.apache.org/viewvc?rev=1345319view=rev
Log:
Add new directive SSLCompression to disable SSL-level compression.
PR: 53219
Submitted by: Björn Jacke bjoern j3e de,
On 06.07.2012 14:41, b...@apache.org wrote:
Author: ben
Date: Fri Jul 6 12:41:10 2012
New Revision: 1358167
URL: http://svn.apache.org/viewvc?rev=1358167view=rev
Log:
Work correctly with a development version of OpenSSL. I suspect
something similar is needed when there are two OpenSSL
On 08.07.2012 22:33, Daniel Gruno wrote:
[ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs
[ ] 0: I don't care
[ ] -1: Don't adopt the system, because
Thanks for enduring your work on this - glad to see that it has become
comments.a.o. in the meantime! I'm in favor
On 08.07.2012 10:30, Kaspar Brand wrote:
On 06.07.2012 14:41, b...@apache.org wrote:
Author: ben
Date: Fri Jul 6 12:41:10 2012
New Revision: 1358167
URL: http://svn.apache.org/viewvc?rev=1358167view=rev
Log:
Work correctly with a development version of OpenSSL. I suspect
something
On 05.08.2012 10:10, Kaspar Brand wrote:
test feedback would be much appreciated (remember to run buildconf after
applying the patch to acinclude.m4, and before calling configure).
The patch attached to the previous message was missing an important
line, unfortunately (sorry to anybody who
On 05.08.2012 14:38, Guenter Knauf wrote:
Am 05.08.2012 10:10, schrieb Kaspar Brand:
1) use --with-ssl-builddir for linking with the static OpenSSL libraries
in that directory (and ignore --with-ssl in this case)
what about splitting into two arguments:
--with-ssl-include=
--with-ssl-lib
On 06.08.2012 22:08, William A. Rowe Jr. wrote:
On 8/5/2012 10:10 PM, Kaspar Brand wrote:
On 05.08.2012 14:38, Guenter Knauf wrote:
Am 05.08.2012 10:10, schrieb Kaspar Brand:
1) use --with-ssl-builddir for linking with the static OpenSSL libraries
in that directory (and ignore --with-ssl
On 06.08.2012 23:36, Rainer Jung wrote:
On 05.08.2012 10:10, Kaspar Brand wrote:
It's a useful enhancement if mod_ssl can be linked with a specific
OpenSSL version in a non-default location, but the current approach has
at least one problem, AFAICT: it will only work if the directory pointed
On 10.08.2012 01:55, William A. Rowe Jr. wrote:
An openssl 'make localinstall' could trivially create the lib, include
trees consisting entirely of symlinks to the origin files in the same
build tree, and create an appropriate openssl.pc file describing the
link steps required to
On 12.8.12 20:01, Ben Laurie wrote:
On Sun, Aug 12, 2012 at 5:23 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
a workaround is to call configure with
suitable {CPP,LD}FLAGS, i.e.
CPPFLAGS=-I${openssl_build_dir}/include \
LDFLAGS=-L${openssl_build_dir} \
./configure ...
(when using
On 17.8.12 13:59, jor...@apache.org wrote:
Author: jorton
Date: Fri Aug 17 11:59:45 2012
New Revision: 1374214
URL: http://svn.apache.org/viewvc?rev=1374214view=rev
Log:
* modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for
missing decrypted private keys, and ensure that
On 18.8.12 21:51, William A. Rowe Jr. wrote:
to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h,
this should also make some of the other #if[n]def
OPENSSL_NO_SSL2
encapsulations unnecessary.
+ [wrowe] agreed the patch was wrong,
On 19.8.12 19:37, Dr Stephen Henson wrote:
On 19/08/2012 18:22, Kaspar Brand wrote:
(ssl.h is not customized by OpenSSL's Configure script, AFAICT you would
have to call openssl version -f and look for any flags set at compile
time.)
I.e., unless mod_ssl is explicitly compiled
On 19.8.12 19:59, Kaspar Brand wrote:
Ok, thanks for clarifying, I stand corrected. opensslconf.h is included
in ssl_private.h via #include openssl/x509_vfy.h, that's why the
current 2.2.x code is working as expected.
Um, for 2.2.x that should read: in ssl_toolkit_compat.h, and it's
actually
On 17.08.2012 10:11, Joe Orton wrote:
On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote:
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands, i.e. in rules.mk we would have
On 27.08.2012 15:42, Michael Felt wrote:
FYI: I get an error message from configure that I do not understand.
+ ./configure
--enable-layout=AIX
--with-apr=/opt/bin/apr-1-config
--with-apr-util=/opt/bin/apu-1-config
On 02.09.2012 14:04, Michael Felt wrote:
The simple part first. AIX has a default install of openssl.
-- however, the name of the library is libssl.a - see attachment for a
filelist of what is included in openssl.base
Ok, this also shows that the AIX package does not include a pkg-config
file
On 23.08.2012 09:22, Kaspar Brand wrote:
On 17.08.2012 10:11, Joe Orton wrote:
On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote:
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands
On 16.09.2012 08:00, Kaspar Brand wrote:
I have committed an improved version in r1385214
Um, make that read r1385216. I left out the acinclude.m4 changes in the
first attempt, unfortunately.
Kaspar
On 18.09.2012 15:05, Joe Orton wrote:
one minor nit/bikeshed-colour-review:
- APR_ADDTO(MOD_SSL_LDADD, [-export-symbols-regex ssl_module])
+ APR_ADDTO(MOD_LDFLAGS, [-export-symbols-regex ssl_module])
this is currently equivalent but keeping _LDADD seems better.
No
On 18.09.2012 17:55, Ben Laurie wrote:
though I still have to actually install openssl somewhere,
which would be irritating if I had to do any serious development. That
said, I could probably figure out how to work around that if I needed
to...
Something like the following will make your
On 03.01.2013 12:20, Joe Orton wrote:
add --static to pkg-config invocations, so that libraries for
static linking are also taken into account (PR 54252 - note that
the additional flags will only appear in modules/ssl/modules.mk
and ab_LDFLAGS, so potential side effects are limited)
This is
On 04.01.2013 22:40, Stefan Fritsch wrote:
On Thursday 03 January 2013, Joe Orton wrote:
Maybe the wording of pkg-config's --static option is somewhat
misleading. It doesn't force linking against the static libs
(i.e. lib{ssl,crypto}.a), but outputs the libraries from
openssl.pc's
On 11.01.2013 23:53, minf...@apache.org wrote:
Author: minfrin
Date: Fri Jan 11 22:53:50 2013
New Revision: 1432322
URL: http://svn.apache.org/viewvc?rev=1432322view=rev
Log:
mod_ssl: Allow the SSLUserName to be used to control the username passed
by the FakeBasicAuth option. PR52616.
On 21.06.2012 18:17, b...@apache.org wrote:
Author: ben
Date: Thu Jun 21 16:17:41 2012
New Revision: 1352596
URL: http://svn.apache.org/viewvc?rev=1352596view=rev
Log:
RFC 5878 support.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/mod_ssl.c
On 10.04.2013 02:49, Lam, Eugene wrote:
Was Re: SSLProxyCheckPeerCN / ProxyPreserveHost issue
So, what do folks think about adding this directive to use the
connection hostname for SNI and the SSLProxyCheckPeerCN feature?
Would such a directive be beneficial? It seems a number of users who
On 05.07.2013 21:25, rj...@apache.org wrote:
Author: rjung
Date: Fri Jul 5 19:25:28 2013
New Revision: 1500108
URL: http://svn.apache.org/r1500108
Log:
mod_ssl: Fix SNI for backend when compiled against
OpenSSL without support for SSLv2.
PR 55194.
Followup to r1497466. Does not
On 10.07.2013 07:53, William A. Rowe Jr. wrote:
Color me confused. Where SSLv2 alone is dropped from the stock OpenSSL
build, 2.2.25 would not compile. The www.a.o/dist/httpd/Announcement
file calls out this patch as a workaround, which I will publish once
I have sorted why the binary win32
On 10.07.2013 10:32, William A. Rowe Jr. wrote:
If you frame this as a fast vote for adoption, and correct the text
in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
as well as the .html version, I'll post that in my morning (which is
still stuck on PDT from my travels).
On 10.07.2013 10:32, William A. Rowe Jr. wrote:
If you frame this as a fast vote for adoption, and correct the text
in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
as well as the .html version, I'll post that in my morning (which is
still stuck on PDT from my travels).
On 23.09.2013 11:17, Joe Orton wrote:
On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote:
Feedback on this approach is again very welcome. Increasing the minimum
required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern,
IMO, as 0.9.7 is no longer maintained, and 0.9.8a
Thanks Joe and Rüdiger for your feedback. I'm going to finish and commit
part1 of the patch next (which seems uncontroversial), and wait a few
more days for opinions re: OpenSSL 0.9.8a, see also the separate thread.
Kaspar
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways, is this something Apache is interested
On 25.09.2013 09:42, Plüm, Rüdiger, Vodafone Group wrote:
IMHO 0.9.8 seems reasonable for trunk and 2.4.
More formal question: Can we do this for 2.4 without breaking any promise?
Sorry for my somewhat naive question, but I guess you need to explain
more specifically (at least to me) what
On 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm not sure how you'd do that with
SSLOpenSSLConfCmd?
It could probably be
On 27.09.2013 20:58, Trevor Perrin wrote:
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile.
If we're adding specific
On 28.09.2013 18:34, Dr Stephen Henson wrote:
How about something like:
int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
which can return things like...
SSL_CONF_TYPE_INVALID:unrecognised name.
SSL_CONF_TYPE_FILE: file name.
SSL_CONF_TYPE_DIR:directory name.
On 29.09.2013 19:48, Hanno Böck wrote:
What needs to happen so this can be backported to 2.4?
Testing patches and reporting on its results e.g. (as previously
solicited in this thread). I have put a backport of the relevant trunk
commits under
On 01.10.2013 12:15, Dr Stephen Henson wrote:
That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl
IMHO you would need a new directive as there's no support for per-certificate
SSL_CONF commands: it wasn't intended to be used like that in its current
form.
This
On 09.10.2013 15:52, Dr Stephen Henson wrote:
It's tempting to just add a directive but after some thought I think expanding
Apache SSL_CONF handling is the way to go. This would add some future proofing
so we don't have to go through this all again in future.
Yes, please. Let's not perpetuate
On 13.10.2013 00:43, Trevor Perrin wrote:
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
I *think* you then have to delve into ssl_pphrase_Handle() [note the comment
on
the way in] and somehow link the ServerInfo index with something you can use
to
recognise it later. The algorithm
On 11.10.2013 13:53, Dr Stephen Henson wrote:
IMHO though there needs to be a way to be able to tie a directive to a
certificate in mod_ssl anyway though. I'm surprised no one has needed to do
that
before.
I'm not sure we really need this for mod_ssl, as configuring more than
one cert per
On 14.10.13 10:51, Rob Stradling wrote:
Kaspar, I don't think data from 2010 (or even data from today) should be
assumed to be a reliable indicator of future use of non-RSA certs on
public sites.
Past performance is not indicative of future performance, as they use
to say in other
1 - 100 of 308 matches
Mail list logo
