You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2008/04/14 22:42:54 UTC
veto on addition of ssl, evp code
Per the other thread, the review for this has mostly been ignored. I
have no wish to waste time banging my head against a wall, so I am:
-1 on the addition of the SSL code, r415639 et al, on the basis that:
a) the API is undocumented in basic ways for key functions; e.g. it is
unspecified to what purpose the certs, keys, and digest are passed in
creating a "factory".
b) providing an SSL client implementation without any way to verify that
the server identity matches the presented cert is a security issue.
(CVE names have been allocated for manifestations of this problem in
other software)
c) it is a leaky abstraction; the way errors are handled is by exposing
the OpenSSL native error codes to the caller, which the caller can only
interpret by knowing which SSL toolkit the code is linked against
d) there seems to be no demonstration that the abstraction is even
*possible* to implement on anything other than OpenSSL; the WinSock code
is mostly commented out or stubbed.
e) it has systematic error handling problems, returning '-1' as an
apr_status_t value in many places.
f) systematically breaks APR code style by doing argument validation
g) the OpenSSL implementation plainly does not meet the documented
(copy'n'pasted) API constraints in at least the handling of non-blocking
I/O.
and I am also -1 on the addition of the EVP code, r597209 et al, on the
basis that:
h) the undocumented/unspecified API (e.g. in formats of cert/key files,
naming of ciphers) is another leaky abstraction requiring the caller to
know it using OpenSSL underneath; and hence may as well code to OpenSSL
directly
i) apr_evp_factory_create represents unnecessarily bad API design;
requiring a single entry point for a dual-purpose function which ignores
half its arguments depending on a "purpose" switch.
j) it has unnecessary dependencies on SSL_* interfaces in code
purporting to do purely crypto
k) it makes use of interfaces from unreleased versions of OpenSSL (which
may or may not change before release; who knows) - for one of the two
major modes of operation, no less.
l) again, no demonstration that non-OpenSSL-based implementations are
even possible, if an abstraction is the intent.
---ends---
I hope that is considered sufficient technical justification for the
vetos. Note that most of the points above are not new and have been
posted on this list six or twelve months back.
I know that the veto is a horrible uncivilised blunt instrument. I am
happy to see this code branched off somewhere where those interested in
developing it further can do so.
I am also happy to do the grunt work of reversion if the authors are
still unwilling to resolve these issues and don't want to (or don't have
time to) do that themselves.
Regards,
joe
Re: veto on addition of ssl, evp code
Posted by David Reid <da...@jetnet.co.uk>.
Joe Orton wrote:
> Per the other thread, the review for this has mostly been ignored. I
> have no wish to waste time banging my head against a wall, so I am:
>
> -1 on the addition of the SSL code, r415639 et al, on the basis that:
>
> a) the API is undocumented in basic ways for key functions; e.g. it is
> unspecified to what purpose the certs, keys, and digest are passed in
> creating a "factory".
>
> b) providing an SSL client implementation without any way to verify that
> the server identity matches the presented cert is a security issue.
> (CVE names have been allocated for manifestations of this problem in
> other software)
>
> c) it is a leaky abstraction; the way errors are handled is by exposing
> the OpenSSL native error codes to the caller, which the caller can only
> interpret by knowing which SSL toolkit the code is linked against
>
> d) there seems to be no demonstration that the abstraction is even
> *possible* to implement on anything other than OpenSSL; the WinSock code
> is mostly commented out or stubbed.
>
> e) it has systematic error handling problems, returning '-1' as an
> apr_status_t value in many places.
>
> f) systematically breaks APR code style by doing argument validation
>
> g) the OpenSSL implementation plainly does not meet the documented
> (copy'n'pasted) API constraints in at least the handling of non-blocking
> I/O.
>
> and I am also -1 on the addition of the EVP code, r597209 et al, on the
> basis that:
>
> h) the undocumented/unspecified API (e.g. in formats of cert/key files,
> naming of ciphers) is another leaky abstraction requiring the caller to
> know it using OpenSSL underneath; and hence may as well code to OpenSSL
> directly
>
> i) apr_evp_factory_create represents unnecessarily bad API design;
> requiring a single entry point for a dual-purpose function which ignores
> half its arguments depending on a "purpose" switch.
>
> j) it has unnecessary dependencies on SSL_* interfaces in code
> purporting to do purely crypto
>
> k) it makes use of interfaces from unreleased versions of OpenSSL (which
> may or may not change before release; who knows) - for one of the two
> major modes of operation, no less.
>
> l) again, no demonstration that non-OpenSSL-based implementations are
> even possible, if an abstraction is the intent.
>
> ---ends---
>
> I hope that is considered sufficient technical justification for the
> vetos. Note that most of the points above are not new and have been
> posted on this list six or twelve months back.
>
> I know that the veto is a horrible uncivilised blunt instrument. I am
> happy to see this code branched off somewhere where those interested in
> developing it further can do so.
>
> I am also happy to do the grunt work of reversion if the authors are
> still unwilling to resolve these issues and don't want to (or don't have
> time to) do that themselves.
Joe,
I've repeatedly said I'm happy to have the code removed. I've offered to
move it into a branch.
Do with the code as you will. No objections from me.
david
Re: veto on addition of ssl, evp code
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 05:43 PM 4/14/2008, Graham Leggett wrote:
>If you revert this, you break mod_session_crypto, which in turn
>severely limits the usefulness of mod_session_cookie, which in turns
>limits the usefulness of mod_auth_form, which is turn limits the
>usefulness of httpd's powerful AAA mechanism that has been sadly
>limited to Basic and Digest auth only for the last ten years.
Is there some reason that this code can't be put directly in
mod_session_crypto?
Re: veto on addition of ssl, evp code
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
>
> I am kind of annoyed that a branch was done for 1.3.x before any
> release of 1.3.0. My opinion is that encourages folks to think of
> trunk as a dumping ground, which is fundamentally bad because trunk
> is the basis for collaboration. However, since Bill is the likely RM,
> I assume he has some plan in mind that I haven't considered.
As true as that misunderstanding might be ... we simply had several
features which /are/ progressing, but needed a place to bring the 1.3.0-dev
API to completion. You can love or hate the apr versioning rules, but they
are the rules this project adopted - and rules that consumers came to trust.
I don't think we'd get anywhere near 1.3.0-final if not for that branch.
Re: veto on addition of ssl, evp code
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 15, 2008, at 5:55 AM, Graham Leggett wrote:
> The solution is simple: leave it on trunk, remove it from the
> v1.3.0 branch until the issues are resolved, so that the folks
> wanting to see v1.3.0 released are not prevented from making that
> happen. I don't think anybody would have objected to the suggestion
> to do so.
Actually, trunk is supposed to be what we are all working on together
(in its currently working form). In a CTR model, it is fairly important
that objections to the current trunk be addressed immediately, either in
the form of a correction or a revert, since otherwise a whole bunch
of people sit around waiting for the change to occur before continuing.
If an objection cannot be resolved immediately, then the accepted
mechanism is to revert on trunk and continue work on a separate
feature branch or sandbox (easily done by copying the trunk and
re-applying the revert to a branch of trunk in reverse mode).
That gives anyone working on the problem the ability to resolve
the objections on their own schedule (or abandon them without
harming group progress). Note that this imposes extra work on the
person wanting the change, as opposed to imposing extra work on
everyone else to work around the incomplete trunk.
I am kind of annoyed that a branch was done for 1.3.x before any
release of 1.3.0. My opinion is that encourages folks to think of
trunk as a dumping ground, which is fundamentally bad because trunk
is the basis for collaboration. However, since Bill is the likely RM,
I assume he has some plan in mind that I haven't considered.
....Roy
Re: veto on addition of ssl, evp code
Posted by David Reid <da...@jetnet.co.uk>.
Graham Leggett wrote:
> Joe Orton wrote:
>
>> So again, I guess I presumed back then, and would still now, that
>> these problems were understood and were going to be addressed. But
>> that didn't actually happen; the problems are still there. Again,
>> that is the basis of my veto.
>
> Yep, it is still there, and that is because I have been devoting about
> 10 hours a day every day weekends included (this last weekend excluded
> thank goodness) to the httpd and apr code over the last three weeks, and
> that was still not enough to get everything done.
>
> In that time the session stuff got a major refactoring - again. The
> documentation was written and rewritten, specifically from the point of
> view of somebody who had never seen this stuff before, and this had the
> knock on effect of even more rewritten and refactored code.
>
> Then I started slowly and tentatively committing the code, and rpluem
> did a thorough evaluation, which had to be analysed, acted on and
> committed. Then Roy presented some issues, so that pushed out the work
> for a few days more.
>
> At the same time, two external deadlines were looming, and they could
> not be pushed out any longer, so I have had to devote my attention back
> to those. The apr and httpd job is not done, and I have no intention of
> leaving the job undone until it is truly complete. I would have seen no
> point in even trying to get this stuff introduced if the intention was
> to not do it properly.
>
> I made the conscious decision to do the httpd stuff before the apr stuff
> because the apr stuff builds clean, and the httpd stuff does not. Httpd
> takes priority right now for that reason. I have every intention of
> addressing the apr concerns. I absolutely cannot do so this week.
>
>> I am sorry if I failed to do enough to help explain or discuss the
>> problems last year, and as a result of that the veto seems unduly harsh.
>
> As I said, they are valid concerns, and I have every intention of
> addressing every one. All I ask is some patience: the apr stuff needs a
> lot of work, not the least of which is the Microsoft Crypto
> implementation. There would be little point in going to all this effort
> if the code only ever worked on one platform.
The intention was always to have an MS implementation, but lack of time
held me back. Then the prospect of having access to MSDN meant I delayed
until that was complete (2 weeks ago) so I've not done as much as I
should have. I'll likely have some time to help out on this in the
coming month, but we should figure out where to develop before anything
else.
It should probably be in a seperate module somewhere and probably should
be developed that way, as I've suggested several times. One of the
problems with that approach is we don't have a way of a module adding
abritrary error codes - something that has been discussed a few times
but never resolved :-(
>
> Regards,
> Graham
> --
>
>
> ------------------------------------------------------------------------
>
> !DSPAM:16,48053566124071905617490!
Re: veto on addition of ssl, evp code
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
> So again, I guess I presumed back then, and would still now, that these
> problems were understood and were going to be addressed. But that
> didn't actually happen; the problems are still there. Again, that is
> the basis of my veto.
Yep, it is still there, and that is because I have been devoting about
10 hours a day every day weekends included (this last weekend excluded
thank goodness) to the httpd and apr code over the last three weeks, and
that was still not enough to get everything done.
In that time the session stuff got a major refactoring - again. The
documentation was written and rewritten, specifically from the point of
view of somebody who had never seen this stuff before, and this had the
knock on effect of even more rewritten and refactored code.
Then I started slowly and tentatively committing the code, and rpluem
did a thorough evaluation, which had to be analysed, acted on and
committed. Then Roy presented some issues, so that pushed out the work
for a few days more.
At the same time, two external deadlines were looming, and they could
not be pushed out any longer, so I have had to devote my attention back
to those. The apr and httpd job is not done, and I have no intention of
leaving the job undone until it is truly complete. I would have seen no
point in even trying to get this stuff introduced if the intention was
to not do it properly.
I made the conscious decision to do the httpd stuff before the apr stuff
because the apr stuff builds clean, and the httpd stuff does not. Httpd
takes priority right now for that reason. I have every intention of
addressing the apr concerns. I absolutely cannot do so this week.
> I am sorry if I failed to do enough to help explain or discuss the
> problems last year, and as a result of that the veto seems unduly harsh.
As I said, they are valid concerns, and I have every intention of
addressing every one. All I ask is some patience: the apr stuff needs a
lot of work, not the least of which is the Microsoft Crypto
implementation. There would be little point in going to all this effort
if the code only ever worked on one platform.
Regards,
Graham
--
Re: veto on addition of ssl, evp code
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Apr 15, 2008 at 02:55:54PM +0200, Graham Leggett wrote:
> Justin Erenkrantz wrote:
>
>> No, as Joe said, you ignored prior comments - this isn't the first
>> time that these concerns have been raised.
>
> I did not ignore prior comments, I responded to the comments, and my
> responses were ignored.
Without wanting to get into a he-said-she-said argument, I've looked
through the mail thread again to see if this is a fair claim.
A theme of the responses is effectively to stonewall: "this is a wider
problem in the SSL code." Well, sure, fine, I agree completely. What
do you expect me to say? I am not going to try to convince you to spend
time fixing the problems if you don't feel so inclined; your time, your
choice. But if nobody spends time fixing the code, the problems will
still be there. That is the basis of my veto.
For at least two of the five issues in my veto which concern the EVP
code, those labelled (h) and (i), in fact no further discussion seemed
necessary because you indicated intent to fix the issues in question:
"Again, this is the underlying toolkit's problem. Will document
better."
...
"Again, this was modelled on the existing code, and I wasn't happy
with it either. Will change both the apr_ssl_* and the apr_evp_*
factories to be more specific."
So again, I guess I presumed back then, and would still now, that these
problems were understood and were going to be addressed. But that
didn't actually happen; the problems are still there. Again, that is
the basis of my veto.
I am sorry if I failed to do enough to help explain or discuss the
problems last year, and as a result of that the veto seems unduly harsh.
Regards,
joe
Re: veto on addition of ssl, evp code
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> No, as Joe said, you ignored prior comments - this isn't the first
> time that these concerns have been raised.
I did not ignore prior comments, I responded to the comments, and my
responses were ignored.
As a result of this, I had no clear indication of what further action
was necessary. Was my response sufficient to address Joe's concerns? Was
there a compromise that could have been reached? No way to tell until
Joe had responded, and Joe chose not to do so until suddenly piping up
six months later and stamped on the code.
This is exactly the way this issue should not have been handled.
>> You have raised some valid points which need to be addressed in the current
>> code. Unfortunately you delivered those points with the blunt instrument of
>> the -1, and as a result the SSL part of the code has effectively been
>> withdrawn, and any chance of those issues ever being addressed has been
>> vastly reduced if not eliminated entirely.
>
> If and when you wish to address *all* of the issues, I (and I think
> Joe too; but I can't speak for him) will be happy to see it back on
> trunk.
Joe has vetoed the code on trunk, and took it upon himself to remove the
code entirely. I think Joe has made it pretty clear where he stands on this.
> But, releasing a half-completed API in 1.3 is extreme badness.
Absolutely.
The solution is simple: leave it on trunk, remove it from the v1.3.0
branch until the issues are resolved, so that the folks wanting to see
v1.3.0 released are not prevented from making that happen. I don't think
anybody would have objected to the suggestion to do so.
Regards,
Graham
--
Re: veto on addition of ssl, evp code
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> No, as Joe said, you ignored prior comments - this isn't the first
> time that these concerns have been raised.
[...]
> If and when you wish to address *all* of the issues, I (and I think
> Joe too; but I can't speak for him) will be happy to see it back on
> trunk.
+1 - although interfaces on trunk/ let us flesh out any issues, the
flaws that Joe found (and I respect his and 3 other individuals
judgments over all others when it comes to SSL implementations)
reflect serious design flaws, and with issues of that severity
I agree with Joe's decision to park this on a branch until these
are proven to be well thought out.
Re: veto on addition of ssl, evp code
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 15, 2008, at 8:08 AM, Justin Erenkrantz wrote:
> But, releasing a half-completed API in 1.3 is extreme badness.
> -- justin
>
+1... and causes extreme pain.
Re: veto on addition of ssl, evp code
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Apr 15, 2008 at 1:18 PM, Graham Leggett <mi...@sharp.fm> wrote:
> To quote what Roy put into his sandbox at
> https://svn.apache.org/repos/asf/httpd/sandbox/wakad/README.txt:
>
> "Don't knock over my castle."
That's a sandbox - not something that is intended to be in a release.
Please don't take things out of context. APR has strict compatibility
rules, so if this code were to make it into 1.3, then we can't alter
the API until 2.0.
> Every time you veto something instead of engaging someone in a discussion
> to resolve the issues, you are knocking over that person's sandcastle. And
> every time you do that, you are giving that person one less reason to bother
> code up anything at all.
No, as Joe said, you ignored prior comments - this isn't the first
time that these concerns have been raised.
> You have raised some valid points which need to be addressed in the current
> code. Unfortunately you delivered those points with the blunt instrument of
> the -1, and as a result the SSL part of the code has effectively been
> withdrawn, and any chance of those issues ever being addressed has been
> vastly reduced if not eliminated entirely.
If and when you wish to address *all* of the issues, I (and I think
Joe too; but I can't speak for him) will be happy to see it back on
trunk. But, releasing a half-completed API in 1.3 is extreme badness.
-- justin
Re: veto on addition of ssl, evp code
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
>>> l) again, no demonstration that non-OpenSSL-based implementations are even
>>> possible, if an abstraction is the intent.
>> http://msdn2.microsoft.com/en-us/library/aa380252(VS.85).aspx#csp_data_encryption_functions
>>
>> http://www.gnu.org/software/gnutls/comparison.html
>
> URLs != demonstration.
Of course URLs are a demonstration.
You maintain that non OpenSSL based implementations are not possible,
and you have offered no evidence whatsoever to support this.
I on the other hand put in a significant amount of research into this
before embarking on this effort to make sure that other platforms, most
notably Windows, have the functionality I am looking for, so that the
session stuff, which I was working on at the time, had the widest
possible audience that would work out the box.
I am not a Windows developer, I was hoping that somebody would pick up
on what I was doing and fill in the Windows bits for me. If not, I
planned to borrow a Windows machine and do it myself. I certainly
planned to address this at the end of next week, when I can make some
more time. That has been short circuited of course.
> I'll revert the code, anyway.
To quote what Roy put into his sandbox at
https://svn.apache.org/repos/asf/httpd/sandbox/wakad/README.txt:
"Don't knock over my castle."
Every time you veto something instead of engaging someone in a
discussion to resolve the issues, you are knocking over that person's
sandcastle. And every time you do that, you are giving that person one
less reason to bother code up anything at all.
You have raised some valid points which need to be addressed in the
current code. Unfortunately you delivered those points with the blunt
instrument of the -1, and as a result the SSL part of the code has
effectively been withdrawn, and any chance of those issues ever being
addressed has been vastly reduced if not eliminated entirely.
Regards,
Graham
--
Re: veto on addition of ssl, evp code
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2008 at 11:43:22PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>> h) the undocumented/unspecified API (e.g. in formats of cert/key files,
>> naming of ciphers) is another leaky abstraction requiring the caller to
>> know it using OpenSSL underneath; and hence may as well code to OpenSSL
>> directly
...
> If you can suggest how the interface might be improved, that will help.
Document the API constraints/guarantees on cipher/digest naming and
cert/key file formats in such a way that a consumer of this API can use
it without needing to know what SSL toolkit is used underneath.
>> j) it has unnecessary dependencies on SSL_* interfaces in code purporting
>> to do purely crypto
>
> If they were unnecessary, they wouldn't be there. OpenSSL does not provide
> getters to extract the information needed by the evp code,
This is still wrong; it is simple to manipulate PEM/DER files using the
PEM/ASN.1 interfaces and without an SSL_CTX.
>> k) it makes use of interfaces from unreleased versions of OpenSSL (which
>> may or may not change before release; who knows) - for one of the two
>> major modes of operation, no less.
>
> Quite correct, you obviously read the documentation included that explains
> this and why it is classed as "experimental".
This is an arbitrary distinction; once the code hits APR 1.x it is
subject to the same stability constraints as the rest of the tree.
Basing such code around an API which only exists in the OpenSSL CVS tree
is the very definition of premature.
>> l) again, no demonstration that non-OpenSSL-based implementations are even
>> possible, if an abstraction is the intent.
>
> http://msdn2.microsoft.com/en-us/library/aa380252(VS.85).aspx#csp_data_encryption_functions
>
> http://www.gnu.org/software/gnutls/comparison.html
URLs != demonstration.
...
> A far better solution would be to contribute towards the improvement of
> this code, which would contribute far more to the usefulness of the project
> as a whole.
My whole issue is that the EVP code as implemented does not add value to
this project, and I am yet to see any demonstration that it *can* do so
in a useful way. I would much rather see people code against OpenSSL
EVP directly than use this API.
I'll revert the code, anyway.
joe
Re: veto on addition of ssl, evp code
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
> Per the other thread, the review for this has mostly been ignored. I
> have no wish to waste time banging my head against a wall, so I am:
You raised questions after the code was committed in November 2007, and
then didn't bother to follow up when those questions were answered. Six
months of silence followed with a veto does not fit my definition of
"banging your head against a wall".
To answer the issues yet again, in the hope that this will result in
some kind of resolution:
> and I am also -1 on the addition of the EVP code, r597209 et al, on the
> basis that:
>
> h) the undocumented/unspecified API (e.g. in formats of cert/key files,
> naming of ciphers) is another leaky abstraction requiring the caller to
> know it using OpenSSL underneath; and hence may as well code to OpenSSL
> directly
The reality behind the underlying toolkits is that neither OpenSSL, nor
(not my knowledge when I looked) Microsoft Crypto API provide lists of
what parameters are supported, so you are expecting APR to expose
functionality that doesn't exist.
If such functionality can be obtained from the underlying toolkit, that
can be achieved through the addition of an extra function at a future
date. There is no need to change the current interface for that. This
does not support a veto IMO.
If you can suggest how the interface might be improved, that will help.
> i) apr_evp_factory_create represents unnecessarily bad API design;
> requiring a single entry point for a dual-purpose function which ignores
> half its arguments depending on a "purpose" switch.
It works like the SSL side of the code works, and you're right, it
should probably be changed.
> j) it has unnecessary dependencies on SSL_* interfaces in code
> purporting to do purely crypto
If they were unnecessary, they wouldn't be there. OpenSSL does not
provide getters to extract the information needed by the evp code, and
so some hoops have to be jumped through to get at the information. To
fix this, we must fix OpenSSL.
> k) it makes use of interfaces from unreleased versions of OpenSSL (which
> may or may not change before release; who knows) - for one of the two
> major modes of operation, no less.
Quite correct, you obviously read the documentation included that
explains this and why it is classed as "experimental".
We can anticipate the functionality today, or we can wait until APR3 to
break our API to support it when OpenSSL is ready.
> l) again, no demonstration that non-OpenSSL-based implementations are
> even possible, if an abstraction is the intent.
http://msdn2.microsoft.com/en-us/library/aa380252(VS.85).aspx#csp_data_encryption_functions
http://www.gnu.org/software/gnutls/comparison.html
> I hope that is considered sufficient technical justification for the
> vetos. Note that most of the points above are not new and have been
> posted on this list six or twelve months back.
>
> I know that the veto is a horrible uncivilised blunt instrument. I am
> happy to see this code branched off somewhere where those interested in
> developing it further can do so.
>
> I am also happy to do the grunt work of reversion if the authors are
> still unwilling to resolve these issues and don't want to (or don't have
> time to) do that themselves.
I have just spent the last three weeks full time devoted to bringing to
a close the session functionality for httpd, after developing it part
time for over a year. This has overrun and I need to do some paid work
which is now overdue so that the bills get paid, which means that I do
not have time this week to drop everything and change evp just for you.
If you revert this, you break mod_session_crypto, which in turn severely
limits the usefulness of mod_session_cookie, which in turns limits the
usefulness of mod_auth_form, which is turn limits the usefulness of
httpd's powerful AAA mechanism that has been sadly limited to Basic and
Digest auth only for the last ten years.
A far better solution would be to contribute towards the improvement of
this code, which would contribute far more to the usefulness of the
project as a whole.
Regards,
Graham
--
Re: veto on addition of ssl, evp code
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 14, 2008, at 2:13 PM, Ruediger Pluem wrote:
> On 04/14/2008 10:42 PM, Joe Orton wrote:
>
>> I am also happy to do the grunt work of reversion if the authors
>> are still unwilling to resolve these issues and don't want to (or
>> don't have time to) do that themselves.
>
> Does this mean you revert it on trunk or only on 1.3.x branch? If
> you revert
> it on trunk mod_session_crypto needs to be removed from httpd trunk
> as well
> as it uses apr_evp_factory_create and the other apr ssl stuff.
Revert it on trunk. FTR, I agree with Joe.
....Roy
Re: veto on addition of ssl, evp code
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/14/2008 10:42 PM, Joe Orton wrote:
>
> I am also happy to do the grunt work of reversion if the authors are
> still unwilling to resolve these issues and don't want to (or don't have
> time to) do that themselves.
Does this mean you revert it on trunk or only on 1.3.x branch? If you revert
it on trunk mod_session_crypto needs to be removed from httpd trunk as well
as it uses apr_evp_factory_create and the other apr ssl stuff.
Regards
Rüdiger