David Schwartz wrote:
Darryl Miles wrote:
But this flag (while documented to the contrary) does nothing inside
libssl. So yes the documentation says you should set it, prove to me
that OpenSSL behaves in a different way because you set it.
One of the biggest downsides of open source software is that encourages
people to code to what something happens to do rather than what it's
guaranteed to do.
Can I please see your "working" (i.e. white paper) on your conclusion
(or that of someone elses conclusion you are merely relaying here); that
this issue is more dominant when involving "open source" ? My gut says
it doesn't agree with you on that statement.
Sure, such an issue exists but just because things are "open source"
doesn't increase it. Lets call it "code by observation".
A hint to DS: grep the source tree of OpenSSL and follow all the
code-paths determined by this flag to their conclusion.
Software development doesn't work that way. That's how you produce code that
suddenly fails mysteriously when you upgrade an unrelated component. The
first rule of software development is "thou shall not assume that something
that happens a particular way is guaranteed to do so, especially when the
documentation specifically warns that it is not".
But there is no "master grand plan for the future" on implementing this
point. At best there was once was but that plan was then found
unnecessary, or was abandoned.
So this is a call to all active developers on OpenSSL what exactly is
your plan for the future with SSL_ACCEPT_MOVING_WRITE_BUFFER. Can the
Open Source community please have an online document outlining the idea,
the concept and the timescales of your intentions.
Lets give a month to come up with such a plan (or at least pipe up that
more time is needed to produce a plan) before this relic should be
earmarked to removal. Especially in the shadow of OpenSSL version 1.0
The existing documentation isn't very clear, it doesn't sufficiently
cover what this flags means:
* by citing a good example and a bad example with explanation as to
which rule(s) is/are broken
* a detailed statement of rules (when to use and when not to use)
* a detailed explanation of scope (the things this flag can not fix
but users might think it fixes)
Anybody wishing to write up such documentation I can assist which some
unclear situations which I do not think the existing documentation
adequately covers.
But first lets hear the future plan to code something actually needing
it, otherwise I would like to see my
SSL_ACCEPT_MANNED_SPACE_FLIGHT_TO_PLUTO added to OpenSSL please.
Since there is no one in the OpenSSL developer community which is
standing up for this flag (from a specification and coding point of view
with an intention to finish the work relating to it). It should be
removed to make users life easier. This does not mean such a flag can
never go in, but the merits of it can be discussed at a later date (once
a body of code is available to require it).
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
