First, sorry for posting to -users and -dev. I'm not sure which is
more appropriate.
I'm working on an embedded system with no operating system and am only
interested in signature verification. I've looked at the config and
have decided to go with "no-threads no-zlib no-shared". But I'm
having
On Fri, Oct 20, 2006, Andy Polyakov wrote:
>
> For reference. I was always wondering why do our dlls have to export
> things by ordinal and not by name? It would make sense if we maintained
> backward binary compatibility [so that incompatible functions with same
> name would be exported under
It just occurred to me that the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed (type
REG_BINARY) contains the latest seeded value from everything that
CryptoAPI takes into account when generating its random seed.
CryptoAPI permutes it with RC4 to come up with a pseudo-ran
http://blog.gmane.org/gmane.comp.encryption.openssl.devel/month=20030201
There is an known issue with SSL_CTX_use_certificate_chain_file
where it checks the error stack after calling SSL_CTX_use_certificate,
even if a successful return was reported.
A previous SSL error on the same thread can ca
With this patch, instead of the subjectAltName getting
"othername:unsupported" it will be something like
"othername:UPN<[EMAIL PROTECTED]"
Nice when working with ceritifcates from CAC cards.
__
OpenSSL Project
Seriously, I'd consider Winsock 1.1 as the one which should be left
behind, rather than Windows 2000 users.
Windows 2000 users are not left behind, IPv6 on 2000 would be.
That's what I meant :)
On bright side one can simply throw in
LoadLibrary("wship6.dll") literally anywhere, e.g. next to
Hello Roumen,
On Tuesday, October 17, 2006 at 17:52:34 +0200, Roumen Petrov via RT wrote:
> Please could you defail used software.
The simplest failing setup is:
-a) Sending Linux Debian Woody box:
- OpenSSL 0.9.8d (built from tarball)
- Exim 3.35-1woody2
- Qpopper 4.0.4-2.woody.1
On Oct 20 15:05, Andy Polyakov wrote:
> >Seriously, I'd consider Winsock 1.1 as the one which should be left
> >behind, rather than Windows 2000 users.
>
> Windows 2000 users are not left behind, IPv6 on 2000 would be.
That's what I meant :)
> Keep in mind 0x333, it's 3.51. If we switch to ws2_3
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
Haven't you yourself mentioned that one needs to generate .def file as
well? Care to a
Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
was to target all NT versions [note that 0x333 actually covers even for
Windows 9x, which has at least all 0x333 stubs, so that application can
actually start]. As for winsock versioning. Upon latest modifications to
b_sock.
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
> Second problem with cross build is that make does certificate
> rehash, using freshly compiled c_rehash program. It doesn't lead to make
> failure, but it would be nice to be able to redefine c_rehash as well,
> and use one from host syst
On 2006.10.20 at 14:12:44 +0200, Andy Polyakov wrote:
> >2. Makefile.shared
> > Define NM variable to hold name of nm program (which also differs
> > from just nm when cross-compiling)
> > Replace explicit call to nm by reference to this variable.
>
> Haven't you yourself ment
On Oct 20 13:51, Andy Polyakov wrote:
> Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
> was to target all NT versions [note that 0x333 actually covers even for
> Windows 9x, which has at least all 0x333 stubs, so that application can
> actually start]. As for winsock ver
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
Haven't you yourself mentioned that one needs to generate .def file as
well? Care to
On 2006.10.20 at 13:51:47 +0200, Andy Polyakov wrote:
>
> Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
> was to target all NT versions [note that 0x333 actually covers even for
> Windows 9x, which has at least all 0x333 stubs, so that application can
> actually start]
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
> On Oct 20 14:28, Victor B. Wagner wrote:
> > On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
> > > ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
> > > for supporting old Winsock 1.1 applications. A "mode
On Oct 20 15:21, Victor B. Wagner wrote:
> On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
>
> > > So, use IPV6 on native windows requires considerable changes anyway?
> >
> > I wouldn't say it's considerable. Just a tweak to the loading of
> > getaddrinfo/freeaddrinfo in crypto/bio/b_s
On 2006.10.20 at 15:41:35 +0400, Victor B. Wagner wrote:
I was to quick to send previous patch. Two additional changes
are required: changing order of
#include
and #include "apps.h" in apps/apps.c
and order of and "../e_os.h" in test/randtest.c
Updated patch attached.
Index: Configure
So, use IPV6 on native windows requires considerable changes anyway?
I wouldn't say it's considerable. Just a tweak to the loading of
getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c, AFAICS.
And since we have to include ws2tcpip.h anyway for structure
definitions, we should provide way to avoi
Now I've managed to cross-compile current CVS tree with
Mingw32 crosscompiler both in static and shared version.
Following changes are needed to the source tree:
1. Configure
1.1. Add -Wl,--export-all to the shared library linker command line
1.2. Add -lws2_32 to list of libraries
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
> > So, use IPV6 on native windows requires considerable changes anyway?
>
> I wouldn't say it's considerable. Just a tweak to the loading of
> getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c, AFAICS.
Implementing of dynamic loading by ha
On Oct 20 14:28, Victor B. Wagner wrote:
> On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
> > ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
> > for supporting old Winsock 1.1 applications. A "modern" Winsock 2
> > application should include winsock2.h and ws2tcp
On 2006.10.20 at 13:33:37 +0400, Victor B. Wagner wrote:
> NM=i586-mingw32msvc-nm
> (i've patched Makefile.shared to support NM overriding),
> I get following results:
>
> shared library cryptoeay-0.9.8.dll (why not 0.9.9?) is created,
> but it exports no symbols. So build of ssleay-0.9.8.dll f
On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
> > I'm not an expert on Win32 tcpip history and cannot tell whether it is
> > problem of my mingw32 runtime headers or something also.
>
> ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
> for supporting old Winsock
On Oct 20 13:33, Victor B. Wagner wrote:
> On 2006.10.20 at 10:56:35 +0200, Andy Polyakov wrote:
> > >It is not perfect to, because it assumes that if one uses mingw32
> > >target, there is always some Unix emulation environment (i.e. cygwin,
> > >msys or real Unix in case of cross-builds).
> >
>
On 2006.10.20 at 10:56:35 +0200, Andy Polyakov wrote:
> >It is not perfect to, because it assumes that if one uses mingw32
> >target, there is always some Unix emulation environment (i.e. cygwin,
> >msys or real Unix in case of cross-builds).
>
> As implied earlier I'd actually prefer this, i.e. m
Can you test if './Configure mingw' followed by 'make
CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean
It seems to work. Although when I start make test on real win32 system
Oh, it was with our modified Configure. When I've restarted build with
unmodified 0.9.9 source tree
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
> > Can you test if './Configure mingw' followed by 'make
> > CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean
>
> It seems to work. Although when I start make test on real win32 system
Oh, it was with our modified C
On 2006.10.20 at 08:44:14 +0200, Andy Polyakov wrote:
>
> >>Before I making too much modifications,
> >>Have anyone succeeded in doing so?
> >
> >I do it routinely.
> >
> >1. Modify Configure script, adding target
> >mingw-cross
> >(this all should go into one line)
> > "mingw-cross", "i586-ming
In Debian on Linux / i386, we actually build the shared library 4
times with different optimizations. Once for i386, once for i486, 586,
686/cmov.
Does it really help? I can understand i386 for broadest binary
compatibility, but the rest can as well be code generated for i486 but
optimized fo
30 matches
Mail list logo