help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: win32 Visual Studio 2005 project for gsasl


From: Simon Josefsson
Subject: Re: win32 Visual Studio 2005 project for gsasl
Date: Fri, 11 Apr 2008 09:31:10 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Adam Strzelecki <address@hidden> writes:

> Hello,

Hi Adam!  I'm now slowly catching up on this.  I'm starting by cc'ing
the list with an answer to your message which ended up in my private
inbox..

>> Thanks, Adam!  I'm forwarding this to the gsasl list so that others
>> can
>> see it.  I think we'll eventually end up with a number of win32
>> packages:
>
> Well I found many of them simply not working (unless using libgcrypt)
> due /dev/random that didn't exist on Windows.
>
> Also native MSVC projects that link against Microsoft CL (C++
> compiler) not GCC enable Windows developers using MSVC debugger also
> debug LIBIDN or GSASL side-libraries. GDB format and MCVC PDB formats
> are not compatible.

Ok.

>>> Yeah, that wasn't the cutest thing I've done ;) Attached patches use
>>> CryptGenRandom now, thanks for the tip.
>>> Patches were tested on Windows XP and Windows 2003.
>> Thanks, this is better.  I think we should note in the documentation
>> that the Windows PRNG is known to have some known flaws.
>
> On one hand all of Win 2xxx versions went successful trough EAL4+ but
> indeed I've read about some reports that Windows 2000 version has some
> flaws. This may be noted somewhere in the documentation of gsasl, that
> using it on Windows 2000 with no libgcrypt may cause some security
> risk.

Yup.  I've added a note in the GNU SASL manual.

>> There is a *.def file in your patch, isn't it possible to generate it?
>> I didn't see one in your libidn patch.  When I build the mingw
>> build, it
>> will generate a *.def file too.  I'm worried I have to manually have
>> to
>> maintain the file.
>
> Well, I tried to be as minimal with the changes as possible. If you
> really want to say bye bye to *.def you need to use Windows way of
> exporting functions & variables to DLL. In libidn's win32 Perl script
> I exactly replace all exports with LIBIDN_API, and for gsasl we would
> need to do the same:
>
> /* GSASL Windows DLL */
> #ifndef GSASL_API
> # if defined(_WIN32) && !defined(GSASL_STATIC)
> #  ifdef GSASL_EXPORTS
> #   define GSASL_API  __declspec(dllexport)
> #  else /* GSASL_EXPORTS */
> #   define GSASL_API  __declspec(dllimport)
> #  endif /* GSASL_EXPORTS */
> # else /* _WIN32 && !GSASL_STATIC */
> #  define GSASL_API extern
> # endif /* _WIN32 && !GSASL_STATIC */
> #endif /* GSASL_API */
>
> And then use "GSASL_API" in all official headers instead of "export"
> for functions and variables. This is only related to those that should
> be exported to DLL. On GCC ELF (Linux, Mac, etc.) all "export" are
> exported, on Windows you need to explicitly mark it with
> __declspec(dllexport) or use *.def files, or you won't get anything
> into DLL.
> Also when you will be using the DLL you need to use
> __declspec(dllimport).
>
> So if you want I can prepare LIBIDN and GSASL patches that define this
> inside the sources, not with external tricks.

Thanks for explaining.  Maintaining the *.def file manually will be a
problem, so I'd appreciate if you could prepare a patch that adds a
GSASL_API symbol.  I'd prefer to keep the 'extern' markers in the code
though, so on non-Windows systems I would want that GSASL_API evaluates
to the empty string.  That isn't a problem for Windows, right?

Note that I've applied parts of your patches to git, so it is easiest if
you make the patch apply to the current git head.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]