In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 12:49:18 +1000
(EST), Brian Havard [EMAIL PROTECTED] said:
brianh Applied to the 0.9.7 branch as well as HEAD. Thanks.
brianh
brianh Cool, though a new problem has been introduced (not directly related to the
brianh ticket). In
Actually, I found that strcasecmp() is often declared in strings.h,
so it still needs to be included in most places. Therefore, I
applied your original patch.
This ticket is now resolved.
[levitte - Tue Jul 16 09:03:42 2002]:
Quick question: does string.h in Unixware define strcasecmp()?
In message [EMAIL PROTECTED] on Wed, 17 Jul
2002 14:10:58 -0400 (EDT), Geoff Thorpe [EMAIL PROTECTED] said:
geoff 0.9.6* releases are strictly for bug-fixes, so that is out of
geoff the question. 0.9.7 is already in beta-testing so I'd similarly
geoff doubt inclusion of anything new in there -
This most likely yet again the problem with the way ld works on
MacOS X. I'll attach the PROBLEMS file that has a section about
this particular problem and possible solutions.
I hereby consider this ticket resolved.
[jaenicke - Tue Jun 11 13:55:44 2002]:
[[EMAIL PROTECTED] - Tue Jun 4
Has this problem been dealt with yet?
[jaenicke - Tue Jun 18 12:30:24 2002]:
On Mon, Jun 17, 2002 at 07:43:18PM +0200, [EMAIL PROTECTED] via RT
wrote:
redhat linux never upgraded libraries are rpm's glibc-2.1.92-14
and
glibc-devel-2.1.92-14. it's redhat 7.0. I think sysconf is
I've seen no further communications on this subject. Has this issue
been dealt with? Is there a change that we should apply, or shall
we just kill this ticket?
[jaenicke - Tue Jun 25 22:25:56 2002]:
[[EMAIL PROTECTED] - Tue Jun 25 20:51:20 2002]:
Hello friend,
I am working for IBM
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002
11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller I think this is wrong.
moeller
moeller The output file is opened in text mode (not binary), so on systems
moeller where line ends are usually CRLF, the \r\n will result in CR CR LF
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002
11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller I think this is wrong.
moeller
moeller The output file is opened in text mode (not binary), so on systems
moeller where line ends are usually CRLF, the \r\n will result in CR CR LF
Often, the cert/key directory is not used at all; otherwise it should be
easy to use symbolic links to get the desired effect. Thus it should be
possible to do without the '--certdir' patch.
A reason for *not* introducing '--certdir' is that the
'--prefix'/'--openssldir' situation is already a
I've reversed the patch. Bodo is correct, it's not OpenSSL's
responsability to do the various conversions that may be done by the
C run-time library anyway. If there are problems passing the
resulting file to some library that expects the formating to CRLF
line ends in a text file, the
In similar configurations with gcc version 2.95.2, I observe none of
these problems. This suggests that the problems may be due to compiler
bugs in your gcc version; please try gcc 2.95.2 or a different newer
release and report if the problems persist.
This is not a report on an actual problem in OpenSSL, and there has been
no updated to the original request since June 25th; so nothing to do for
us about this at the moment.
__
OpenSSL Project
apps/ca.c has now been changed as suggested; thanks for the patch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Hi all,
I am looking into the shatest.c file since i want to make use of sha-1
message digest.
In this file openssl-0.9.6d/crypto/sha/shatest.c,
141 for (i=0; i1000; i++)
142 SHA_Update(c,buf,1000);
143 SHA_Final(md,c);
For chunks of data we can call
It's in the middle of the afternoon, so I'm resolving this ticket.
I've mailed [EMAIL PROTECTED] about the whole
issue. Whenever I get a good answer, I'll make appropriate changes.
Until then, MacOS X will simply need to be tweaked before one can
compile OpenSSL on it.
[levitte - Wed Jul
On Thu, Jul 18, 2002 at 05:06:20PM +0530, Srinivas Cheruku wrote:
I am looking into the shatest.c file since i want to make use of sha-1
message digest.
In this file openssl-0.9.6d/crypto/sha/shatest.c,
141 for (i=0; i1000; i++)
142 SHA_Update(c,buf,1000);
Thus spake Richard Levitte - VMS Whacker:
In message [EMAIL PROTECTED] on Wed, 17 Jul 2002
13:33:09 -0500, Stephen Sprunk [EMAIL PROTECTED] said:
stephen I'd like to take on moving OpenSSL towards an autoconf
stephen system. First of all, if anyone else is working on this,
stephen please
On Thu, 18 Jul 2002 09:22:49 +0200 (CEST), Richard Levitte - VMS Whacker
wrote:
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 12:49:18 +1000
(EST), Brian Havard [EMAIL PROTECTED] said:
brianh Applied to the 0.9.7 branch as well as HEAD. Thanks.
brianh
brianh Cool, though a new problem has
On Thu, 18 Jul 2002, Bodo Moeller via RT wrote:
Often, the cert/key directory is not used at all; otherwise it should be
Well, at least pine and lynx do. And there will be others...
easy to use symbolic links to get the desired effect. Thus it should be
possible to do without the
But here the SHA_Update is called 1000 times with the same buffer. Is it
right?
It's just a test, so it's like calling SHA_Upodate with a 1000 buffers
that are all the same. It's just to ensure that the hash input is large.
Normally, you'd call SHA_Update once on your data.
/r$
Hi there,
On Thu, 18 Jul 2002, Frederic DONNAT wrote:
I've sent the first release of our engine for 0.9.6x more than 6 months ago.
Later on, I've sent a release for the 0.9.7dev long before the 0.9.7beta versions.
This has been an ongoing problem, for which we apologise. It's the main
reason
On Thu, 18 Jul 2002, Richard Levitte via RT wrote:
I've been away from this ticket for a while, sorry about the delay.
Thanks for getting back to it.
I think I've solved the problem. Since the tests are the biggest
problem with my suggestion, I deviced a mechanism to generate dummy
Yes
Please read the man page for
HMAC(http://www.openssl.org/docs/crypto/hmac.html) and
EVP_sha1 (http://www.openssl.org/docs/crypto/evp.html)
HTH
Edson E. W.
--- Srinivas Cheruku [EMAIL PROTECTED] wrote:
Hi,
Is there an implementation for Keyed Hash functions
like HMAC_SHA1, HMAC_MD5
As far as I know, most programs deliver verbosity to stderr rather
than stdout. One could argue that OpenSSL should have optional
verbosity, and I would agree. I'm not sure if this belongs in the
important range of fixes, however.
If a -verbose flag is to be added, I don't know if I want
Hey Andrew,
Actually, OpenSSL hasn't really been possible to build in
non-monolith mode, as far as I know. Honestly, I don't think
we should go the non-monolith path eaither, if you consider commands
like passwd...
If you tell me why you want to go non-monolith, I might change my
mind. No
[levitte - Thu Jul 18 19:41:51 2002]:
Hey Andrew,
Actually, OpenSSL hasn't really been possible to build in
non-monolith mode, as far as I know.
I meant to write hasn't really been possible to build in non-monolith
mode *in a long time*...
--
Richard Levitte
[EMAIL PROTECTED]
Fixed by letting X509_NAME_oneline() allocate the string. This ticket
is now resolved.
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Those two files are copies of the 0.9.6d [engine] variants. However,
most functionality has been restored back to the pre-engine days (or
rather, the ENGINE framework has become much more transparent).
I'm tempted to just revert those two files back to what they are in
0.9.6d, but I'd like
I just did a tentative addition of history. Please check it and
complete it if needed.
[levitte - Thu Jul 18 11:19:52 2002]:
Has this been dealt with?
[jaenicke - Wed May 29 21:45:30 2002]:
The manual pages about the EVP wrapper do not reflect the
complete
history. Example:
For now, I've added a note in the documentation of RSA_check_key()
that explains that it doesn't work properly for hard keys and why.
We will ponder a little more on this issue.
[[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]:
It wouldn't take much to make this function
compatible, or the
Just attaching a little more state to this ticket ...
[[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]:
The problem is that the use oF engines should be
totaly transparent to the higher API, but apparently
it's not.
I don't call RSA_check_key for a hardware key, I call
it for my CA private
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 18 Jul
2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller I think this is wrong.
moeller
moeller The output file is opened in text mode (not binary), so on systems
moeller where line ends are usually
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 21:07:10 +0100, Ben
Laurie [EMAIL PROTECTED] said:
ben The issue as reported to me was that the body had CRLF, but headers LF
ben only...
ben
ben Seems to me they should be consistent.
I agree. However, what kinds of complications does that
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 18 Jul
2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller I think this is wrong.
moeller
moeller The output file is opened in text mode (not binary), so on systems
moeller where line ends are
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 22:07:57
+0200 (METDST), Ben Laurie via RT [EMAIL PROTECTED] said:
rt The issue as reported to me was that the body had CRLF, but headers LF
rt only...
I just tried to find the places where the body would get a \r
anywhere, and failed. Did
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 22:07:57
+0200 (METDST), Ben Laurie via RT [EMAIL PROTECTED] said:
rt The issue as reported to me was that the body had CRLF, but headers LF
rt only...
I just tried to find the places where the body would get a \r
anywhere, and failed. Did
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 21:07:10 +0100, Ben
Laurie [EMAIL PROTECTED] said:
ben The issue as reported to me was that the body had CRLF, but headers LF
ben only...
ben
ben Seems to me they should be consistent.
I agree. However, what kinds of complications does that
I just realised that the configuration entries for AIX currently
assume a 32-bit environment. The question is how gcc view this, and
especially what size an int is, and also the size of a long. If
either of them is 64 bits, a different configuration entry may be
useful, perhaps called
G'day,
[levitte - Thu Jul 18 20:55:58 2002]:
I just did a tentative addition of history. Please check it and
complete it if needed.
Yup the history stuff looks great, thanks Richard. However I'm not sure
who understands the EVP behavioural changes well enough to
comment/document them
OK, I'm going to close this ticket down now as we have at least solved
the bug, albeit that it was a bit of a short-cut ... we documented the
existing behaviour rather than changing it :-)
If anyone feels strongly that this is not resolved until
RSA_check_key() is modified to use a new
Since this hasn't been reported by anyone else and we haven't heard
from the original requestor in a while, I'm stalling this ticket.
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project
Richard Levitte via RT wrote:
I just realised that the configuration entries for AIX currently
assume a 32-bit environment. The question is how gcc view this, and
especially what size an int is, and also the size of a long. If
either of them is 64 bits, a different configuration entry may
I'm taking a look at this now ... please hold off on reverting back to
0.9.6 (non-engine) versions of the docs until I get my head around it
again (I haven't looked at this stuff for a while) ...
Cheers,
Geoff
--
Geoff Thorpe, RT/openssl.org
Hi,
I am trying to encrypt a session key that I created using DES_KEY_SCHEDULE. I am using
RSA_public_encrypt to encrypt the session key (8 bytes) with the public key using
RSA_PKCS1_OEAP_PADDING. This creates a 64byte encrypted session key. I send this to
the
Server on the windows machine.
Indeed it would be a good idea, especially for
RSA_generate_key, since people have to generate their
key thru an interface that is extern to OpenSSL, then
sign their CSR with that key using OpenSSL, when
everything could be implemented within OpenSSL.
The major benefit would come for, a PKI
45 matches
Mail list logo