OpenSSL Project wrote:
>
> OpenSSL STATUS Last modified at
> __ $Date: 1999/01/21 13:01:20 $
>
> DEVELOPMENT STATE
>
> o OpenSSL 0.9.2: Under development.
> o OpenSSL 0.9.1c: Released on December 23th, 1998
>
>
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
>
> >> o Ben is folding in his patches
>
> > I finished that some time ago.
>
> >>2. The massive symlinking of Makefile.ssl -> Makefile:
> >> First the `make -f Makefile.ssl links' command is nasty,
Richard Levitte - VMS Whacker wrote:
> There's one little problem with that, as far as I've been told by
> folks in the states, and it's that RSAref doesn't have anything
> corresponding to RSA_NO_PADDING, making it difficult to use when you
> don't want any padding (this is the case, apparently,
Mark J Cox wrote:
>
> In going through our internal code I came across some changes that we
> should look at putting into OpenSSL. I've attached a large DIFF against
> the current CVS tree (all changes in the /ssl/ directory).
Is there likely to be much more of this? Coz the longer its left the
Mark J Cox wrote:
>
> > Is there likely to be much more of this? Coz the longer its left the
> > harder it gets to incorporate...
>
> Yes, there is some more of this; but it is intermingled with C2Net
> proprietary stuff that I need to extract it from.
I'm curious to know what sort of thing is
Mark J Cox wrote:
>
> I'm going to delay applying this patch; after applying some connections
> fail:
>
> try openssl -connect www.trustcenter.de:443 [fails]
> try openssl -connect www.trustcenter.de:443 -no_tls1 [passes]
Hmmm ... do we know what they run? Could it be an old version of SSLeay
[EMAIL PROTECTED] wrote:
>
> int func_name _P(whatever);
>
> I'd rather see you give up on non-ANSI platforms and always
> include a prototype.
I'd agree with that. The clincher is whether leaving out the _P makes it
difficult to deal with the stuff Steve mentioned, though.
Cheers,
Be
Ulf Möller wrote:
>
> When libcrypto.a is deleted and then re-made, the Makefiles only put
> those files into the new library which had to be newly built. A better
> way would be to create an .a file in each subdirectory and create a
> new libcrypto.a out of them whenever necessary. It will proba
Josh MacDonald wrote:
>
> To solve your Makefile problems, I think you should all realize that
> the GNU autoconf solution, along with automake and libtool, have
> improved dramatically in the last couple of years. With libtool,
> your shared library problems are solved completely, with no effor
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
>
> > The file crypto/rsa/rsa_enc.c in OpenSSL is obsolete.
>
> You're right. It's now removed. Thanks for the hint.
Yeah, I think it is time we started getting rid of the flotsam...
Cheers,
Ben.
--
http://www.apache-s
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
> >>
> >> In article <[EMAIL PROTECTED]> you wrote:
> >>
> >> > The file crypto/rsa/rsa_enc.c in OpenSSL is obsolete.
> >>
> >> You're right. It's now removed. Thanks for the hint.
>
> > Yeah,
Anonymous wrote:
>
> Jeffrey Altman <[EMAIL PROTECTED]> said:
> > These changes make it easier to configure OpenSSL on Windows.
> >
> > crypto/x509/x509_def.c:
> > 67c68,71
> > ...
>
> Jeff has stated on the mailing list that he's a U.S. citizen.
> What happens now? The changes have been submit
Dr Stephen Henson wrote:
>
> Erwann ABALEA wrote:
> >
> >
> > Here they are. You'll find 2 SET root CA certificates, I don't exactly
> > know which one is really used by the SET world.
> >
>
> That certificate also contains a PKIX extension that I wanted to support
> at some point but I didn't h
OK, I stuffed things up slightly with that!
I'm working on a fix...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less comp
Roland Mechler wrote:
>
> I've had zero response on this. Isn't anyone interested that OpenSSL
> implements the protocol incorrectly?
I'm interested, but I'm still waiting for Mark - he was looking into
weird behaviour with the patch, which I strongly suspect was the same
problem. But perhaps we
Ulf Möller wrote:
> diff -u orig/rsa_eay.c ./rsa_eay.c
> --- orig/rsa_eay.c Fri Feb 5 22:08:26 1999
> +++ ./rsa_eay.c Sat Feb 6 15:06:39 1999
> @@ -130,6 +130,9 @@
> case RSA_PKCS1_PADDING:
> i=RSA_padding_add_PKCS1_type_2(buf,num,from,flen);
> break;
Ulf Möller wrote:
>
> > Shouldn't this also get added to private_encrypt?
>
> PKCS #1 doesn't define an OAEP signature mode yet. You can't
> simply use the same function for signing.
OK.
> The test vectors are from
> http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-1.html
>
> Did you intention
Anonymous wrote:
>
> Having been bitten yet again by the problem where I delete libssl.a
> and do a make and existing up-to-date .o's don't get added to the
> library, and not being able to build shared libs at all, I'm looking
> for a good solution...
Patient: Doctor, it hurts when I do this!
D
er
> > + Suites For TLS", draft-ietf-tls-56-bit-ciphersuites-00.txt.
> > + [Ben Laurie]
>
> Where did you find this draft? It's not in www.ietf.org/internet-drafts/.
It was posted to the TLS WG. No doubt it will appear in the usual places
in due course. I im
Ralf S. Engelschall wrote:
>
> Was this file not committed?
>
> making apps...
> making test...
> make: don't know how to make rsa_oaep_test.o. Stop
> *** Error code 1
make links
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of peop
Ralf S. Engelschall wrote:
>
> I've noticed that the new TLSv1 ciphers are not identified correctly by
> SSL_CIPHER_description() and this way they are also identified as "SSLv3"
> ciphers at the "openssl ciphers" command. The reason is because SSL_TLSV1 is
> currently defined to just the value o
Lutz Behnke wrote:
>
> Hi there,
>
> I have asked this before, but why are all the function headers writen
> in the old K&R style? is that for compatibility with some compiler?
>
> It is not compatible with lxr and AFAICT this is doe to the non-ansi
> headers. I will asume that there are other
Ralf S. Engelschall wrote:
> In short, this (the s_server approach) works:
>
> ctx = SSL_CTX_new();
> SSL_CTX_set_tmp_rsa_callback(ctx, ...);
> SSL_CTX_use_certificate(ctx, ...);
> ssl = SSL_new();
> /* now ssl->cert contains the callbacks for the RSA temp key */
>
> while th
Clifford Heath wrote:
> Anyhow we haven't complied as yet - I prefer Eric's one to X9.17 although
> I did patch it to use SHA-1 instead of MD5 - but I thought you should
> consider making a pluggable interface for the PRNG when you put Peter
> Gutmann's one in.
Randomness already is pluggable.
C
Richard Levitte - VMS Whacker wrote:
>
> This change is against the latest rsync of the main cvs tree.
Parts of this patch look rather garbled...
Cheers,
Ben.
>
> Index: CHANGES
> RCS file: /src/packages/openssl/repository//openssl/CHANGES,v
> retrieving revision 1.94
> diff -u -r1.94 CHANGE
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
> >> In short, this (the s_server approach) works:
> >>
> >> ctx = SSL_CTX_new();
> >> SSL_CTX_set_tmp_rsa_callback(ctx, ...);
> >> SSL_CTX_use_certificate(ctx, ...);
> >> ssl =
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
> >> In article <[EMAIL PROTECTED]> you wrote:
> >> > Ralf S. Engelschall wrote:
> >> >> In short, this (the s_server approach) works:
> >> >>
> >> >> ctx = SSL_CTX_new();
> >> >> SSL_C
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
> >>
> >> I've noticed that the new TLSv1 ciphers are not identified correctly by
> >> SSL_CIPHER_description() and this way they are also identified as "SSLv3"
> >> ciphers at the "openssl cip
Ralf S. Engelschall wrote:
> What makes you thinking that the settings are blown away by
> SSL_use_certificate and friends? These functions already have checks like ``if
> ((ssl->cert == NULL) || (ssl->cert == ssl->ctx->default_cert))'' which
> prevents them from blowing away the settings, Ben.
S
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
> >> What makes you thinking that the settings are blown away by
> >> SSL_use_certificate and friends? These functions already have checks like ``if
> >> ((ssl->cert == NULL) || (ssl->cert == s
Anonymous wrote:
>
> The core group is doing a great job of fixing things and adding new features,
> and I'm amazed how responsive you are to bug reports.
>
> But I'd like to respectfully request that you run 'make test' before you
> check code into CVS, to make sure it didn't break anything. Y
[EMAIL PROTECTED] wrote:
>
> In my mind, the primary benefit of DEF is that it lets you
> specify the symbol order (and export list) so that you can
> preserve binary compatibility across releases. I don't think
> this need by an OpenSSL goal, so I would vote to remove them.
I was going to say
Hmmm ... seem to have filed away the original email, but I just noticed
something...
> Dr Stephen Henson wrote:
> > An alternative which should (hopefully) solve this problem once and for
> > all is to junk the DEF files and generator completely. In my PKCS#12
> > stuff I use the EXTERN macro for
Josh MacDonald wrote:
> The system will use authentication only, built upon the openssl library,
> which is available from outside the U.S. Though SSL contains support for
> encryption, it will be disabled by selecting a NULL encryption cipher
> (which uses only a MAC, no confidentiality). It is
Lennart Bong wrote:
>
> Hi,
>
> Just joined this list today after a nice soul
> at [EMAIL PROTECTED] told me that
> list was dead, heh. I am glad that SSleay lives
> on at OpenSSL since eay joining RSA raised
> some questions on the matter.
>
> Anyway I am in the process to port SSLeay-090b
> t
John Saylor wrote:
>
> Hi
>
> I've got it installed and working pretty well, except for one little
> thing [or else why would I be writing this email?]. I can generate
> certs and set up apache for SSL, but when I try and connect from
> netscape using a browser that has downloaded the CA cert I
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Josh MacDonald wrote:
>
> >> The system will use authentication only, built upon the openssl library,
> >> which is available from outside the U.S. Though SSL contains support for
> >> encryption, it will be disabled b
Josh MacDonald wrote:
> If your question is why PRCS, the answer is because there are numerous
> fundamental errors in the design of CVS that needed correction. There
> is a complete description in ftp://ftp.xcf.berkeley.edu/pub/prcs/scm98.ps.
> The new client/server version also features multipl
[EMAIL PROTECTED] wrote:
>
> Is there interest in making the library "const correct"?
Yes.
> I know this
> first requires ANSI C use. Would the core team accept patches that
> all the niggly little const's added?
I certainly will, and I've been doing them as I go along, too.
Cheers,
Ben.
--
Simon Middleton wrote:
>
> On Thu 04 Mar, Dr Stephen Henson wrote:
> > > #3 Possible lack of syslog. The syslog BIO module 'bss_log.c'
> > > wants syslog but the OS may not have that functionality.
> > > Not sure how openssl group want to handle stuff like this
> > > so I have no
Steve Pierce wrote:
>
> -REPLY SEPARATOR--
> On Thu Mar 4 23:23:08 1999, Josh MacDonald wrote:
> >
> > The header file `pem2.h' is not installed by the 19990304 snapshot.
> >
> You need to create links in ./include to pem2.h and x509v3.h. Do this
> f
Josh MacDonald wrote:
>
> In order to use a null encryption cipher I have to supply a special
> CPP flag (SSL_ALLOW_ENULL) when I *compile* it. This makes it difficult
> to write an application which uses NULL encryption, and there is no way
> for the programmer to re-enable NULL filters. If yo
I need access to an Alpha - anyone got one?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- In
Dr Stephen Henson wrote:
> CJ Holmes wrote:
> This is supported already if you don't mind converting them to a form
> OpenSSL understands.
>
> Firstly you have to pull the certificate chains apart into their
> separate certificates. E.g.
>
> openssl pkcs7 -in file.pem -print_certs -out certs.pem
Hannes Reinecke wrote:
>
> Ben Laurie wrote:
> >
> > I need access to an Alpha - anyone got one?
> >
> To quote from a famous TV series:
> 'In which sense ?'
>
> I have a really nice one at home (21164pc, 533MHz, 512MB), which
> presumably d
Richard Levitte - VMS Whacker wrote:
>
> There are a bunch of places where I see unsigned char and char being
> mixed with each other, making more pedantic ANSI-C compilers (like DEC
> C) spew warnings all over the place.
>
> I'm not really sure how this should be handled. For now, I turn char
Ralf S. Engelschall wrote:
>
> I've tested it with gcc on dev.openssl.org (a Solaris 2.6 box)
> and we've two problems:
>
> First GCC discovered some type inconsitencies related to the ctype functions
> isxxx() which expect an int as the argument per definition/prototype while we
> usually pass
Theodore Hope wrote:
> Global symbol "x86_gc_des" requires explicit package name at
> ./Configure line 160.
> Execution of ./Configure aborted due to compilation errors.
>
> That's as far as I can get for now. Tell me what else I should try.
That should be x86_gcc_des...
Cheers,
Ben.
--
ht
Clifford Heath wrote:
>
> > No, no - rid the world of evil casts!
> > Go with what's right everywhere, surely?
>
> That's difficult when system library calls are often variously and erroneously
> prototyped. The alternative is wrappers "my_select(...)" or evil casts on
> those function calls on
Richard Levitte - VMS Whacker wrote:
> jmacd> Overall, I think it is safer to use an unsigned character
> jmacd> representation, and use casts to (char*) when neccesary.
>
> Scream, Ben, scream :-).
On the Internet, nobody can hear you scream...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.h
[EMAIL PROTECTED] wrote:
>
> Aix 4.2 / gcc (openssl-SNAP-19990309-0930)
> fails in the make test script as others
> have reported for other platforms.
I've just fixed this. Grab the next snapshot.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are
Anonymous wrote:
>
> "Ralf S. Engelschall" <[EMAIL PROTECTED]> said:
> > PS: But we've one more problem on big endian machines as it looks:
>
> FWIW the latest stuff out of CVS now pass everything in 'make test'
> for me on solaris-sparc-sc4. Maybe Ralf's failure is related to
> his using gcc/g
[EMAIL PROTECTED] wrote:
>
> >Another solution (and I just checked this with a friend >who knows the C
> >standards pretty damn well) could be to use `void *' >for any argument
> >that is supposed to hold binary (non-text) data.
>
> Get another friend. :)
>
> void* is best used to indicate "can
Is, in fact, a red herring. The problem is that the certs are not
linked, coz openssl (the app) wasn't available when the links were made.
I'm referring to the SSL test failing, rather than the DES quad
checksum.
I'm going to commit a fix later. Right now I have to cook...
Cheers,
Ben.
--
htt
Stefan Pedersen wrote:
>
> Greetings.
>
> I've compiled OpenSSL SNAP 990309-2130 yesterday
> on Linux-2.2.1 with pgcc (egcs-1.1.1 with pentium opt.)
> Build and install works but I noticed that one
> of the tests fails with a certificate failure. I didn't
> have time to investigate any further t
Ulrich Kroener wrote:
> Ben Laurie, it's your turn...
We don't support non-ANSI compilers.
There! That was easy. :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the
Anonymous wrote:
>
> When configured for solaris-sparc-sc4 with BN_ASM=asm/sparc.s the
> build fails. From make:
> > cc -o openssl -DMONOLITH -I../include -xO5 -Xa -DB_ENDIAN openssl.o
> >verify.o asn1pars.o req.o dgst.o dh.o enc.o gendh.o errstr.o ca.o
> >pkcs7.o crl2p7.o crl.o rsa.o ds
Stefan Pedersen wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> wrote:
>
> > Stefan Pedersen wrote:
> > >
> > > Greetings.
> > >
> > > I've compiled OpenSSL SNAP 990309-2130 yesterday
> > > on Linux-2.2.1 with pgcc (e
Dr Stephen Henson wrote:
>
> Ben Laurie wrote:
> >
> > Ulrich Kroener wrote:
> > > Ben Laurie, it's your turn...
> >
> > We don't support non-ANSI compilers.
> >
> > There! That was easy. :-)
> >
>
> I'd better und
Clifford Heath wrote:
>
> > For const, the simplest possible way, ie by #defining it
> > to the empty string.
>
> That doesn't work on systems that use mangled names in the C libraries.
Huh? Why not? And which systems mangle C names?
> Removing const from appearing in system pr
Georg Gollmann wrote:
>
> Hello,
>
> here are my failed attempts to build openssl-SNAP-19990310-0930 on HP-UX 10.20.
>
> >Then at least run the following procedure:
> >
> > $ cd openssl
> > $ sh config
>
> $ sh config
> sh: config: Execute permission denied.
>
> Setting the Execute permission
Holger Reif wrote:
>
> Ben Laurie schrieb:
> >
> > Bodo Moeller wrote:
> > >
> > > How are things in Apache-SSL with respect to the potential problem
> > > discussed below?
> >
> > I don't believe it is necessary to take any action
[EMAIL PROTECTED] wrote:
>
> Dear Sirs:
>
> Here is a bug report for tarball openssl-SNAP-19990312-1530.tar.gz:
>
> sh config doesn't work if no 'cc' on system
> The makefiles in lower directories still say CC=cc.
I fixed this quite recently. Can you try the latest tarball?
Cheers,
Ben.
--
Matthias Loepfe wrote:
>
> Hi
>
> I just realized that SSLeay-0.9.0 and OpenSSL-0.9.2 are not binary compatible
> at all (I'm using shared libs). It seems that at least some structures have
> changed in a incompatible way.
>
> What is the policy (if there is one at all) for the future regarding
Ulf Möller wrote:
>
> Please don't forget the enc_read.c bug fix.
This appears to have already been fixed.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be
Ulf Möller wrote:
>
> I know that the macro makes packaging easier, but it is a drawback
> that there no longer is a version identifier in the source files.
> Having an identifier is useful especially when parts of the library
> are used separately (like in the FreeBSD libmd, for example).
Huh?
Ulf Möller wrote:
>
> > Huh? You mean if the file is copied? If so, since only some of the files
> > had version numbers in them, the argument is rather weak.
>
> I mean sub-libraries that provide independent functionality, such as
> the SHA, blowfish or DES libraries.
But those still get the v
Chad C. Mulligan wrote:
> If anyone is interested, I'll post a description of the algorithm and my source code
> and test program so you can all play with it. If you like it, you can stick it in
> OpenSSL to give people a choice of methods.
Yeah, I'm interested.
Cheers,
Ben.
--
http://www.apac
Hannes Reinecke wrote:
>
> Hi all,
>
> here is a patch for adding bn_div_words to asm/alpha.s. It got lost
> somehow, but without the assembler version won't compile.
>
> I'm not entirely familiar with the internal working of openssl, but to
> my untrained eye bn_asm.c:bn_div_words and bn_mulw.
Bodo Moeller wrote:
>
> On Mon, Mar 29, 1999 at 05:20:36PM +0200, Bodo Moeller wrote:
>
> > What I don't understand though is the redifinition of BN_ASM in
> > openssl-0.9.2b/crypto/bn/Makefile: [...]
> > The real definition is in openssl-0.9.2b/Makefile.ssl: [...]
> > What's this redefinition a
Ulf Moeller wrote:
>
> A switch to x86unix.pl to optionally generate 80386 code.
Cool ... but how does the flag get in there in the first place?
Presumably Configure needs modifying?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of p
Ulf Moeller wrote:
>
> > Actually, this is all a bit strange - since x86asm.pl is included, but
> > you are grabbing the 386 flag from the commandline of whatever calls it.
> > Really, you should make it an (optional) argument to main'asm_init...
>
> But then the individual assembler scripts wil
Ulf Moeller wrote:
>
> > You mean the bit about target type? But the scripts actually pass that
> > in, it isn't picked off the command line, nor does it say where it comes
> > from.
That's better (though I think $ARGV[$#ARGV] instead of $ARGV[1] is
eccentric, but then it's Perl and There's More
Ulf Möller wrote:
>
> While we are adding new stuff for 0.9.3, shouldn't we set
> OPENSSL_VERSION_NUMBER to some value greater than 0x0922 and
> less than 0x0930?
Definitely. I think it may be time to move to a more appropriate
numbering scheme (given that people can get snapshots).
Cheers,
Be
Bodo Moeller wrote:
>
> s3_srvr inconsistently uses s->ctx->default_cert->rsa_tmp_cb for
> temporary RSA keys, but s->session->cert->dh_tmp_cb for ephemeral DH
> keys. So the comment in the definition of struct cert_st (aka CERT)
> in ssl_locl.h is wrong:
>
> /* FIXME: Although rsa_tmp
Alicia da Conceicao wrote:
>
> Further update...
>
> The "genrsa" freeze that occurs with openssl 0.9.2b, also occurs with the
> lastest snapshot of openssl, which is SNAP-19990402. In addition, also with
> both openssl 0.9.2b and with SNAP-19990402, "make test" goes all the way to
> the "rsa_o
Wade L. Scholine wrote:
>
> I recently updated to OpenSSL 0.9.2b from SSLeay 0.9.0b. Building 0.9.2b was
> *almost* effortless, I list the exceptions here for your delectation. If
> anyone is interested, I have a complete transcript of the build session,
> which I did in an emacs shell buffer in
Richard Levitte - VMS Whacker wrote:
>
> openssl> o Compilation warnings: ctype-related int vs. char
>
> I sent a patch for this a bunch of weeks ago. Has it been missed, or
> just not taken in yet?
>
> (granted, I use unsigned char instead of int in my changes, because
> that's basically
Ulf Möller wrote:
>
> The defintions from the toplevel Makefile are not included when I run
> make errors. Why is that? (Should I add a definition PERL=perl to
> each Makefile.ssl? Doesn't sound very reasonable to me.)
Pass them on the command line. I'm sure its only not done because it
wasn't n
Dr Stephen Henson wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > That seems very complicated. How about doing this
> > in the Makefile
> > test: cipherlist
> > cipherlist: cipherlist.c
> > ..usual CC rules.
> > And cipherlist is
> > main()
> > {
> > #ifndef NO_DES
> >
Mark J Cox wrote:
>
> I noticed a problem - when the CA list we were loading from a file
> (standard verify_locations stuff) contained a duplicate certificate all
> certificates after the duplicate would be ignored. This patch alters
> X509_load_cert_file() so that if an error occurs looking at
Bodo Moeller wrote:
>
> Down below, as discussed, a patch for getting rid of ctx_size.c and
> pem.org follows. The Configure script obviously should be cleaned up
> if we do this. The new pem.h will differ from the existing pem.org as
> follows (remember that HEADER_ENVELOPE_H is always defined
Bodo Moeller wrote:
>
> On Sun, Apr 11, 1999 at 01:17:19PM +0100, Ben Laurie wrote:
>
> >> (remember that HEADER_ENVELOPE_H is always defined here
> >> because of a previous #include, and that the dummy structure
> >> definitions anyway could fai
Yesterday I wrote the type-safe stack stuff I've been threatening. In
order to test them, I had to use them, of course. This resulted in a
vast patch. It also spreads into type-safe ASN1 sets and other good
stuff. Rather than spam you all with the patch, which you will then
ignore, I'm going to co
[EMAIL PROTECTED] wrote:
>
> I'd like to see the code if you're going to wait
> a bit before committig.
>
> I'm curious how you do it all with macros yet
> maintain type-safety. :)
>
> /r$, wishing for templates...
Don't forget that templates are really just a glorified preprocessor
(w
[EMAIL PROTECTED] wrote:
>
> Ahh, I misunderstood what you meant by macros.
> I thought you meant things like:
> #define sk_X509_push(sk, v) \
> sk_push((stack*)sk, (char*)v)
> Which is, of course, sub-optimal. Having a bunch of
> one-line wrapper functions isn't unreasonable.
Would I do
Dr Stephen Henson wrote:
>
> Ben Laurie wrote:
> >
> >
> > Don't forget that templates are really just a glorified preprocessor
> > (well, OK, they aren't now but they were at first) :-)
> >
> > Seriously, you can do a lot of what templat
Dr Stephen Henson wrote:
> 4. There is no way to lookup by other methods, for example lookup by
> subject key id (needed for proper certificate chain verification) or
> lookup by issuer name (needed to find matching certificates in an SSL
> client when authentication is requested). To add new look
Anonymous wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> said:
> > If everyone thinks it is a terrible idea I'm prepared to undo it. I'll
> > fight first, though, coz I think it is a great idea :-)
>
> I, for one, do think it is a terrible idea and I "vot
Dr Stephen Henson wrote:
>
> Ben Laurie wrote:
> >
> > Dr Stephen Henson wrote:
> > > 4. There is no way to lookup by other methods, for example lookup by
> > > subject key id (needed for proper certificate chain verification) or
> > > lookup by issu
Dr Stephen Henson wrote:
> I suppose this could be done by having a number in the structure which
> says which version of the API is supported. Not at the beginning though
> because that is taken. This does present problems if the someone wants
> to add a device specific "search by" method.
>
> U
I do I'll shut up and like
> it. But here's my POV anyway...
You beat me to that diagnosis: I was heading towards saying the same
thing myself :-)
> Ben Laurie <[EMAIL PROTECTED]> said:
> > Anonymous wrote:
> > > - They fragment a clean general purpo
Martin Kraemer wrote:
>
> Hi,
>
> Without proposing a complete "british english to american english"
> change, I still suggest that the typo in the following BIO modules be
> fixed (from BIO_R_UNINITALISED to BIO_R_UNINITIALISED -- note
> the 'I' after the 'T'). In order to not break backward co
Anonymous wrote:
>
> [EMAIL PROTECTED] said:
> >
> > +#ifndef NOPROTO
> > +static int sk_comp_cmp(SSL_COMP **a,SSL_COMP **b);
> > +#endif
> > +
> >static int sk_comp_cmp(a,b)
> >SSL_COMP **a,**b;
> > {
>
> Is it time to start converting function args to ANSI?
> So NOPROTO w
Ulf Moeller wrote:
>
> > I think to be safe (since this stuff is autogenerated), you have to do
> > a #define BIO_R_UNINITALISED BIO_R_UNINITIALISED in a different
> > location, rather than just leaving the old #define in.
>
> Where would that location be?
Just somewhere else in the header, I
Ulf Moeller wrote:
>
> > > Where would that location be?
> >
> > Just somewhere else in the header, I think...
>
> Anything after the error code stuff disappears after make errors.
> So it would seem we'd have to rename the entire bio.h file and
> include it from a new one. Then frankly I'd pref
Ulf Moeller wrote:
>
> The error codes in bn and evp are also spelled "INITALISED".
> Shouldn't we take the opportunity to change it to the more familiar
> "INITIALIZED"?
Not sure about the Z, but definitely add the I!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once t
Anonymous wrote:
>
> A couple of functions are prototyped static but not declared as such.
>
> And there are a few places where variables are "unsigned char *" when
> they should be "char *" or vice versa, causing warnings from the compiler.
I'm curious to know which compiler, and with what set
Bodo Moeller wrote:
>
> "Roger Bodén" <[EMAIL PROTECTED]>:
>
> > I've noticed that the session re-use doesn't work if I turn on
> > client authentication in my SSL server, [...] A full SSL negotiation
> > is performed each time my client connects. If I turn off client
> > authentication the sess
Wu Zhigang wrote:
>
> Hi,
>
> when I used the BIO Lib, I find I always need abouve 2
> fuction, can we add these to the BIO lib.
Sure, why not?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who ta
601 - 700 of 835 matches
Mail list logo
