Hi,
I have written a server which receives connections from
SSL clients. I accept SSL connections as well as read the
data from the client in the following function: DoSSLRead.
Upon the arrival of the client connection, the SSL_read()
is called 3 times (2 times for handshake data and once
for
From: Mixmaster [EMAIL PROTECTED]
mixmaster Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a
mixmaster huge security hole. No security conscious program uses
mixmaster them, and IMO that capability should be explicitly disabled
mixmaster in OpenSSL and users should simply be required
On Wed, Nov 08, 2000 at 09:45:24AM +0100, Richard Levitte - VMS Whacker wrote:
From: Mixmaster [EMAIL PROTECTED]
mixmaster Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a
mixmaster huge security hole. No security conscious program uses
mixmaster them, and IMO that capability
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 07, 2000 8:55 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Constification
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C
Richard Levitte - VMS Whacker wrote:
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
Like strstr()...
Just because the C libraries are broken
From: Ben Laurie [EMAIL PROTECTED]
ben I'm starting to think that we should have BN_mul() and BN_sqr() break
ben constness when they need to do a bn_wexpand(). After all, there are
ben flags telling us if the BIGNUM is static or not, and if it isn't, it's
ben been allocated on the heap.
ben
I have successfully installed openssl on Windows
2000. I am now testing programs to generate private and pub keys, write
them to a file, and then using the private key to sign a text file. This
code has been taken from UNIX Solaris OS, where it works fine.
I have tried taking the public
Jon,
make
sure you access the files as binary
i. e.
fopen(filename, "rb") or fopen(filename, "wb");
if you
use fopen()
Robert
-Original Message-From: jon brace
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, November 08,
2000 12:51 PMTo: [EMAIL PROTECTED]Subject: i2d
Richard Levitte - VMS Whacker wrote:
From: Ben Laurie [EMAIL PROTECTED]
ben I'm starting to think that we should have BN_mul() and BN_sqr() break
ben constness when they need to do a bn_wexpand(). After all, there are
ben flags telling us if the BIGNUM is static or not, and if it
From: Ben Laurie [EMAIL PROTECTED]
ben It does mean exactly that. If we want to constify the API, what
ben choice do we have? Also, note that in the problematic sections,
ben there's a check to see that the BIGNUM data isn't flagged as static.
ben
ben It is absolutely unacceptable to take
Richard Levitte - VMS Whacker wrote:
And oh, you may not have noticed, but the unconstification carried to
a couple of other places. One of them is in the ASN.1 macros, but if
I understood Stephen right, the new ASN.1 code he's working on will
take away that problem (Stephen, I'd like to
Dr S N Henson wrote:
Richard Levitte - VMS Whacker wrote:
And oh, you may not have noticed, but the unconstification carried to
a couple of other places. One of them is in the ASN.1 macros, but if
I understood Stephen right, the new ASN.1 code he's working on will
take away that
Richard Levitte - VMS Whacker wrote:
From: Ben Laurie [EMAIL PROTECTED]
ben It does mean exactly that. If we want to constify the API, what
ben choice do we have? Also, note that in the problematic sections,
ben there's a check to see that the BIGNUM data isn't flagged as static.
From: Ben Laurie [EMAIL PROTECTED]
ben This is why I said what we have is really a mutable, but you can't say
ben that in C (its a C++ concept). But the central point is that having
ben "const" in an API is a promise not to modify the parameter - its
ben completely pointless to make that promise
%% Ben Laurie [EMAIL PROTECTED] writes:
Like strstr()...
bl Just because the C libraries are broken doesn't mean we should
bl break ours. In Apache we fix these rather than live with them.
How exactly do you fix them?
--
From: Ben Laurie [EMAIL PROTECTED]
ben Like strstr()...
ben
benbl Just because the C libraries are broken doesn't mean we should
benbl break ours. In Apache we fix these rather than live with them.
ben
ben How exactly do you fix them?
ben
ben By wrapping them with correctly
%% Ben Laurie [EMAIL PROTECTED] writes:
bl By wrapping them with correctly declared functions.
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
I don't think either of these two options is better than deconstifying
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker wrote:
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1,
OK, from what I understand, everyone agrees that the RSAref glue code
can go.
My first step will be to simply remove all references to it, while
still leaving the rsaref/ directory in, if anyone would still be
interested in it (actually, I'm toying with the idea of making it an
engine that one
From: Rich Salz [EMAIL PROTECTED]
rsalz As I see it, you have a couple of choices.
rsalz 1. Leave the old code, as shown in the first fragment, but declared the
rsalz parameters const. You can't do that, because the resultant code is not
rsalz standard-conforming.
rsalz
rsalz 2. Declare the
20 matches
Mail list logo
