In message <[EMAIL PROTECTED]> on Fri, 29 Nov 2002 10:03:08
+0100, Nils Larsch <[EMAIL PROTECTED]> said:
nlarsch> may I ask why you didn't replace the 'memset()' in
nlarsch> BN_clear_free() with the new OPENSSL_cleanse() function ?
Quite simple: the memset()s I felt safe modifying at that point
[EMAIL PROTECTED] wrote:
> levitte 28-Nov-2002 09:04:47
>
> Modified:apps apps.c ca.c dgst.c enc.c s_client.c s_server.c
> s_socket.c
>crypto md32_common.h mem.c
>crypto/asn1 a_sign.c a_verify.c n_pkey.c p8_pkey.c
>
Date sent: Tue, 19 Mar 2002 14:39:00 -0500
From: Vern Staats <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: openssl/ssl kssl.c
Send reply to: [EMAIL PROTECTED]
I just wish the logic worked,
On Tue, Mar 19, 2002 at 06:37:35PM +, Dr S N Henson wrote:
> Jeffrey Altman wrote:
> >
> > To make it very clear, the locations that I'm seeing warnings are:
> > ssl\kssl.c:
> >
> > In print_krb5_data() kdata->length is unsigned
> > In print_krb5_keyblock() keyblk->length is unsigned
> > [..
Jeffrey Altman wrote:
>
> To make it very clear, the locations that I'm seeing warnings are:
>
> ssl\kssl.c:
>
> In print_krb5_data() kdata->length is unsigned
>
> In print_krb5_keyblock() keyblk->length is unsigned
>
> In print_krb5_princ() princ->realm.length and
> princ->realm.data[i].leng
To make it very clear, the locations that I'm seeing warnings are:
ssl\kssl.c:
In print_krb5_data() kdata->length is unsigned
In print_krb5_keyblock() keyblk->length is unsigned
In print_krb5_princ() princ->realm.length and
princ->realm.data[i].length are unsigned.
and then in ssltest.c (n
> Jeffrey Altman wrote:
> >
> > > Update on this. I've now got hold of MIT 1.2.4 sources from:
> > >
> > > http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5
> > >
> > > I tested compiling OpenSSL with KRB options under Linux (RHL 6.2) and it
> > > showed no warnings at all (my option
Jeffrey Altman wrote:
>
> > Update on this. I've now got hold of MIT 1.2.4 sources from:
> >
> > http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5
> >
> > I tested compiling OpenSSL with KRB options under Linux (RHL 6.2) and it
> > showed no warnings at all (my options are to use the
> Update on this. I've now got hold of MIT 1.2.4 sources from:
>
> http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5
>
> I tested compiling OpenSSL with KRB options under Linux (RHL 6.2) and it
> showed no warnings at all (my options are to use the -Wall -pedantic
> -Werrors which w
Jeffrey Altman wrote:
>
> Steve:
>
> Which flavor of Kerberos 5 are you using?
> Which release?
>
> I have a feeling the reasons that you are I are seeing different
> warnings is because the types of the fields in different flavors or
> versions are different.
>
> I'm compiling against MIT 1.2
Date sent: Fri, 15 Mar 2002 9:35:06 EST
From: Jeffrey Altman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Copies to: [EMAIL PROTECTED]
Subject: Re: cvs commit: openssl/ssl kssl.c
Send reply to: [EMAIL PRO
Jeffrey Altman wrote:
>
> Steve:
>
> Which flavor of Kerberos 5 are you using?
> Which release?
>
> I have a feeling the reasons that you are I are seeing different
> warnings is because the types of the fields in different flavors or
> versions are different.
>
> I'm compiling against MIT 1.2
Steve:
Which flavor of Kerberos 5 are you using?
Which release?
I have a feeling the reasons that you are I are seeing different
warnings is because the types of the fields in different flavors or
versions are different.
I'm compiling against MIT 1.2.4 which is the current release.
Some of you
Richard Levitte - VMS Whacker wrote:
>
> From: Jeffrey Altman <[EMAIL PROTECTED]>
>
> jaltman> Just wondering. What are you compiling with that you are seeing
> jaltman> warnings?
> jaltman>
> jaltman> I compile this code without any warnings without these modifications.
>
> On Linux, with the
From: Jeffrey Altman <[EMAIL PROTECTED]>
jaltman> Just wondering. What are you compiling with that you are seeing
jaltman> warnings?
jaltman>
jaltman> I compile this code without any warnings without these modifications.
On Linux, with the target debug-levitte-linux-elf, I got some of those
wa
Jeffrey Altman wrote:
>
> Just wondering. What are you compiling with that you are seeing
> warnings?
>
VC++ 6.0 SP1, Kerberos 1.2.3 headers. I couldn't get the Kerberos 1.2.3
distribution to compile under Windows though. Can 1.2.4 sources/binaries
be downloaded from anywhere outside the US?
Just wondering. What are you compiling with that you are seeing
warnings?
I compile this code without any warnings without these modifications.
> steve 12-Mar-2002 20:37:23
>
> Modified:ssl kssl.c s3_srvr.c
> Log:
> Fix Kerberos warnings with VC++.
>
> Revision Cha
Hey there,
On Sun, 3 Dec 2000, Dr S N Henson wrote:
> I think the DECLARE and IMPLEMENT macros for most things don't have a
> semicolon anyway so it would be an idea to follow that for consistency.
>
> If you really want the semicolon then I suppose you could just include a
> superfluous protot
Geoff Thorpe wrote:
>
> Hey there,
>
> On Sun, 3 Dec 2000 [EMAIL PROTECTED] wrote:
>
> > ; gcc -c -ansi -pedantic a.c
> > a.c:3: warning: ANSI C does not allow extra `;' outside of a function
>
> :-) OK, I'm busted. hehe.
>
> Fair enough, I guess ANSI is as good a reason as any! I'll remove
Hey there,
On Sun, 3 Dec 2000, Ben Laurie wrote:
> > is equivalent to whether you can follow a function's closing brace with a
> > semi-colon.
>
> Which you can't in ANSI C.
Yup, ok. :-)
> > Another option would be using "inline" I guess, but I don't know how
> > effective that is. Feedback w
Hey there,
On Sun, 3 Dec 2000 [EMAIL PROTECTED] wrote:
> ; gcc -c -ansi -pedantic a.c
> a.c:3: warning: ANSI C does not allow extra `;' outside of a function
:-) OK, I'm busted. hehe.
Fair enough, I guess ANSI is as good a reason as any! I'll remove any
other trailing semi-colons in the next b
Geoff Thorpe wrote:
>
> Hi there,
>
> On Sun, 3 Dec 2000, Ben Laurie wrote:
>
> > > -static IMPLEMENT_LHASH_HASH_FN(index_serial_hash,const char **);
> > > -static IMPLEMENT_LHASH_COMP_FN(index_serial_cmp,const char **);
> > > -static IMPLEMENT_LHASH_HASH_FN(index_name_hash,const char **)
>> Couldn't find a way to not get warnings and still have a semicolon, I'm
>> afraid.
>Really? Weird ... is the compiler/OS running punched cards?
>it's hardly a biggee. I'm curious though why it doesn't accept them though
>- the macro expands into a function declaration so the trailing semi-co
Hi there,
On Sun, 3 Dec 2000, Ben Laurie wrote:
> > -static IMPLEMENT_LHASH_HASH_FN(index_serial_hash,const char **);
> > -static IMPLEMENT_LHASH_COMP_FN(index_serial_cmp,const char **);
> > -static IMPLEMENT_LHASH_HASH_FN(index_name_hash,const char **);
> > -static IMPLEMENT_LHASH_COMP_
[EMAIL PROTECTED] wrote:
>
> ben 03-Dec-2000 11:04:23
>
> Modified:apps ca.c openssl.c
>ssl kssl.c
> Log:
> Fix warnings.
>
> Revision ChangesPath
> 1.71 +4 -4 openssl/apps/ca.c
> 1.32 +2 -2 openssl/apps/openssl.c
>
>
From: [EMAIL PROTECTED]
levitte> levitte 16-Nov-2000 22:35:13
levitte>
levitte> Added: ssl kssl.c kssl.h
levitte> Log:
levitte> I've checked again and again. There really is no need to expand a to
levitte> 4 times it's size when bn_sqr_recursive() won't look farther than
26 matches
Mail list logo
