Ulf Möller wrote:
>
> > $ gcc --version
> > 2.7.2.3
>
> > cc1: Invalid option `cpu=ultrasparc'
>
> Thanks for pointing that out. Since which version does gcc support ultrasparc?
Since 2.8 I believe. In either case note that those UltraSPARC-specific
assembler modules can be perfectly "compiled"
Thanks for the directions.
I compiled the libs to be PIC. Everything works fine if I write a
standalone openSSL client that connects to an openSSL enabled daemon.
However, if I use the client as an NSAPI module (which is basically a
shared library), the server gives an error
12477:error:140780E
On Tue, May 18, 1999 at 08:13:38AM -0700, Ted Rolle wrote:
> Well, if you're referring to humans or monkeys, PRIMATIVE may be
> appropriate. ;->
:)
mh
>
> On Tue, 18 May 1999, gang cao wrote:
>
> > in asn1 lib , is PRIMATIVE should be PRIMITIVE?
> >
> > __
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> >> release without change if they track all the way to the end. We don't
> >> support distinguishing an arbitrary snapshot of a development version,
> >> though; only the latest. So, if you have support for a feature in 0.
In article <[EMAIL PROTECTED]> you wrote:
>> release without change if they track all the way to the end. We don't
>> support distinguishing an arbitrary snapshot of a development version,
>> though; only the latest. So, if you have support for a feature in 0.9.4,
>> then you test like this:
>>
Ulf Möller wrote:
>
> > release without change if they track all the way to the end. We don't
> > support distinguishing an arbitrary snapshot of a development version,
> > though; only the latest. So, if you have support for a feature in 0.9.4,
> > then you test like this:
> >
> > #if OPENSSL_VE
On Tue, May 18, 1999 at 05:19:01PM +0200, Ulf Möller wrote:
>> #if OPENSSL_VERSION >= 0x00904000
>
> In that case I would just test for the release version number
> OPENSSL_VERSION >= 0x000904100, ignoring that the feature already is
> present in some of the development versions.
>
> But we're
This is *at least* the 5th time I see this same message. What's
happening?
And also, I pretty often see messages twice, even if they're obviously
sent to one address only. What's happening?
I can, on request, take a closer look on my side.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PR
Well, if you're referring to humans or monkeys, PRIMATIVE may be
appropriate. ;->
On Tue, 18 May 1999, gang cao wrote:
> in asn1 lib , is PRIMATIVE should be PRIMITIVE?
>
> __
> OpenSSL Project
> release without change if they track all the way to the end. We don't
> support distinguishing an arbitrary snapshot of a development version,
> though; only the latest. So, if you have support for a feature in 0.9.4,
> then you test like this:
>
> #if OPENSSL_VERSION >= 0x00904000
In that cas
I'm using OpenSSL 0.9.2B and would like to enable/disable session id
caching. Is this possible from the command line, or does the software
need to be tweaked?
Thanks,
Vince
__
OpenSSL Project ht
> $ gcc --version
> 2.7.2.3
> cc1: Invalid option `cpu=ultrasparc'
Thanks for pointing that out. Since which version does gcc support ultrasparc?
__
OpenSSL Project http://www.openssl.org
Develo
Goetz Babin-Ebell wrote:
>
> At 11:35 18.05.99 +0100, you wrote:
> >Richard Levitte - VMS Whacker wrote:
> >> ben> OK, I propose that we follow the Apache version numbering scheme,
> which,
> >> ben> I quote:
> >> ben>
> >> ben> /* Numeric release version identifier: MMNNFFRBB: major minor fix
>
In article <[EMAIL PROTECTED]> you wrote:
> Ulf Möller wrote:
>>
>> > Do we? We don't currently have a policy of incrementing version numbers
>> > during development cycles.
>>
>> We don't have the policy to make incompatible changes to the API either,
>> do we?
>
> Yes, I'm afraid we do.
>
>
babinebell> >Yes, 0 for beta, 1 for release. 2-f could be used for something else,
babinebell> >but I can't think what :-)
babinebell>
babinebell> 2 for next beta,
babinebell> 3 for a interim release,
babinebell> 4 for the betas based on 3
babinebell> ...
No, I assume the version will be upped i
in asn1 lib , is PRIMATIVE should be PRIMITIVE?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Ulf Möller wrote:
>
> > Do we? We don't currently have a policy of incrementing version numbers
> > during development cycles.
>
> We don't have the policy to make incompatible changes to the API either,
> do we?
Yes, I'm afraid we do.
> Using the wrong pointer type is an *error* with g++, for
At 11:35 18.05.99 +0100, you wrote:
>Richard Levitte - VMS Whacker wrote:
>> ben> OK, I propose that we follow the Apache version numbering scheme,
which,
>> ben> I quote:
>> ben>
>> ben> /* Numeric release version identifier: MMNNFFRBB: major minor fix
final
>> ben> beta
>>
>> I assume "final" m
> Do we? We don't currently have a policy of incrementing version numbers
> during development cycles.
We don't have the policy to make incompatible changes to the API either,
do we?
Using the wrong pointer type is an *error* with g++, for example, so we
need a way to detect this.
_
Ulf Möller wrote:
>
> We need to increment the version number to reflect the API change in
> the DES library. I don't know if the beta release is coming soon,
> else I would have done it right now.
Do we? We don't currently have a policy of incrementing version numbers
during development cycles.
ben> > There are some serious problems with md32_common.h that I've run
ben> > into. However, I'll wait 'til the next rsync (in a few minutes)
ben> > to see if it has been resolved already...
ben>
ben> OK, care to say what they are?
It's been resolved. It was that HASH_BLOCK_DATA_ORDER wasn't
Richard Levitte - VMS Whacker wrote:
>
> ben> OK, I propose that we follow the Apache version numbering scheme, which,
> ben> I quote:
> ben>
> ben> /* Numeric release version identifier: MMNNFFRBB: major minor fix final
> ben> beta
>
> I assume "final" means "release"...
Yes, 0 for beta, 1 for
Hi, (hope this is the right thing to do...)
FYI for openssl-SNAP-19990518-0930 (and a few others previous to
this)...
I did a test build on the sun ultra 5 here...
$ uname -a
SunOS helios 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10
$ gcc --version
2.7.2.3
config guesses as...
Operating
In article <00ca01be9b01$7c16e3a0$[EMAIL PROTECTED]> you wrote:
> Hi, how can I convert a certificate from X509*xs structure format to DER =
> format, and put it in a char * string in C, without using a temporary file ?
> Thanks everibody in advance.
First, can you please post in plain ASCII? I
In article <[EMAIL PROTECTED]> you wrote:
> ulf> What is that "tardy" thing in make tar?
>
> It adds the prefix "openssl-${VERSION}/" to all the file names in the
> tar output. I find that brilliant, and much better than the
> cd../rename/tar/rename/cdfoo thingy that was made in SSLeay.
Yes, o
In article <[EMAIL PROTECTED]> you wrote:
> I tried to Cc this to <[EMAIL PROTECTED]>, but it bounced.
> I'll re-try with <[EMAIL PROTECTED]>.
> You don't happen to use sendmail, do you?
We use Sendmail 8.9, but the Email addresses are case-sensitive.
Ral
In article <[EMAIL PROTECTED]> you wrote:
> when revoke a certificate '01.pem' ,and use
> 'openssl ca -gencrl -out crl.pem'
> to generate crl . then 'cat crl.pem >>./demoCA/cacert.pem',
>
> when use 'openssl verify -CApath ./demoCA
> -CAfile ./demoCA/cacert.pem 01.pem' to verify the
> revoked
27 matches
Mail list logo
