> There is no anonymous CVS access restriction. I'm not sure why you'd get > errors. You might want to try SourceForge support.
This is working now; must have been a temporary outage... > I'm delaying official release until the FIPS certificate comes. > Before that > there's still a chance changes need to be made. I see this is in the final stages. When are you expecting it's release? If this isn't complete (i.e., hung up in committee somewhere :)) say, six months from now, will 5.2.3 get released anyway (there are some bug fixes there that would be generally useful outside FIPS certification)? As an aside it would have been nice to have seen some responses on this question earlier. I would have expected many others would have run into this same problem as it's hard to imagine any significant Crypto++ application running on Windows would have been using __stdcall linkage by default. Perhaps there just aren't that many users out there. Either way, someone noticed this after 5.2.1 since the fix is present in the CVS tip... As a result of finding this out the hard way (i.e., deciphering notoriously cryptic - pardon the pun - C++ symbol mismatch errors in a highly templatized interface) we also have re-confirmed our earlier experiences/frustrations working with Crypto++ on this level. Yes, there are examples one can use to get a Crypto++ application put together, but you better be ready to roll up your sleeves for some intense investigation if you ever have problems (link time or otherwise). This is not to say Crypto++ isn't a valuable resource, it is. It is in my experience working with dozens of other open-source frameworks (several of them many orders of magnitude larger), however, that Crypto++ is relatviely more difficult to "reverse engineer" when problems occur. I also believe that, in this case, these concerns could largely be helped by providing more documentation (and I mean more than the supposed doxygen-based "reference manual"). I say this also as someone who generally doesn't play the "I need more documentation card" ;). Finally, since Crypto++ is a community resouce it really falls on the community to assist with this. Without sounding trite one benefit the community provides is the kind of feedback being received on this list (an example is this thread). Going forward, becoming an advanced enough user to provide something like documentation requires some kind of an ability to "intelligetly read through" the source code. Users are currently scared away from contributing to this by: 1) modelling their work around example code (no need to understand the API at a more fundamental level), 2) experiencing difficultly deciphering comple/link/runtime errors, and 3) not having sufficient documentation. Kind of a catch-22 scenario. My feeling is that a watershed improvement to Crypto++ would be real documentation. Regards, -David > ----- Original Message ----- > From: "David Hauck" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, March 28, 2005 1:41 PM > Subject: RE: 5.0.4/5.2.1 Source Compatibility > > > > Hi, > > > > It's me again :)... OK, it looks like the CVS tip has the required > > changes: > > i.e., proper CRYPTOPP_API qualifiers specified in the offending entry > > points > > (specifically the static class methods, e.g., StaticAlgorithmName()). I > > didn't look to see if all the required methods contained these since I > > didn't have any success pulling the tip from Sourceforge > (anonymous login > > errors); I simply added the required mods the to the appopriate header > > files > > in my copy of 5.2.1. This corrects my link errors and also allows API > > applications the ability to use the default __cdecl calling convention. > > > > Is there any way to have the current tip packaged up as a > source release? > > Perhaps this is awaiting the imminent FIPS 140-2 certification > before it > > is > > tagged as CRYPTOPP_5_2_1? Has anonymous CVS access been restricted for > > this > > Sourceforge module? > > > > Thanks, -David > > > >> Hi, > >> > >> These link errors appear to be related to build-specific options > >> related to > >> calling convention. In particular if I change my 5.0.4 project to > >> default to > >> __stdcall in the .NET2003 project settings, the 5.2.1-related > >> link errors go > >> away. > >> > >> We've seen issues related to this in the past and wonder why it is that > >> crypto++ requires referencing projects to be built with the > non-standard > >> __stdcall calling convention. It would be better if the crypto API > >> explicitly qualified its definitions with the _stdcall calling > convention > >> keyword so that API users could continue to use the default calling > >> convention in their project builds (for e.g., this restriction > currently > >> prevents us from referencing/using other APIs - that rely on > the default > >> calling convention - in the same project). > >> > >> It looks like something was done between 5.0.4 and 5.2.1 to try to > >> address > >> this, but likely this was wasn't completely fixed (as our link > >> errors below > >> indicate). Can anyone explain what the current thinking is > >> regarding the API > >> and its explicit (or lack thereof) use of the _stdcall calling > >> convention? > >> Is it a requirement that all API users set the __stdcall calling > >> convention > >> as the default in their projects? Why not just prefix the relevant API > >> definitions explicitly with the _stdcall qualifier? > >> > >> Thanks, > >> -David > >> > >> > Good idea, I will try this. I never did anything special however; > >> > there are > >> > no .NET2003 solution/project files (i.e., no .sln/.vcproj files) > >> > so I simply > >> > loaded up the MSVC++ equivalents (the .dsp project file > actually) into > >> > .NET2003 and built. Nothing special was done. Is there any > >> > particular reason > >> > there are no .NET2003 specific .sln/.vcproj files? > >> > > >> > Thanks, -David > >> > > >> > > This looks like a problem with project settings, rather than code > >> > > compatibility. Are you able to compile the dlltest project > >> > > that comes with > >> > > Crypto++? If so, try making a copy of that project file and > >> > > put your own > >> > > code into it. > >> > > > >> > > ----- Original Message ----- > >> > > From: "David Hauck" <[EMAIL PROTECTED]> > >> > > To: <[email protected]> > >> > > Sent: Friday, March 25, 2005 1:06 PM > >> > > Subject: 5.0.4/5.2.1 Source Compatibility > >> > > > >> > > > >> > > > Hi, > >> > > > > >> > > > Is there a document somewhere that outlines the source level > >> > > > incompatibilites between 5.0.4 (DLL) and 5.2.1 (DLL)? I'm > >> > > getting 5.2.1 > >> > > > (.NET2003) link errors in a pretty basic example that > >> > > workds in 5.0.4 > >> > > > (MSVC6). > >> > > > > >> > > > Code: > >> > > > > >> > > > CFB_Mode<AES>::Encryption cfb(&aes_key[0], aes_key.size(), > >> > > > iv_begin, feed_back_size); > >> > > > cfb.ProcessData(&ciphertext[0], data_begin, data_size); > >> > > > > >> > > > <field types are generally simple: aes_key/ciphertext above are > >> > > > std::vector<char> and data_begin is char*> > >> > > > > >> > > > This links fine with the 5.0.4 DLL, but has the following > >> > > link erros in > >> > > > 5.2.1: > >> > > > > >> > > > x_crypto error LNK2001: unresolved external symbol > >> > > "__declspec(dllimport) > >> > > > bool (__cdecl* CryptoPP::AssignIntToInteger)(class > >> > > type_info const &,void > >> > > > *,void const *)" > >> > > > > ([EMAIL PROTECTED]@@3P6A_NABVtype_info@@[EMAIL PROTECTED]) > >> > > > > >> > > > x_crypto error LNK2019: unresolved external symbol > >> > > "__declspec(dllimport) > >> > > > public: static char const * __cdecl > >> > > > CryptoPP::CFB_ModePolicy::StaticAlgorithmName(void)" > >> > > > > >> > > ([EMAIL PROTECTED]@CryptoPP@@SAPBDXZ) > >> > > referenced > >> > > > in > >> > > > function "public: static class std::basic_string<char,struct > >> > > > std::char_traits<char>,class std::allocator<char> > __cdecl > >> > > > CryptoPP::CipherModeFinalTemplate_CipherHolder<class > >> > > > CryptoPP::BlockCipherFinal<0,class CryptoPP::Rijndael::Enc>,class > >> > > > CryptoPP::ConcretePolicyHolder<class CryptoPP::Empty,class > >> > > > CryptoPP::CFB_EncryptionTemplate<class > >> > > > CryptoPP::AbstractPolicyHolder<class > >> > > > CryptoPP::CFB_CipherAbstractPolicy,class > >> > > CryptoPP::CFB_ModePolicy> >,class > >> > > > CryptoPP::CFB_CipherAbstractPolicy> >::StaticAlgorithmName(void)" > >> > > > > >> > > ([EMAIL PROTECTED]@V > >> > > ?$BlockCipherF > >> > > > > >> > > [EMAIL PROTECTED]@[EMAIL > >> > > PROTECTED]@CryptoPP@@@CryptoPP@@V?$ConcretePolicyH > >> > > [EMAIL PROTECTED]@C > >> > > > > >> > > ryptoPP@@[EMAIL PROTECTED]@VCF > >> > > B_CipherAbstra > >> > > > > >> > > [EMAIL PROTECTED]@@[EMAIL PROTECTED]@@CryptoPP@@@[EMAIL PROTECTED] > >> > > AbstractPolicy > >> > > > > >> > > @2@@2@@CryptoPP@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@V? > >> > > [EMAIL PROTECTED]@2 > >> > > > @@std@@XZ) > >> > > > > >> > > > x_crypto error LNK2019: unresolved external symbol > >> > > "__declspec(dllimport) > >> > > > public: static class std::basic_string<char,struct > >> > > > std::char_traits<char>,class std::allocator<char> > __cdecl > >> > > > CryptoPP::AlgorithmImpl<class > >> > > CryptoPP::SimpleKeyingInterfaceImpl<class > >> > > > CryptoPP::TwoBases<class > CryptoPP::SimpleKeyedTransformation<class > >> > > > CryptoPP::BlockTransformation>,struct > >> > > > CryptoPP::Rijndael_Info>,class > >> > > > CryptoPP::TwoBases<class > CryptoPP::SimpleKeyedTransformation<class > >> > > > CryptoPP::BlockTransformation>,struct > >> > > CryptoPP::Rijndael_Info> >,class > >> > > > CryptoPP::SimpleKeyingInterfaceImpl<class > CryptoPP::TwoBases<class > >> > > > CryptoPP::SimpleKeyedTransformation<class > >> > > > CryptoPP::BlockTransformation>,struct > >> > > > CryptoPP::Rijndael_Info>,class > >> > > > CryptoPP::TwoBases<class > CryptoPP::SimpleKeyedTransformation<class > >> > > > CryptoPP::BlockTransformation>,struct CryptoPP::Rijndael_Info> > > >> > > >>::StaticAlgorithmName(void)" > >> > > > > >> > > ([EMAIL PROTECTED]@V?$SimpleKeyingInt > >> > > [EMAIL PROTECTED] > >> > > > > >> > > [EMAIL PROTECTED]@[EMAIL PROTECTED] > >> > > ptoPP@@@Crypto > >> > > > > >> > > PP@@[EMAIL PROTECTED]@@CryptoPP@@V12@@CryptoPP@@V12@@CryptoPP@@ > >> > > SA?AV?$basic_s > >> > > > [EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@XZ) > >> > > referenced in > >> > > > function "public: static class std::basic_string<char,struct > >> > > > std::char_traits<char>,class std::allocator<char> > __cdecl > >> > > > CryptoPP::CipherModeFinalTemplate_CipherHolder<class > >> > > > CryptoPP::BlockCipherFinal<0,class CryptoPP::Rijndael::Enc>,class > >> > > > CryptoPP::ConcretePolicyHolder<class CryptoPP::Empty,class > >> > > > CryptoPP::CFB_EncryptionTemplate<class > >> > > > CryptoPP::AbstractPolicyHolder<class > >> > > > CryptoPP::CFB_CipherAbstractPolicy,class > >> > > CryptoPP::CFB_ModePolicy> >,class > >> > > > CryptoPP::CFB_CipherAbstractPolicy> >::StaticAlgorithmName(void)" > >> > > > > >> > > ([EMAIL PROTECTED]@V > >> > > ?$BlockCipherF > >> > > > > >> > > [EMAIL PROTECTED]@[EMAIL > >> > > PROTECTED]@CryptoPP@@@CryptoPP@@V?$ConcretePolicyH > >> > > [EMAIL PROTECTED]@C > >> > > > > >> > > ryptoPP@@[EMAIL PROTECTED]@VCF > >> > > B_CipherAbstra > >> > > > > >> > > [EMAIL PROTECTED]@@[EMAIL PROTECTED]@@CryptoPP@@@[EMAIL PROTECTED] > >> > > AbstractPolicy > >> > > > @2@@2@@CryptoPP@@[EMAIL PROTECTED]@D > >> > > > > >> > > > x_crypto error LNK2019: unresolved external symbol > >> > > "__declspec(dllimport) > >> > > > public: static void __cdecl > >> > > > CryptoPP::NameValuePairs::ThrowIfTypeMismatch(char const > >> > > *,class type_info > >> > > > const &,class type_info const &)" > >> > > > > >> > > ([EMAIL PROTECTED]@CryptoPP@@SAXPBDABV > >> > > type_info@@[EMAIL PROTECTED] > >> > > > ) referenced in function "public: virtual void __thiscall > >> > > > CryptoPP::AlgorithmParametersBase2<unsigned char const > >> > > > *>::AssignValue(char > >> > > > const *,class type_info const &,void *)const " > >> > > > > >> > > ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@UBEXPBD > >> > > ABVtype_info@@ > >> > > > [EMAIL PROTECTED]) > >> > > > > >> > > > Thanks in advance, > >> > > > -David > >> > > > > >> > > > >> > > > >> > > >> > > >> > > > >
