[openssl.org #445] typos in man pages
I've made the corrections (most were already there) in 0.9.7a-dev and 0.9.8-dev. This ticket is now resolved. [[EMAIL PROTECTED] - Fri Jan 10 08:44:04 2003]: Hello, Some typos in the openssl man pages were discovered (see NetBSD's PR misc/19627 http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=19627), attached please find a patch to correct them. Cheers, -Jan -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Get client IP
Hi, I use BIO to make a client-server connexion, For the server, How can I get the IP of the client when a connexion is accepted Thanks __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #432] pkcs#11 engine for openssl 0.9.7 0.9.6
It's unfortunate that cryptoki.h is GPLd, or I would put it in our contribution area. GPL is not compatible with the OpenSSL license. Is it possible to get a different cryptoki.h? Also, is conf.h really necssary? I'm willing to do the transformation needed for this bundle to work properly within OpenSSL. [[EMAIL PROTECTED] - Fri Jan 3 06:44:06 2003]: This is a contribution for a generic pkcs#11 engine for openssl 0.9.7 and 0.9.6h. Thanks to add it to the openssl contibution page. Best regards -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
[[EMAIL PROTECTED] - Sat Jan 4 12:04:29 2003]: These instructions, from the CHANGES file: == *) Add appropriate support for separate platform-dependent build directories. The recommended way to make a platform-dependent build directory is the following (tested on Linux), maybe with some local tweaks: # Place yourself outside of the OpenSSL source tree. In # this example, the environment variable OPENSSL_SOURCE # is assumed to contain the absolute OpenSSL source directory. mkdir -p objtree/`uname -s`-`uname -r`-`uname -m` cd objtree/`uname -s`-`uname -r`-`uname -m` (cd $OPENSSL_SOURCE; find . -type f -o -type l) | while read F; do mkdir -p `dirname $F` ln -s $OPENSSL_SOURCE/$F $F done To be absolutely sure not to disturb the source tree, a make clean is a good thing. If it isn't successfull, don't worry about it, it probably means the source directory is very clean. [Richard Levitte] == don't work very well -- in particular, files in $OPENSSL_SOURCE which are relative links already will end up as absolute links into $OPENSSL_SOURCE, which breaks those which incorporate results of the Configure step, such as include/openssl/opensslconf.h which should be a link to ../../crypto/opensslconf.h. Hmm, that's a point. Does leaving out '-o -type l' help? -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
I've removed '-o -type l' from the note in CHANGES. I've also added a note on separate build directories at the end of INSTALL. Finally, I've made sure that test/testgen removes the files it generates if they exist before the actual generation. I've tested this against a read-only source tree, and it works. Please test the next snapshot. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
[[EMAIL PROTECTED] - Sat Jan 4 19:22:11 2003]:
On Sat, 4 Jan 2003, Nick Briggs via RT wrote:
[snip]
# Place yourself outside of the OpenSSL source tree. In
# this example, the environment variable OPENSSL_SOURCE
# is assumed to contain the absolute OpenSSL source
directory.
[...]
I think $OPENSSL_SOURCE needs to be a full path name, not relative.
Correct, and it says so in the comment (cited above).
It basicly starts with the commands above but my find doesn't have
-o -type l. It may work with it, I don't know.
It's probably better without. I'm currently checking to see that it works without.
Now I clean up after patch and remove files made from .in files
find . -name *.orig -exec rm -f {} \;
rm -f Makefile.ssl apps/CA.pl apps/der_chop \
crypto/opensslconf.h tools/c_rehash
Why do you need to do those removals? Does something go bad? Why?
Now if you don't want to modify your source tree during the build,
or your source tree is read-only, do something like.
# make sure the auto generated files are writable
for i in ${FILES}
do
rm -f ${i}
cp ${OPENSSL_SOURCE}/${i} ${i}
chmod ug+w ${i}
done
Please explain to me why those removals are necessary. To begin with, ${FILES} are
autogenerated through 'make update', which should be run once in the source tree
('make -f Makefile.org update'...).
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #432] pkcs#11 engine for openssl 0.9.7 0.9.6
Richard Levitte via RT wrote: Hello Richard, It's unfortunate that cryptoki.h is GPLd, or I would put it in our contribution area. GPL is not compatible with the OpenSSL license. Is it possible to get a different cryptoki.h? Also, is conf.h really necssary? conf.h is only incuded if HAVE_CONF_H is defined But it is never defined... I'm willing to do the transformation needed for this bundle to work properly within OpenSSL. From a quick glance: * There is no way to set the PKCS#11 slot number. * There is call to a special bull function C_InitializeRpc(). This is active if a define is set. Would be better to enable it at run time with an parameter But most important: * It seems it does not support threads. I started to work on these problems but there is something other I have to do first... :-( Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
OK, I've hacked a little. Please try the following patch on a 0.9.7 snapshot, and put the attached openssl-shared.txt in doc/: Index: Makefile.org === RCS file: /e/openssl/cvs/openssl/Makefile.org,v retrieving revision 1.154.2.49 diff -u -u -r1.154.2.49 Makefile.org --- Makefile.org9 Jan 2003 16:15:06 - 1.154.2.49 +++ Makefile.org10 Jan 2003 12:03:15 - @@ -763,6 +763,12 @@ cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ set $(MAKE); \ $$1 -f $$here/Makefile link-shared ); \ + if [ $(INSTALLTOP) != /usr ]; then \ + echo 'OpenSSL shared libraries have been installed in:'; \ + echo ' $(INSTALLTOP)'; \ + echo ''; \ + sed -e '1,/^$/d doc/openssl-shared.txt; \ + fi; \ fi cp openssl.pc $(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig The OpenSSL shared libraries are often installed in a directory like /usr/local/ssl/lib. If this directory is not in a standard system path for dynamic/shared libraries, then you will have problems linking and executing applications that use OpenSSL libraries UNLESS: * you link with static (archive) libraries. If you are truly paranoid about security, you should use static libraries. * you define the LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH (HP), DYLD_LIBRARY_PATH (MacOS X) or PATH (Cygwin and DJGPP) environment variable and add the OpenSSL shared library directory to it, and use the -L linker option. * you use the GNU libtool code during linking (http://www.gnu.org/software/libtool/libtool.html) * you use pkg-config during linking (this requires that PKG_CONFIG_PATH includes the path to the OpenSSL shared library directory) (http://www.freedesktop.org/software/pkgconfig/) * you specify the system-wide link path via a command such as crle(1) on Solaris systems. * you add the OpenSSL shared library directory to /etc/ld.so.conf and run ldconfig(8) on Linux systems. One common tool to check the dynamic dependencies of an executable or dynamic library is ldd(1) on most UNIX systems. See any operating system documentation and manpages about shared libraries for your version of UNIX. The following manpages may be helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP], ldd(1), crle(1) [Solaris], pldd(1) [Solaris], ldconfig(8) [Linux].
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: ldd problems
OK, I've hacked a little. Please try the following patch on a 0.9.7 snapshot, and put the attached openssl-shared.txt in doc/: Index: Makefile.org === RCS file: /e/openssl/cvs/openssl/Makefile.org,v retrieving revision 1.154.2.49 diff -u -u -r1.154.2.49 Makefile.org --- Makefile.org9 Jan 2003 16:15:06 - 1.154.2.49 +++ Makefile.org10 Jan 2003 12:03:15 - @@ -763,6 +763,12 @@ cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ set $(MAKE); \ $$1 -f $$here/Makefile link-shared ); \ + if [ $(INSTALLTOP) != /usr ]; then \ + echo 'OpenSSL shared libraries have been installed in:'; \ + echo ' $(INSTALLTOP)'; \ + echo ''; \ + sed -e '1,/^$/d doc/openssl-shared.txt; \ + fi; \ fi cp openssl.pc $(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
-- OpenSSL Shared Libraries have been installed in: [directory name] If this directory is not in a standard system path for dynamic/shared libraries, then you will have problems linking and executing applications that use OpenSSL libraries UNLESS: There is another option, The Right Thing:-) To start with the problem is formulated incorrectly in my opinion. To make 'ldd libssl.so' work is not actually *the* goal, 'ldd openssl' or 'ldd target-app' is. And the first priority answer to the problem should be *embedded* run-time library path. Well, it can be embedded even into .so object, but it's not necessary a good thing. Because you might want to include a copy into some bigger package and install it in alternative location. Embedded run-time library path belongs in application, not .so, and that's what you want to control. How does one control the run-time library path in general? Yes, crle is a way, but it first appears in Solaris 8, it's pain in network environment (you have to configure it on every damn machine) and is not plain-user friendly. Yes, LD_LIBRARY_PATH[_64] environment variable is another way, but you don't want to rely on it as users are bound to fail to [re]set it. Finally (the option I refer to as embedded run-time path), it's possible to set LD_RUN_PATH at link time or pass -R flag to the linker(*). Currently OpenSSL does embed run-time path into .so on some OSes (Tru64?), but I for one am not actually fond of it. As already mentioned [even last year] I believe that it should be embedded into application where it belongs (.so never run). Another argument against embedding it onto .so is presence of multiple ABI and not having real control over which ABI was actually chosen. It's those who deploy the toolkit [are expected to] have the grip over the run-time library path (they might even choose to embed multiple path), not us. That's what I basically ment last year that we should stand for code and documentation, but not for the run-time path itself. Well, we have to care about openssl application itself, but again, not by embedding the run-time path into .so, but into the application. Bottom line. +1 for proposed documentation with explicit mention and prioritizing (i.e. #2 after static linking:-) of embedded run-time path and lowering LD_LIBRARY_PATH priority. As for pkgconfig. I know nothing about it, but assume that openssl.pc has everything to do with it. I think it's a good idea to put -R/-rpath into it. (*) Most OSes support equivalent option. Most notably -rpath (Linux, Tru64, IRIX). And when it comes to Solaris and Linux there is an easter egg here. Starting with 2.6 Solaris run-time linker implements support for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the application will be looking for .so objects in ../lib relative to the application binary. This $ORIGIN thing is very useful. It's so useful, that it's tempting to wrap openssl binary into a script which would emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the way autoconf does in build tree. Should I look into it? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #447] [Fwd: Bug#176058: openssl: Should ask password only after basic input validation]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #448] [Fwd: Bug#176062: openssl: Expired certificates and recertification]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #449] [Fwd: Bug#176059: openssl: ca shows CSR contents, not preview of certificate]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds
I think a sufficient requirement is that files in the source tree that are relative links need to be recreated as relative links within the platform dependent directory. If you just leave out the -o -type l you won't make any of the links, and the include/openssl directory will be empty, which will fail. Of course your source directory needs to be absent any residual configuration -- which would cause the script to make links to files that would be created by Configure and might then cause subsequent Configures to update the source tree version. Overall, I think I prefer (modern) make's VPATH, but i'm not sure that that fits your requirements for portability. \nick __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds
I'll try the next snapshot.Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
[[EMAIL PROTECTED] - Fri Jan 10 16:35:08 2003]: I think a sufficient requirement is that files in the source tree that are relative links need to be recreated as relative links within the platform dependent directory. exactly. If you just leave out the -o -type l you won't make any of the links, and the include/openssl directory will be empty, which will fail. Only if you don't configure in your build tree. Why should you leave that out? Of course your source directory needs to be absent any residual configuration -- which would cause the script to make links to files that would be created by Configure and might then cause subsequent Configures to update the source tree version. What files is Configure creating that you're worried about and that 'make clean' doesn't take care of? To be very exact, what in this sequence doesn't work? - make the object tree with soft links to the source tree files. - make -f Makefile.org clean - ./config Overall, I think I prefer (modern) make's VPATH, but i'm not sure that that fits your requirements for portability. Well, can you guarantee that VPATH works with all current make implementations? In any case, the whole make tree needs an overhaul, which I intend to attempt for 0.9.8, but with a lower priority than other stuff... -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 15:03:00 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro There is another option, The Right Thing:-) Of course :-). Unfortunately, about -R/-rpath, I've avoided it so far for exactly the reason you mentioned: it doesn't quite support moving libraries to a dofferent place and still have it work. And also, I have understood that libssl.so does need a -R/-rpath to be able to find libcrypto.so, on which it depends. And you're quite correct, the openssl application should be linked with it, which we don't do at all today... appro (*) Most OSes support equivalent option. Most notably -rpath (Linux, appro Tru64, IRIX). And when it comes to Solaris and Linux there is an easter appro egg here. Starting with 2.6 Solaris run-time linker implements support appro for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the appro application will be looking for .so objects in ../lib relative to the appro application binary. This $ORIGIN thing is very useful. It's so useful, appro that it's tempting to wrap openssl binary into a script which would appro emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the appro way autoconf does in build tree. Should I look into it? That's a good idea. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: ldd problems
I just committed the final change that makes 'make install' print a recommendation on handling the shared libraries of such a thing was installed anywhere else than in /usr/lib. The text that's shown is rather close to the one suggested by Jeff, with additions about pkg-config and a reordering according to Andy's suggestion. This ticket is now resolved. Any problems should be reported as a NEW ticket. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems
Unfortunately, about -R/-rpath, I've avoided it so far for exactly the reason you mentioned: it doesn't quite support moving libraries to a dofferent place and still have it work. And that is what I'm suggesting to adhere to. I.e. to avoid it (and even to remove it from tru64!) and leave this final decision to those who deploy the toolkit. And also, I have understood that libssl.so does need a -R/-rpath to be able to find libcrypto.so, on which it depends. This is not true. The fact that 'ldd libssl.so' says can't locate libcrypto.so does *not* mean that libssl.so is bound to fail to link with libcrypto.so. -L and -R options at *application* link time provide for that. -R/-rpath option at libssl.so link time can and should be omitted. -R/-rpath option at *application* link time is the one to be used. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423]openssl-0.9.7-stable-SNAP-20021229:lddproblems
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 17:40:18 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro And also, I have understood appro that libssl.so does need a -R/-rpath to be able to find libcrypto.so, appro on which it depends. appro appro This is not true. The fact that 'ldd libssl.so' says can't locate appro libcrypto.so does *not* mean that libssl.so is bound to fail to link appro with libcrypto.so. -L and -R options at *application* link time provide appro for that. -R/-rpath option at libssl.so link time can and should be appro omitted. -R/-rpath option at *application* link time is the one to be appro used. Ah, so recursive loads inherit the -R/-rpath values? It's good to know I misunderstood this. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCE] OpenSSL 0.9.7 released
On Thu, Jan 09, 2003 at 10:35:16PM +0100, Corinna Vinschen wrote: The 2 is just sort of a counter which is needed to allow more than [...] Hi, I have chosen another packaging method: Version 0.9.6h will consist only of the needed DLLs to link applications build against it. The package will be called openssl096-0.9.6h-1.tar.bz2 The new 0.9.7 version will become the openssl package again, as the 0.9.6 version before. So the new packages are still just called openssl: openssl-0.9.7-1.tar.bz2 openssl-devel-0.9.7-1.tar.bz2 openssl-0.9.7-1-src.tar.bz2 That means, the patch to util/cygwin.sh can be reverted to create the normal openssh packages again instead of openssh2. Is that ok with you? Would you revert the cygwin.sh patch then? Thanks in advance, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #450] openssl-0.9.7 not building with ncr-scde
Hello, i try building openssl-0.9.7 on an ncr server using ./Configure ncr-scde ( uname -a: cti1dev cti1dev 4.0 3.0 3360,3430-R Pentium(TM)-MCA login info: Welcome to the NCR MP-RAS SVR4 UNIX System UNIX System V Release 4.0 (cti1dev) (pts/0) ) and i get the following linker errors (unresolved symbols): NCR High Performance C Compiler R3.0c (c) Copyright 1994-97, NCR Corporation (c) Copyright 1987-97, MetaWare Incorporated rm -f openssl if [ = hpux-shared -o = darwin-shared ] ; then \ cc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_NO_KRB5 -O6 -Xa -Hoff=BEHA VED -686 -Hwide -Hiw openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passw d.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_ra nd.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine. o ocsp.o ../libssl.a ../libcrypto.a -lsocket -lnsl ; \ else \ cc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_NO_KRB5 -O6 -Xa -Hoff=BEHA VED -686 -Hwide -Hiw openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passw d.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_ra nd.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine. o ocsp.o -L.. -lssl -L.. -lcrypto -lsocket -lnsl ; \ fi Undefined first referenced symbol in file strcasecmp ca.o ftime speed.o UX:ld: ERROR: openssl: fatal error: Symbol referencing errors. No output written to openss l *** Error code 1 (bu21) make: fatal error. *** Error code 1 (bu21) make: fatal error. Any ideas ? regards, Martin -- DREGIS Dresdner Global IT-Services Gesellschaft mbH Advance Bank Services Martin Megele Putzbrunner Str. 71 81739 München Tel.: ++49 (0)89 62729-272 Fax: ++49 (0)89 62729-687 EMail: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #450] openssl-0.9.7 not building with ncr-scde
On Fri, 10 Jan 2003, Megele, Martin via RT wrote: Hello, i try building openssl-0.9.7 on an ncr server using ./Configure ncr-scde ( uname -a: cti1dev cti1dev 4.0 3.0 3360,3430-R Pentium(TM)-MCA login info: Welcome to the NCR MP-RAS SVR4 UNIX System UNIX System V Release 4.0 (cti1dev) (pts/0) ) and i get the following linker errors (unresolved symbols): NCR High Performance C Compiler R3.0c (c) Copyright 1994-97, NCR Corporation (c) Copyright 1987-97, MetaWare Incorporated rm -f openssl [snip] cc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_NO_KRB5 -O6 -Xa -Hoff=BEHA VED -686 -Hwide -Hiw openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passw d.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_ra nd.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine. o ocsp.o -L.. -lssl -L.. -lcrypto -lsocket -lnsl ; \ fi Undefined first referenced symbol in file strcasecmp ca.o Try adding -lresolv ftime speed.o UX:ld: ERROR: openssl: fatal error: Symbol referencing errors. No output written to openss l -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #434] duplicate execution of callback with non-blocking SSL_accept
[[EMAIL PROTECTED] - Fri Jan 3 08:21:38 2003]: When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? You are talking of the verify callback? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
[[EMAIL PROTECTED] - Fri Jan 3 06:45:12 2003]: I'm trying to compile 0.9.7 with Borland C++ 5.5 and NASM 0.98.35 on Windows XP Professional SP1 with all updates. I did perl Configure BC-32 no-idea no-mdc2 no-rc5 ms\do_nasm make -f ms\bcb.mak It fails at: bcc32 -otmp32\x_all.obj -Iinc32 -Itmp32 -DWIN32_LEAN_AND_MEAN -q -w-aus -w-par -w-inl -c -tWC -tWM -DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp -O2 -ff -fp -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 -c .\crypto\x509\x_all.c .\crypto\x509\x_all.c: Error E2450 .\crypto\x509\x_all.c 72: Undefined structure 'ASN1_ITEM_st' in function X509_verify Error E2450 .\crypto\x509\x_all.c 72: Undefined structure 'ASN1_ITEM_st' in function X509_verify ASN1_ITEM_st was added in OpenSSL 0.9.7. It therefore seems, that old header files are picked up. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #450] openssl-0.9.7 not building with ncr-scde
On Fri, 10 Jan 2003, Tim Rice wrote: On Fri, 10 Jan 2003, Megele, Martin via RT wrote: Undefined first referenced symbol in file strcasecmp ca.o Try adding -lresolv ftime speed.o Oops, didn't see ftime. Does your system have libc89.a ? Maybe try -llibc89 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #431] Help
[[EMAIL PROTECTED] - Thu Jan 2 13:14:21 2003]: Hello, I would configure and install a certification from openssl for Windows 2000 IIS. This is not a bug or enhancement report with respect to the OpenSSL package. Please ask your question on the openssl-users mailing list. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #408] Segmentation Fault (openssl-0.9.7-beta6)
[levitte - Fri Dec 20 09:28:56 2002]: Looks to me like everything was successful, really, even index.txt is up to date. Do you have the possibility to debug and find out exactly where the segfault happened? [[EMAIL PROTECTED] - Wed Dec 18 17:22:44 2002]: While executing the following command, openssl gave a segmentation fault. I am using openssl-0.9.7-beta6. I am also attaching the index.txt, openssl.cnf, newcert.pem, and newreq.pem files. % openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever -extensions xpclient_ext -extfile xpextensions -infiles newreq.pem ... Changes were made in ca.c with respect to PR#430 which also dealt with a segmentation fault. Can you reproduce the problem with 0.9.7 release? If you can reproduce it, does it still appear with the latest 0.9.7a development snapshot? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
On Fri, 10 Jan 2003 21:27:56 +0100 (MET), Lutz Jaenicke via RT
[EMAIL PROTECTED] said:
[[EMAIL PROTECTED] - Fri Jan 3 06:45:12 2003]:
I'm trying to compile 0.9.7 with Borland C++ 5.5 and NASM 0.98.35 on
Windows XP Professional SP1 with all updates.
I did
perl Configure BC-32 no-idea no-mdc2 no-rc5
ms\do_nasm
make -f ms\bcb.mak
It fails at:
bcc32 -otmp32\x_all.obj -Iinc32 -Itmp32 -DWIN32_LEAN_AND_MEAN
-q
-w-aus -w-par -w-inl -c -tWC -tWM -DOPENSSL_SYSNAME_WIN32
-DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp -O2 -ff -fp
-DBN_ASM
-DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_NO_IDEA
-DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 -c
.\crypto\x509\x_all.c
.\crypto\x509\x_all.c:
Error E2450 .\crypto\x509\x_all.c 72: Undefined structure
'ASN1_ITEM_st'
in function X509_verify
Error E2450 .\crypto\x509\x_all.c 72: Undefined structure
'ASN1_ITEM_st'
in function X509_verify
ASN1_ITEM_st was added in OpenSSL 0.9.7. It therefore seems, that
old header files are picked up.
I tried 0.9.7 before succesfully compiling 0.9.6h.
As Doug Kaufman suggested for some reason asn1t.h doesn't get included. I
had to manually edit a dozen source files.
I also have Cygwin in c:\cygwin, but my PATH shows:
PATH=C:\usr\Perl\bin\;C:\usr\Borland\Bcc55\Bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
I really don't see how it could be including other headers if I did
everything from g:\Linux\openssl-0.9.7.
--
0@pervalidus.{net, dyndns.org}
--
http://fastmail.fm - And now for something completely different...
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #434] duplicate execution of callback with non-blockingSSL_accept
Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Fri Jan 3 08:21:38 2003]: When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? You are talking of the verify callback? Yes, the client verify_callback. Thanks, -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #449] [Fwd: Bug#176059: openssl: ca shows CSR contents, not preview of certificate]
[[EMAIL PROTECTED] - Fri Jan 10 15:10:09 2003]: Ugh, can't quote the original message... This refers to OpenSSL 0.9.6X which does indeed only show the DN of the CSR (or pseudo CSR in the case of SPKACs) including the old mishandling of multibyte string types. That's one reason why I didn't add extension copying to 0.9.6X: you can't see what extensions you are adding which is a big security issue. OpenSSL 0.9.7 does not have this problem and the contents of the preview are highly configurable, including such things as extensions in the certificate. See 0.9.7 docs. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
