On Wed, Nov 08, 2000 at 11:46:49AM -0700, [EMAIL PROTECTED] wrote:
There were disenters. This does not affect me but I recall reading about S390
people who claim the h/w presents an RSA BASF personality.
RSA BSAFE is not the same as RSAREF, and their APIs differ too.
A BSAFE API would be a
Hi there!!
Don't you think that CROATIA could be the right place
for your exposing?!!
We are now the biggest sex amateur site in the country.
Please send us your photos with your BANNER via e mail.You
can find many new friends here.
Our adress is www.zlobecsportamateurs.com
Best regards
So with that in mind, is there a good reason to try and have this
functionality (but working this time!) in the new ASN1 code or should
any existing structure be freed and a new one freshly allocate?
Are refcounts on the ASN1 objects or higher-level? How do you handle
overwrite if the
Dr S N Henson wrote:
Another general ASN1 question.
The revised OpenSSL ASN1 code will eventually have support for I/O based
operations in addition to the current memory based operations which need
to have the entire structure in memory (tricky if its a 1Gb structure on
tape).
Doing
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
Ben Laurie [EMAIL PROTECTED]:
BTW, Bodo mentioned that dup_expand was dupping regardless of whether it
expands - if so, that'll slow it down a lot, I'd guess. Did you fix
that?
Depends on what you mean with "fix". As it is in the repository
I am sure have missed its previous mail but it certainly seems very
interesting. Kindly let me have some background information.
Cheers.
Najam
Ben Laurie wrote:
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets
On Thu, Nov 09, 2000 at 11:46:03AM -0500, Jeffrey Altman wrote:
I need an API in OpenSSL to allow the negotiated cipher to be queried
to determine if it is or is not Anonymous. I don't want to directly
query the contents of the SSL_CIPHER algorithms in my code:
On Fri, Nov 10, 2000 at 11:27:03PM +0100, Richard Levitte - VMS Whacker wrote:
[...]
Constifying just the BN_mod_exp's should be enough for a lot of that.
If necessary, we can still add a constified variant of BN_mul that
copies its arguments or uses a multiplication algorithm that does not
From: Naomaru Itoi [EMAIL PROTECTED]
itoi I have been talking with Markus Friedl
itoi [EMAIL PROTECTED] in the OpenSSH
itoi developers group about possible smartcard integration to
itoi OpenSSH. That is, to store an RSA key pair on a smartcard and
itoi carry out RSA operation there.
That would
%% Rich Salz [EMAIL PROTECTED] writes:
That's not the issue - the issue is that if you declare something const
the compiler can assume it doesn't change over the function call. If it
does, then things can break.
rs No, because "noalias" was removed from the standard.
rs You're
From: Bodo Moeller [EMAIL PROTECTED]
moeller The BN_mod_exp functions can be constified. The worst that
moeller can happen is that they'll have to copy the number that is to
moeller be exponentiated (the BN_CTX can be used for this).
That's a useful solution (copying arguments at that level,
From: Geoff Thorpe [EMAIL PROTECTED]
Hi there,
[snip]
psmith IMHO this is a legitimate reason to cast away const, and that
psmith the "const" notation on the arguments to lhash is useful for
psmith self-documentation purposes, at the least.
Hmm, perhaps you're right. I'm just
%% Ben Laurie [EMAIL PROTECTED] writes:
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
bl The latter.
To me, that's much more ugly than simply casting it.
This is C, not C++, and we do the best we can with
On Fri, Nov 10, 2000 at 11:44:44PM +0100, Richard Levitte - VMS Whacker wrote:
[Description of different locations for different modules deleted.]
In this case, I'd say ENGINE_PATH would probably be the way to go that
is reasonably simple to implement.
I consider this as kind of agreement,
This restriction (or, lack of ability to assume) only takes effect
when stepping across function calls, doesn't it?
And into. Any function that takes a pointer can't be sure it's not
aliased.
/r$
__
OpenSSL Project
This sounds like a problem I've run into before. Remember that a FILE *
structure uses memory malloc'd from a heap, and that Windows DLLs have their
own heaps, distinct from the main app. As such, you cannot set up a pointer
in one space and then use it with malloc/realloc in the other space.
From: Lutz Jaenicke [EMAIL PROTECTED]
Lutz.Jaenicke Please tell me how $ENGINE_PATH is more secure than
Lutz.Jaenicke $SHLIB_PATH?
Lutz.Jaenicke ENGINE_PATH is being explicitely processed by the
Lutz.Jaenicke application (or inside the dso functionality).
Lutz.Jaenicke SHLIB_PATH is processed
Rich Salz wrote:
So with that in mind, is there a good reason to try and have this
functionality (but working this time!) in the new ASN1 code or should
any existing structure be freed and a new one freshly allocate?
Are refcounts on the ASN1 objects or higher-level? How do you
"Paul D. Smith" wrote:
%% Ben Laurie [EMAIL PROTECTED] writes:
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
bl The latter.
To me, that's much more ugly than simply casting it.
This is C, not
[EMAIL PROTECTED] wrote:
/* read in at offset 8, read the EVP_Cipher
* documentation about why */
- i=BIO_read(b-next_bio,(ctx-buf[8]),ENC_BLOCK_SIZE);
+ i=BIO_read(b-next_bio,(ctx-buf[BUF_OFFSET]),ENC_BLOCK_SIZE);
BTW, AFAICS,
20 matches
Mail list logo
