Re: Windows 8 anyone?
On 3/3/2012 12:58 PM, André Hentschel wrote:
Anyone has the new Visual Studio? I wonder if it includes an ARM
Crosscompiler...
Yes, there is one in the Visual Studio 11 Express that comes with the
developer preview.
Here an excerpt from "cl /?" output :
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.40825.2 for ARM
/arch: minimum CPU architecture requirements, one of:
VFPv3 - enable use of VFPv3 instructions
VFPv3-D32 - enable use of VFPv3 instructions with 32 double
precision registers available
and an excerpt from "link /?" :
/MACHINE:{ARM|EBC|X64|X86}
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
Re: Windows 8 anyone?
On 3/3/2012 3:08 AM, Aric Stewart wrote: So for some conversation that is not release related... Anyone installed the windows 8 consumer preview yet? It refuses to install in my virtual box or (old) vmware fusion machines. I think it really wants real hardware. If someone does has a copy running, maybe i can send a uniscribe script enumerator that you would run and send me the result? I would be curious what new languages Microsoft has added. I tried in the developer preview from a few months ago and nothing had really been updated there. -aric Hi Aric, I was able to install the consumer preview on my VirtualBox 4.1.8 the same way as the developer preview (2G of RAM, 40G of disk, 128M Video Memory, "Use host I/O cache" checked on the storage section). I can run your test if you want. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Re: winscard
On 9/30/2011 4:47 PM, Marcus Meissner wrote: +State = pStates[i].dwEventState& (~SCARD_STATE_CHANGED); > +rgReaderStates[i].cbAtr = pStates[i].cbAtr; > +memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? I'll answer this since these patches are taken from my original big patch: copying cbAtr bytes makes more sens but copying MAX_ATR_SIZE is not wrong since the two buffers are of the same size and here we are just transferring all bytes from pcsclite side to the WIN32 side. That being said, maybe putting pStates[i].cbAtr will help the patches be accepted. By the way, I want to thank Vincent for taking the time to try to incorporate the winscard code into Wine. Without his dedication, this could languish for many years more! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Re: winscard.dll
Vitaliy Margolen kievinfo.com> writes: > > +/* get list from pcsc-lite */ > > +*pmszReaders = (LPSTR*) mszReaders; > You corrupting memory here. You haven't assigned any memory to pmszReaders. > Did you mean to write "pmszReaders = (LPSTR) mszReaders;" ? In fact I don't > see you using the assigned value at all. > > Also you have some trailing spaces in your patch. > > Vitaliy. > > Hi Vitaliy, You are right : In my original patch , the line reads : /* get list from pcsc-lite */ LPSTR* pmszReaders = (LPSTR*) mszReaders; Vincent changed that by declaring pmszReaders at the beginning but he left the star in front of pmszReaders in the affectation. In his version of the patch, this line should read : /* get list from pcsc-lite */ pmszReaders = (LPSTR*) mszReaders; Innocent source code editing can introduce big bugs if not done (and tested) properly! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Re: winscard.dll
viny gmail.com> writes: > > Yes I started with this referenced discussion. > > Here is a first patch. With it, Winscard can identify your smartcard reader. > > Is it good enough to be sent to wine-patch ? Hi Vincent, I'm the original author of the Winscard patch sent in 2007 and I see that the patch you have sent is just a subset of the code I originally posted. However, I don't see any credits to me or IDRIX in you submission. I'm sure this is a honest omission and I hope that it will be corrected in future patches. Just for the record, I provide since 2007 a 32bit Linux binary of winscard.so.dll that have full PC/SC support. Last Tests conducted two weeks ago against Wine 1.3.1 and latest Linux ditros. Here is the link to it : http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz In the coming days, I'll prepare an updated version of the 2007 patch that can be applied cleanly against the latest source tree. That being said, I thank Vincent for his efforts in order to revive Wincard integration into Wine and I hope that it will finally succeed after more than three years of stagnation. Till now, most smart card users under Wine rely solely on the binary I provide or compiling their own using the original patch. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Re: Winscard: Correct the declaration of SCardReleaseStartedEvent to match MSDN
Hi, You're right: I have done a small test and MSDN is indeed wrong on the definition of this function. Sorry for my erroneous patch. -- Mounir IDRASSI IDRIX http://www.idrix.fr On Wed, August 27, 2008 4:43 am, Dmitry Timoshkov wrote: > "Mounir IDRASSI" <[EMAIL PROTECTED]> wrote: > >> This patch corrects the declaration of the function >> SCardReleaseStartedEvent of Winscard to match its definition in MSDN >> found >> in the following link : >> >> http://msdn.microsoft.com/en-us/library/aa379799(VS.85).aspx > >> -voidWINAPI SCardReleaseStartedEvent(void); >> +voidWINAPI SCardReleaseStartedEvent(HANDLE); > > This doesn't match an actual declaration used by PSDK. It's better to > use PSDK for a reference, not an online documentation since the latter > one is proved to have many typos. > > -- > Dmitry. >
Re: [Patch] 0001-Support-for-winscard.dll.patch
Hi All, I have just been informed by one of my contacts that this discussion about Winscard has started. As the original author of Winscard for Wine, I'd like to inform you that I have already posted a fully functional Winscard patch for Wine on April 2007. Here is the link to it : http://www.winehq.org/pipermail/wine-devel/2007-April/056432.html Afterwards, my complete patch was not accepted because I was relying on the fact that alignment of the Winscard structures coming from the WIN32 world is the same as the alignment expected by pcsclite on the system on which Wine is running. My assumption is true for Linux 32Bit but I clearly can't guarantee that on other platforms. Anyway, my implementation is running production systems on two of my customers under Linux 32bit (Ubuntu, CCID readers) and it has been tested by many users who contacted me directly to provide them with the full featured winscard version. For that, I distribute the winscard binary for 32-bit Linux systems under the following link : http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz I think it would be more efficient if your effort can benefit from my patch and all the experience I have put on it. The source from my side has evolved a little bit but it remains close to the original posting. I hope there will room for collaboration of this to provide a maximum number of Wine users with smart cards functionalities. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Concerning Bug 11509 (AES Provider Handling for Windows XP)
Hi, >From what I see, the patch correcting this bug from Vijay has been refused because it modifies the name of the RSA and AES provider, which is wrong. However, this patch can be easily changed to keep the current name and simply add a new provider name. So, the declaration of the variable szRSAName should be changed to "static const WCHAR szRSAName[4][66]" and its value appended at the end with the new name of the provider for XP instead of modifying the last field. This way, I'm sure the patch will be accepted. Vijay : can you submit a modified version of your patch. Cheers, Mounir IDRASSI IDRIX - Cryptography And IT Security Experts http://www.idrix.fr
Re: wincrypt: add missing defines
You forgot the attachement... Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > --Juan > > > > > Choose the right car based on your needs. Check out Yahoo! Autos new Car > Finder tool. > http://autos.yahoo.com/carfinder/ > > > > >
Re: advapi32: Allow setting CRYPT_VERIFYCONTEXT and CRYPT_NEWKEYSET in CryptAcquireContext
Hi Maarten, You should not modify advapi32 to accommodate this behavior but rsaenh instead. The acceptance of this flags combination is specific to the Microsoft RSA CSP implementation and other vendors don't support it (I tested it with four third party CSPs). Moreover, your patch will clearly introduce unexpected CSP behavior when this combination of flags is specified as you start by acquiring a context using CRYPT_NEWKEYSET only: the returned context will not behave as intended by the CRYPT_VERIFYCONTEXT flag which normally limits many things. The modification to rsaenh is straightforward: in the code of RSAENH_CPAcquireContext, juste add the line "case CRYPT_VERIFYCONTEXT | CRYPT_NEWKEYSET:" above the existing line "case CRYPT_VERIFYCONTEXT:". Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > With tests. I think this is the correct way to do this: First try to > Acquire with CRYPT_NEWKEYSET, then CRYPT_VERIFYCONTEXT if it already exists. >
Re: CryptAcquireContext can have multiple flags defined at the same time, V2
Hi Marteen, As you mentioned, I can confirm that this combination of flags is allowed only when the default container is specified (the second parameter pszContainer set to NULL). So, a small patch would consist of adding this flags combination to the same switch code of CRYPT_VERIFYCONTEXT. Could you please send the patching code along with the test to the patches list?. Thanks for pointing this behavior. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > Hello, > > After retrying, I tried the same function arguments that msn messenger > 7.5 passes to advapi32. It seems that function _is_ allowed to define > the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT at the same time. > > I tried the same flags for advapi32 crosstest 'crypt' in linux and windows. > > Linux: > $ wine advapi32_crosstest.exe crypt > crypt.c:198: Test failed: 0/80090009 > > windows 2000: > Test didn't fail. > > Patch attached. > Note that second parameter must be NULL for this call to succeed. > > Maarten >
Re: gdiplus: added stub implementation of gdiplus.dll
Hi, You also have to modify other files in order to integrate your stub implementation to the wine build chain: Makefile.in, configure and configure.ac in the wine root directory, Makefile.in in the "dlls" directory. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Evan Stade wrote: > Changelog: > * added stub implementation of gdiplus.dll (3 files) > > dlls/gdiplus/Makefile.in | 16 + > dlls/gdiplus/gdiplus.c| 45 +++ > dlls/gdiplus/gdiplus.spec | 609 > + > 3 files changed, 670 insertions(+), 0 deletions(-)
Re: rsaenh: AcquireContext can have multiple flags defined at the same time
Hi, Your patch is wrong: the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT can't be mixed and if they are set together like in your patch AcquireContext should return NTE_BAD_FLAGS. You can check that using the MS implementation under windows. It's also clearly stated in MSDN that CRYPT_VERIFYCONTEXT is reserved for non persistent operations which is not the case when you create a new container. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > According to msdn a combination of flags are set, since I'm not sure > which combo's are valid I put up a FIXME. > > > >
Re: winscard: add pcsc-lite helpers for upcoming implementation (try 2)
Actually, pcsc-lite defines the same headers from PSDK with the same types for 32bit architecture. Including pcsclite headers will clash with wine's headers. The only possible modification is to redefine pcsclite types with different names but this is useless as they are the same as the ones in winscard. The only exception is for winscard handles: in pcsclite they are always defined as "long", whereas in PSDK they are defined as ULONG_PTR. So, for me, the only thing to do is convert those handles back and forth from long to ULONG_PTR. Another possible issue is when wine is running under a 64bit host and pcsclite is compiled on 64bit mode...but I think this is a more global issue. Am I missing something? Please advise. Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > I don't think the pcsc-lite library is guaranteed to be binary > compatible with the Windows definitions. You'll need to include the > correct headers and convert data types between Windows and Unix > definitions. >
re: winscard: add pcsc-lite helpers for upcoming implementation
The code is definitely cleaner with all your suggestions. I'm applying
them now.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
> James wrote:
>> This would be a lot cleaner as:
>>
>> if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
>> wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr)))
>> {
>>ERR("Failed to get SCardEstablishContext from pcsclite library. Error
>> = %s\n",szErr);
>>goto error;
>> }
>
> I think in C you can skip the cast from void *, can't you? e.g.
>
> liteSCardEstablishContext =
> wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr));
Re: winscard: add pcsc-lite helpers for upcoming implementation
Thanks for your comments Juan.
Actually, the upcoming implementation checks the used function pointer at
each call and returns an error if not assigned. Also in it, winscard
always succeed to load even if pcsc-lite is not running. FYI, my first
winscard patch contains an advanced stage of the whole implementation.
Concerning the BOOL return value, it's here for "historical" reasons. I'll
remove it.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://.idrix.fr
> +BOOL InitializePCSCLite(void)
>
> You don't use the return value:
>
> @@ -42,9 +43,11 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD
> fdwReason, LPVOID lpvReserved)
> {
> DisableThreadLibraryCalls(hinstDLL);
> WINSCARD_hModule = hinstDLL;
> +InitializePCSCLite();
> break;
> }
>
> I suspect it's safer not to fail loading winscard if PCSC-Lite isn't
> available. Instead, the functions such as SCardListCards should probably
> return empty lists. But knowing to do so relies on knowing that PCSC-Lite
> couldn't be initialized, so the return value shouldn't be thrown away.
> Or, remove the return value, and have every function check the function
> pointers it needs.
>
> --Juan
Re: winscard: small stub implementation of winscard dll (Try 2)
Hi Alexandre, You are completely right...these variables are definitely useless!! I don't remember when I coded that but it must have been very late at night! Anyway, I'll purge them from the patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <[EMAIL PROTECTED]> writes: >> Thank you for your comments Alexandre. >> Concerning the SCARD_PCI_xxx , I implemented them as variables instead >> of defines because it's impossible using winelib to link against the >> exported variables g_rgSCardXXX (please see my discussion with Eric >> Pouech about that). Well, I should create variables with other names to >> achieve the same goal. >> > Linking against SCARD_PCI_xxx would be just as impossible, so I still > don't understand why you need any extra variables. Could you give an > example? >
Re: winscard stub dll
Hi Francois, Thanks for your modifications. I'll review your patch and submit it if I have no comments, ِCheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Francois Gouget wrote: > Hi, > > Here's a new version of the patch that removes the casts as suggested > by Alexandre. >
Re: winscard stub dll
Hi, Apart from Alexandre comment, I don't see any other possible changes. So, if the first patch containing the API headers is OK, I can submit the winscard stub patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Francois Gouget <[EMAIL PROTECTED]> writes: > > >> * I would really have liked to get rid of the (unsigneg int) casts, but >> as the handle types are ULONG_PTRs it seems like it won't be possible. >> That's quite annoying. If anyone has suggestions... >> > > ULONG_PTRs are longs, they should be printed with %lx without casts. > >
Re: crypt32: remove hardcoded value AT_SIGNATURE from CertContext_SetKeyProvInfo
Hi Alexandre, I analyzed more deeply the code. The test is absolutely correct but the the implementation of the function CertContext_SetKeyProvInfo is definitely incorrect: in MSDN, it's stated that the dwKeySpec field of CRYPT_KEY_PROV_INFO is "the specification of the private key to retrieve". Or, in the code, it's computed as the key specification values supported by the CSP wich is not the same. So, the CertContext_SetKeyProvInfo must be modified to retrieve the key spec of the key related to the certificat, and it should not call CryptGetProvParam. I'm working on that and I'll send a correct patch soon. I analogize for my misunderstanding. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <[EMAIL PROTECTED]> writes: > > Like I said, the test currently passes on Windows, so you can't simply > change it. Tests are supposed to reflect the behavior of Windows, not > of Wine. > >
Re: rsaenh: add support for mandatory parameters to RSAENH_CPGetProvParam
Hi Alexandre, The problem comes from the file cert.c in crypt32 dll (the real one, not the one in tests): at line 1976, the value AT_SIGNATURE is hardcoded in case for failure of CryptGetProvParam. Without my patch, this function definitely fail and the hardcoded value is written. So, a more complete patch would include also a correction to this file. Question: can a patch include corrections to different dlls? I can submit it now. Cheers Mounir IDRASSI IDRIX - Cryptography and IT Security Experts Alexandre Julliard wrote: > Mounir IDRASSI <[EMAIL PROTECTED]> writes: > > >> This patch adds support for mandatory parameters in >> RSAENH_CPGetProvParam. It also adds tests for them. >> The mandatory parameters are: PP_UNIQUE_CONTAINER, PP_PROVTYPE, >> PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE. >> > > Thanks for resending, but unfortunately this breaks make test: > > ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p > crypt32_test.exe.so cert.c && touch cert.ok > cert.c:1215: Test failed: Expected AT_SIGNATURE, got 3 > make: *** [cert.ok] Error 1 > > I know you sent a patch for that test, but since it currently succeeds > on Windows the change can't be right. > >
Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)
Hi Juan, Thanks for your explanations. I'm resubmitting the patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > Yes, certainly. See e.g. recent patches from Paul Vriens to get the tests > succeeding on Win9x. > --Juan >
Re: rsaenh: fix bug in RSAENH_CPGetProvParam (corrected)
For CRYPT_SEC_DESCR, my previous implementation of the patch tested for it with an "&" as you are suggesting. But, after Alexandre Julliard comment, I no more check the current version of windows and return always CRYPT_SEC_DESCR in RSAENH_CPGetProvParam. So, that's why I put an "==" instead to stick with wine implementation. Well, I think the two views are equivalent even if my first patch containing the version check seemed more logical to me but ,as I am new to wine, I prefer following the advise of more experienced wine developers. Question: are wine tests meant to be run on Windows? This is the only case for the test to fail. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > Hi Mounir, > > +case PP_KEYSTORAGE: > +dwTemp = CRYPT_SEC_DESCR; > > This looks fine.. > > +result = CryptGetProvParam(prov, PP_KEYSTORAGE, (LPBYTE)&dwParam, > &dataLen, 0); > +ok(result && dataLen == sizeof(dwParam) && (dwParam == > CRYPT_SEC_DESCR), > +"Expected CRYPT_SEC_DESCR to be set, got 0x%08X\n",dwParam); > > but this test will now fail on Win9x, yes? > > A simple fix would be to check (dwParam & CRYPT_SEC_DESCR) rather than > (dwParam == CRYPT_SEC_DESCR). > > --Juan > > > > > Don't pick lemons. > See all the new 2007 cars at Yahoo! Autos. > http://autos.yahoo.com/new_cars.html > > >
Re: RSAENH_CPGetProvParam
Actually, the only application I know that uses this expects only CRYPT_SEC_DESCR. So, as you advised, I'll rewrite the patch to remove the version check. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <[EMAIL PROTECTED]> writes: > > >> +case PP_KEYSTORAGE: >> +dwTemp = GetVersion(); >> +/* for Windows NT, 95,98, Me, return CRYPT_PSTORE | >> CRYPT_UI_PROMPT | CRYPT_SEC_DESCR >> + * for the others, return CRYPT_SEC_DESCR >> + */ >> +if(dwTemp < 0x8000 && ((dwTemp & 0x00FF) != >> 0x0004)) >> +dwTemp = CRYPT_SEC_DESCR; >> +else >> +dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; >> > > You shouldn't add such version checks, unless you have a real life app > that depends on the difference. > >
Re: rsaenh: fix critical bug in read_key_container
I'll take you advice from now and I apologize for any annoyance caused by my previous emails. I would also thank all the people who took time to review our patches and sent me their comments/remarks. Regards, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Vitaliy Margolen wrote: > No, that adds more pollution to the place which should not have it. > Please send all patches to [EMAIL PROTECTED] If you think that > all of your patches need work, then don't send them at all. Do this > extra work. And when you have a patch that _you_ think is as good as it > can be, send it to [EMAIL PROTECTED] > > Vitaliy Margolen. >
Re: rsaenh: fix critical bug in read_key_container
yes but I prefer sending patches first to the devel list for comments. Once no major issue is raised, I send it to the patches list. I think this helps prevent polluting the patches list. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Stefan Dösinger wrote: > Hi, > Patches should go to [EMAIL PROTECTED] :-) >
Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
Thanks for your reply. I'm rewriting the patches and sending them back. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Detlef Riekenberg wrote: > I have no Idea about the code, but the missing defines should > be a seperate patch. > > Your idention looks broken. > Wine is using 4 Space, when possible. >
Re: Winscard support (for smart cards)
Hi all, We have noticed that our first patch for winscard containing only the headers have not been applied yet. Is this a normal delay? Is there any pending issues? Should we send the remaining list of patches to complete the winscard implementation? Any comments/remarks are welcomed. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr
rsaenh: fix critical bug in read_key_container
Hi,
We have found a critical bug in rsaenh dll. This bug prevents
CryptAcquireContext from correctly loading the key associated with the
container from the registry, and thus CryptGetUserKey become unusable.
This bug is located in the internal function read_key_container.
Attached with this email is a patch correcting this bug and adding a
test that demonstrate it.
Cheers,
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
>From 8da78d912c0a709a641ae4082ee6df270f644a08 Mon Sep 17 00:00:00 2001
From: Mounir IDRASSI <[EMAIL PROTECTED]>
Date: Mon, 7 May 2007 17:04:46 +0200
Subject: rsaenh: fix critical bug in read_key_container
---
dlls/rsaenh/rsaenh.c | 11 +++
dlls/rsaenh/tests/rsaenh.c | 19 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c
index 2ace2d5..7723157 100644
--- a/dlls/rsaenh/rsaenh.c
+++ b/dlls/rsaenh/rsaenh.c
@@ -1050,6 +1050,7 @@ static HCRYPTPROV read_key_container(PCHAR
pszContainerName, DWORD dwFlags, PVTa
KEYCONTAINER *pKeyContainer;
HCRYPTPROV hKeyContainer;
DATA_BLOB blobIn, blobOut;
+HCRYPTKEY hCryptKey;
sprintf(szRSABase, RSAENH_REGKEY, pszContainerName);
@@ -1089,8 +1090,9 @@ static HCRYPTPROV read_key_container(PCHAR
pszContainerName, DWORD dwFlags, PVTa
if (CryptUnprotectData(&blobIn, NULL, NULL, NULL, NULL,
(dwFlags & CRYPT_MACHINE_KEYSET) ?
CRYPTPROTECT_LOCAL_MACHINE : 0, &blobOut))
{
-RSAENH_CPImportKey(hKeyContainer, blobOut.pbData,
blobOut.cbData, 0, 0,
-
&pKeyContainer->hKeyExchangeKeyPair);
+if(RSAENH_CPImportKey(hKeyContainer, blobOut.pbData,
blobOut.cbData, 0, 0,
+ &hCryptKey))
+ pKeyContainer->hKeyExchangeKeyPair = hCryptKey;
HeapFree(GetProcessHeap(), 0, blobOut.pbData);
}
}
@@ -1113,8 +1115,9 @@ static HCRYPTPROV read_key_container(PCHAR
pszContainerName, DWORD dwFlags, PVTa
if (CryptUnprotectData(&blobIn, NULL, NULL, NULL, NULL,
(dwFlags & CRYPT_MACHINE_KEYSET) ?
CRYPTPROTECT_LOCAL_MACHINE : 0, &blobOut))
{
-RSAENH_CPImportKey(hKeyContainer, blobOut.pbData,
blobOut.cbData, 0, 0,
- &pKeyContainer->hSignatureKeyPair);
+if(RSAENH_CPImportKey(hKeyContainer, blobOut.pbData,
blobOut.cbData, 0, 0,
+ &hCryptKey))
+ pKeyContainer->hSignatureKeyPair = hCryptKey;
HeapFree(GetProcessHeap(), 0, blobOut.pbData);
}
}
diff --git a/dlls/rsaenh/tests/rsaenh.c b/dlls/rsaenh/tests/rsaenh.c
index fe27f4b..0832e0f 100644
--- a/dlls/rsaenh/tests/rsaenh.c
+++ b/dlls/rsaenh/tests/rsaenh.c
@@ -1603,6 +1603,25 @@ static void test_null_provider(void)
CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL,
CRYPT_DELETEKEYSET);
+
+
+/* test for the bug in accessing the user key in a container
+ */
+result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL,
+ CRYPT_NEWKEYSET);
+ok(result, "CryptAcquireContext failed: %08x\n", GetLastError());
+result = CryptGenKey(prov, AT_KEYEXCHANGE, 0, &key);
+ok(result, "CryptGenKey with AT_KEYEXCHANGE failed with error %08x\n",
GetLastError());
+CryptDestroyKey(key);
+CryptReleaseContext(prov,0);
+result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL,0);
+ok(result, "CryptAcquireContext failed: 0x%08x\n", GetLastError());
+result = CryptGetUserKey(prov, AT_KEYEXCHANGE, &key);
+ok (result, "CryptGetUserKey failed with error %08x\n", GetLastError());
+CryptDestroyKey(key);
+
+CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL,
+ CRYPT_DELETEKEYSET);
}
START_TEST(rsaenh)
--
1.4.4.2
crypt32: fix a wrong test
Hi, In the tests of the crypt32 dll, a test was written in a way that accommodates the bug we have corrected previously in the patch for rsaenh dll. The attached small patch corrects the value expected from this test to be consistent with the correct output. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From b2059ab820a37ef3129cd52c4a4048c9081d3bb9 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <[EMAIL PROTECTED]> Date: Mon, 7 May 2007 15:33:36 +0200 Subject: crypt32: fix a wrong test --- dlls/crypt32/tests/cert.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/crypt32/tests/cert.c b/dlls/crypt32/tests/cert.c index 345c9f5..bec65de 100644 --- a/dlls/crypt32/tests/cert.c +++ b/dlls/crypt32/tests/cert.c @@ -1212,7 +1212,7 @@ static void testCreateSelfSignCert(void) "Unexpected key container\n"); ok(!lstrcmpW(info->pwszProvName, MS_DEF_PROV_W), "Unexpected provider\n"); -ok(info->dwKeySpec == AT_SIGNATURE, +ok(info->dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), "Expected AT_SIGNATURE, got %d\n", info->dwKeySpec); } HeapFree(GetProcessHeap(), 0, info); -- 1.4.4.2
Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
Hi,
Thanks Maarte for your comment. Please find attached the patch augmented
with some tests that illustrate what has been corrected.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Maarten Lankhorst wrote:
> I don't see any tests added in this patch so it is hard to verify. Please
> also update dlls/rsaenh/tests with some simple tests if possible, it will
> make it more likely that the code will be accepted.
>
> Cheers,
> Maarte
>From 33a9a1f1573299c9b83c2d699dd4ac31f097a682 Mon Sep 17 00:00:00 2001
From: Mounir IDRASSI <[EMAIL PROTECTED]>
Date: Sun, 6 May 2007 21:36:08 +0200
Subject: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
---
dlls/rsaenh/rsaenh.c | 32 ++-
dlls/rsaenh/tests/rsaenh.c | 61 ---
include/wincrypt.h |5 +++
3 files changed, 92 insertions(+), 6 deletions(-)
diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c
index 2ace2d5..488b90c 100644
--- a/dlls/rsaenh/rsaenh.c
+++ b/dlls/rsaenh/rsaenh.c
@@ -1473,7 +1473,13 @@ BOOL WINAPI RSAENH_CPAcquireContext(HCRYPTPROV *phProv,
LPSTR pszContainer,
SetLastError(NTE_BAD_KEYSET_PARAM);
return FALSE;
} else {
-if (!RegDeleteKeyA(HKEY_CURRENT_USER, szRegKey)) {
+ HKEY hRootKey;
+if (dwFlags & CRYPT_MACHINE_KEYSET)
+hRootKey = HKEY_LOCAL_MACHINE;
+else
+hRootKey = HKEY_CURRENT_USER;
+
+if (!RegDeleteKeyA(hRootKey, szRegKey)) {
SetLastError(ERROR_SUCCESS);
return TRUE;
} else {
@@ -2899,6 +2905,7 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD
dwParam, BYTE *pbData,
switch (dwParam)
{
case PP_CONTAINER:
+case PP_UNIQUE_CONTAINER:/* MSDN says we can return the same value as
PP_CONTAINER */
return copy_param(pbData, pdwDataLen, (CONST
BYTE*)pKeyContainer->szName,
strlen(pKeyContainer->szName)+1);
@@ -2906,6 +2913,29 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv,
DWORD dwParam, BYTE *pbData,
return copy_param(pbData, pdwDataLen, (CONST
BYTE*)pKeyContainer->szProvName,
strlen(pKeyContainer->szProvName)+1);
+case PP_PROVTYPE:
+ dwTemp = PROV_RSA_FULL;
+return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSPEC:
+dwTemp = AT_SIGNATURE | AT_KEYEXCHANGE;
+return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSET_TYPE:
+ dwTemp = pKeyContainer->dwFlags & CRYPT_MACHINE_KEYSET;
+ return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSTORAGE:
+dwTemp = GetVersion();
+/* for Windows NT, 95,98, Me, return CRYPT_PSTORE |
CRYPT_UI_PROMPT | CRYPT_SEC_DESCR
+* for the others, return CRYPT_SEC_DESCR
+*/
+ if(dwTemp < 0x8000 && ((dwTemp & 0x00FF) != 0x0004))
+ dwTemp = CRYPT_SEC_DESCR;
+else
+ dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR;
+ return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
case PP_SIG_KEYSIZE_INC:
case PP_KEYX_KEYSIZE_INC:
dwTemp = 8;
diff --git a/dlls/rsaenh/tests/rsaenh.c b/dlls/rsaenh/tests/rsaenh.c
index fe27f4b..dd7013b 100644
--- a/dlls/rsaenh/tests/rsaenh.c
+++ b/dlls/rsaenh/tests/rsaenh.c
@@ -1480,7 +1480,8 @@ static void test_null_provider(void)
HCRYPTPROV prov;
HCRYPTKEY key;
BOOL result;
-DWORD keySpec, dataLen;
+DWORD keySpec, dataLen,dwParam;
+char szName[MAX_PATH];
result = CryptAcquireContext(NULL, szContainer, NULL, 0, 0);
ok(!result && GetLastError() == NTE_BAD_PROV_TYPE,
@@ -1513,10 +1514,23 @@ static void test_null_provider(void)
CRYPT_VERIFYCONTEXT);
ok(result, "CryptAcquireContext failed: %08x\n", GetLastError());
if (!result) return;
+/* Test provider parameters getter */
+dataLen = sizeof(dwParam);
+result = CryptGetProvParam(prov, PP_PROVTYPE, (LPBYTE)&dwParam, &dataLen,
0);
+ok(result && dataLen == sizeof(dwParam) && dwParam == PROV_RSA_FULL,
+ "Expected PROV_RSA_FULL, got 0x%08X\n",dwParam);
+dataLen = sizeof(dwParam);
+result = CryptGetProvParam(prov, PP_KEYSET_TYPE, (LPBYTE)&dwParam,
&dataLen, 0);
+ok(result && dataLen == sizeof(dwParam) && dwParam == 0,
+ "Expected 0, got 0x%08X\n",dwParam);
+dataLen = sizeof(dwParam);
+res
rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
Hi,
We have found few bugs in the MS Enhanced CSP implementation in wine
(rsaenh.dll) and you'll find attached a patch that corrects them.
Here is a description of the problems we found:
- In RSAENH_CPAcquireContext : when specifying CRYPT_DELETEKEYSET,
the function always deletes the container for the local user, while it
should check the CRYPT_MACHINE_KEYSET flag to see if it should be
deleted on the local machine or for the local user.
- In RSAENH_CPGetProvParam: The following mandatory parameters were
not supported : PP_UNIQUE_CONTAINER, PP_PROVTYPE, PP_KEYSPEC,
PP_KEYSET_TYPE, PP_KEYSTORAGE.
In order to support the PP_KEYSTORAGE parameter, we added three defined
to wincrypt.h.
Cheers,
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
>From a7240539a2e3c83291c7cf206d55f1e4e7e75803 Mon Sep 17 00:00:00 2001
From: Mounir IDRASSI <[EMAIL PROTECTED]>
Date: Sat, 5 May 2007 19:01:57 +0200
Subject: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
---
dlls/rsaenh/rsaenh.c | 32 +++-
include/wincrypt.h |5 +
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c
index 2ace2d5..9f55760 100644
--- a/dlls/rsaenh/rsaenh.c
+++ b/dlls/rsaenh/rsaenh.c
@@ -1473,7 +1473,13 @@ BOOL WINAPI RSAENH_CPAcquireContext(HCRYPTPROV *phProv,
LPSTR pszContainer,
SetLastError(NTE_BAD_KEYSET_PARAM);
return FALSE;
} else {
-if (!RegDeleteKeyA(HKEY_CURRENT_USER, szRegKey)) {
+ HKEY hRootKey;
+if (dwFlags & CRYPT_MACHINE_KEYSET)
+hRootKey = HKEY_LOCAL_MACHINE;
+else
+hRootKey = HKEY_CURRENT_USER;
+
+if (!RegDeleteKeyA(hRootKey, szRegKey)) {
SetLastError(ERROR_SUCCESS);
return TRUE;
} else {
@@ -2899,6 +2905,7 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD
dwParam, BYTE *pbData,
switch (dwParam)
{
case PP_CONTAINER:
+case PP_UNIQUE_CONTAINER:/* MSDN says we can return the same value as
PP_CONTAINER */
return copy_param(pbData, pdwDataLen, (CONST
BYTE*)pKeyContainer->szName,
strlen(pKeyContainer->szName)+1);
@@ -2915,6 +2922,29 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv,
DWORD dwParam, BYTE *pbData,
dwTemp = CRYPT_IMPL_SOFTWARE;
return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+case PP_PROVTYPE:
+ dwTemp = PROV_RSA_FULL;
+return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSPEC:
+dwTemp = AT_SIGNATURE | AT_KEYEXCHANGE;
+return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSET_TYPE:
+ dwTemp = pKeyContainer->dwFlags & CRYPT_MACHINE_KEYSET;
+ return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
+case PP_KEYSTORAGE:
+dwTemp = GetVersion();
+/* for Windows NT, 95,98, Me, return CRYPT_PSTORE |
CRYPT_UI_PROMPT | CRYPT_SEC_DESCR
+* for the others, return CRYPT_SEC_DESCR
+*/
+ if(dwTemp < 0x8000 && ((dwTemp & 0x00FF) != 0x0004))
+ dwTemp = CRYPT_SEC_DESCR;
+else
+ dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR;
+ return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
+
case PP_VERSION:
dwTemp = 0x0200;
return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp,
sizeof(dwTemp));
diff --git a/include/wincrypt.h b/include/wincrypt.h
index 2219bd5..c897e96 100644
--- a/include/wincrypt.h
+++ b/include/wincrypt.h
@@ -1613,6 +1613,11 @@ static const WCHAR MS_SCARD_PROV_W[] = {
'M','i','c','r','o','s','o','
#define PP_KEYSPEC 39
#define PP_ENUMEX_SIGNING_PROT 40
+/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */
+#define CRYPT_SEC_DESCR 0x0001
+#define CRYPT_PSTORE0x0002
+#define CRYPT_UI_PROMPT 0x0004
+
/* Crypt{Get/Set}KeyParam */
#define KP_IV 1
#define KP_SALT 2
--
1.4.4.2
Bug in Advapi32: CryptEnumProviderTypesA and CryptEnumProvidersA
Hi,
During our tests of wine with our cryptographic suite, we have found a
bug in the functions CryptEnumProviderTypesA and CryptEnumProvidersA in
advapi32 dll: In case of failure, they both report a wrong last error
through GetLastError.
We have found and corrected the source of the bug: They both call their
wide-char counterpart but they don't test the success of this call.
The correction is simple: add an if statement and return immediately in
case of error. I have attached a small patch with our correction.
Should we fill a bugzilla report before submitting the patch?
Thanks.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
>From ab7323952138e725700ded1bad4afd17e42717e7 Mon Sep 17 00:00:00 2001
From: Mounir IDRASSI <[EMAIL PROTECTED]>
Date: Wed, 2 May 2007 20:20:59 +0200
Subject: Correct bug in CryptEnumProviderTypesA and CryptEnumProvidersA: They
report wrong last error in case of failure
---
dlls/advapi32/crypt.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c
index 1fd16c3..a7273b9 100644
--- a/dlls/advapi32/crypt.c
+++ b/dlls/advapi32/crypt.c
@@ -1139,7 +1139,8 @@ BOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved,
TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags,
pdwProvType, pszProvName, pcbProvName);
- CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL,
&strlen);
+ if(!CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType,
NULL, &strlen))
+ return FALSE;
if ( pszProvName && !(str = CRYPT_Alloc(strlen)) )
{
SetLastError(ERROR_NOT_ENOUGH_MEMORY);
@@ -1267,7 +1268,8 @@ BOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved,
TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags,
pdwProvType, pszTypeName, pcbTypeName);
- CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType,
NULL, &strlen);
+ if(!CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType,
NULL, &strlen))
+ return FALSE;
if ( pszTypeName && !(str = CRYPT_Alloc(strlen)) )
{
SetLastError(ERROR_NOT_ENOUGH_MEMORY);
--
1.4.4.2
Re: Adding header files for the implementation of Winscard dll (Smart Cards support)
Sorry, my mistake... I'll definitely be more careful next time. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Dmitry Timoshkov wrote: > This is a notice more for Alexandre this time, but next time please > make sure to send the files with exec bits turned off (755 -> 644). >
Re: Winscard support (for smart cards)
Hi, Please find attached the patch for adding header files for the support of smart cards through Winscard dll. If it's OK, should I post it elsewhere? Thanks in advance. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > > sorry, I didn't actually compare the files, just saw the comments (my > bad) > that'll be better for the first patch not to include those C files > go ahead ;-) > A+ > From 90fb2bc92327fc839d6a0ef68c3157035cd50c65 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <[EMAIL PROTECTED]> Date: Tue, 1 May 2007 18:03:01 +0200 Subject: Header files for the support of smart cards using Winscard dll --- include/Makefile.in |3 + include/scarderr.h | 70 + include/winscard.h | 416 +++ include/winsmcrd.h | 190 +++ 4 files changed, 679 insertions(+), 0 deletions(-) diff --git a/include/Makefile.in b/include/Makefile.in index 2577872..7dc0cc3 100644 --- a/include/Makefile.in +++ b/include/Makefile.in @@ -293,6 +293,7 @@ SRCDIR_INCLUDES = \ rpcndr.h \ rpcnterr.h \ rpcproxy.h \ + scarderr.h \ schannel.h \ schemadef.h \ schnlsp.h \ @@ -351,6 +352,8 @@ SRCDIR_INCLUDES = \ winreg.h \ winres.h \ winresrc.h \ + winscard.h \ + winsmcrd.h \ winsock.h \ winsock2.h \ winspool.h \ diff --git a/include/scarderr.h b/include/scarderr.h new file mode 100755 index 000..c07833e --- /dev/null +++ b/include/scarderr.h @@ -0,0 +1,70 @@ +/* + * Copyright 2007 Mounir IDRASSI ([EMAIL PROTECTED], for IDRIX) + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + + +#ifndef _WINE_SCARDERR_H +#define _WINE_SCARDERR_H + + +#define SCARD_S_SUCCESS0x +#define SCARD_F_INTERNAL_ERROR 0x8011 /* An internal error occured while executing the operation */ +#define SCARD_E_CANCELLED 0x8012 /* SCardCancel was called to cancel the operation */ +#define SCARD_E_INVALID_HANDLE 0x8013 /* The given handle is not valid */ +#define SCARD_E_INVALID_PARAMETER 0x8014 /* An invalid parameter was given in input*/ +#define SCARD_E_INVALID_TARGET 0x8015 /* Smart card service encountered inconsistent installation information */ +#define SCARD_E_NO_MEMORY 0x8016 /* No enough memory available to complete the operation */ +#define SCARD_F_WAITED_TOO_LONG0x8017 /* A timeout occured in an internal operation */ +#define SCARD_E_INSUFFICIENT_BUFFER0x8018 /* The output buffer is too small to receive data */ +#define SCARD_E_UNKNOWN_READER 0x8019 /* The given reader name is unknwon to the system */ +#define SCARD_E_TIMEOUT0x801A /* The operation timed out */ +#define SCARD_E_SHARING_VIOLATION 0x801B /* can't access the card because of other connections*/ + +#ifndef SCARD_E_NO_SMARTCARD +#define SCARD_E_NO_SMARTCARD 0x801C /* no smart card found on the reader*/ +#endif + +#define SCARD_E_UNKNOWN_CARD 0x801D /* The given card name is unknwon to the ssytem */ +#define SCARD_E_CANT_DISPOSE 0x801E /* The system can't handle the disposition request in SCardDisconnect or SCardEndTransaction*/ +#define SCARD_E_PROTO_MISMATCH 0x801F /* The given protocol is not compatible with the currenr card context */ +#define SCARD_E_NOT_READY 0x80100010 /* The reader or the card are not ready for use */ +#define SCARD_E_INVALID_VALUE 0x80100011 /* An invalid value was detected while */ +#define SCARD_E_SYSTEM_CANCELLED 0x80100012 /* The system canceld the current operation with the reader */ +#define SCARD_F_COMM_ERROR 0x80100013 /* A communication error occured with the reader */ +#define SCARD_F_UNKNOWN_ERROR 0x80100014 /* An unknown error occured */ +#define SCARD_E_INVALID_ATR
Re: Winscard support (for smart cards)
Hi Eric, I am afraid I don't see any MS comments in scarderr.h: I have written all the file from scratch and the comments are mine. Can you point them out please? In the final implementation, all the functions are needed even if they are stubs because they can be called by applications that ignore them if they report an error. That's why we must implement them all. But I can start with stubs in the spec file for the first patch. I'll wait for your reply before submitting the first patch. Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > thanks for your work > > I still have a couple of comments: > - you don't need at first (for the skeletton) to provide an empty > implementation for a given function. If you use the stub keyword in > the .spec file, Wine will create a minimal stub for the function > (that'll make the program crash when it's called), but is sufficient > when the API is never called => this is the preferred way to go. All > your stubs are not lost, you'll reuse them when providing the first > API implementation > - basically, I'd submit a patch for the headers and a second one for > the skeletton of the DLL. Then you can go on with the various API > implementations > > From the coding itself: > - in traces, don't cast handles to int, it won't work every where... > rather use "%x", handle => that's portable > - there's still (void) functions declared as () (in the C files) > - there's still MS comments in scarderr.h > > A+ >
Re: Winscard support (for smart cards)
oups ...sorry...It was my fault! You are as absolutely right. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > they should work across the whole buffer > are you sure you don't pass -1 as the length for the input buffer ? > A+ >
Re: Winscard support (for smart cards)
Hi Eric,
I have tested your hint concerning the final single call to
MultiByteToWideChar in order to convert the whole area but it didn't
work: even when I specify the whole length of the multi-string, it keeps
stoping at the first NULL character. I guess MultiByteToWideChar and
WideCharToMultiString don't understand multi-strings ( MSDN say nothing
about that).
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Eric Pouech wrote:
> you have to ensure that binary compat is present for both pcsc-lite
> and MS APIs
> if not, then you'll have to convert back and forth the non "portable"
> types
> actually, we don't provide exported variables when those are used from
> a native module (those would work from a builtin module though)
> if you really need to access them from a builtin module you have to:
> - define a pointer to this (exported) variable
> - get the address of this variable:
> GetProcAddress(GetModuleHandle("modname.dll"), "varname")
> - access the variable through the pointer
>
> A+
>
Re: Winscard support (for smart cards)
Hi , Thank you for all your comments. Concerning the header files, they contain portions taken from Microsoft headers. We will rewrite them to remove any copyright issues. For the types used, they are more close to pcsc-lite than Microsoft but still compatible at the binary level. We will modify them to be more close to MS SDK definitions. We understand the issue of having a big patch. I'll split it into small parts as you advised. The same applies to winscard.c file. Concerning the exported variables, we think we have followed the msvcrt example: "@ extern name" in the spec file and the declaration in a c file. The variables exported are visible from win32 programs and are used without any problem. However, there is still an issue: when when try to compile a source file that uses them using winegcc, we get an unresolved symbol error. Did we miss something? The only difference we see with msvcrt source is that winscard exported variables have a structure as a type, whereas msvcrt exported variables are pointers. Cheers, Mounir IDRASSI IDRIX – Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > from a cursory look, it looks a very goot start !!! > > a couple of comments though: > - some functions are declared (), they should be (void) (it's C, not C++) > - wstrlen already exists: it's strlenW (even if we don't check for > NULL strings) > - don't use malloc/free but rather HeapAllocate... in windows, malloc > boils down to HeapAllocate through msvcrt, but in Wine it uses the > glibc one, which is not what you want > - ConvertListToANSI: IMO, after computing the final length, only a > single call to MultiByteToWideChar is necessary (it will convert the > whole area) > - ditto for ConvertListToWideChar > - headers: >+ the rule for including new headers in Wine is really to have them > fully retyped... looking at the comments in the file, it looks to me > you mostly copied the existing headers and their comments as well >+ some types are not the correct ones (at least on my latest SDK) > => e.g. you use long for SCARDCONTEXT whereas it's defined as a > ULONG_PTR (it will not correctly work when compiling on a 64bit > machine) (I'm not saying that your code must be 64 compliant at first, > but the headers must be) > - spec file: >+ don't define an entry point if you don't absolutely need it (most > of them should still be stubs) > - you still use C++ comments, whereas Wine only allows C comments > > from the inclusion into Wine, it's already way to big to be included > in a single operation. So, you should split up your work in smaller > pieces. For example: > - patch #1-3: new header files > - patch #4: bare DLL infrastructure (mostly .spec file (only stubs), > Makefile.in and .c file with DllMain, configure.ac) > - patch #5: a small set of functions XXX (c file, modified .spec file) > - patch #6: a small set of functions YYY (c file, modified .spec file) > > it would be also interesting to think about having several c files for > the DLL (given the number of APIs to implement) > > finally, it seems that the DLL exports some variables => they have to > be specially handled (see details on how to do it in some other DLLs, > like msvcrt) > > A+ >
Re: Winscard support (for smart cards)
Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > IMHO it would be best for the community if you will start doing > this immediatelly, not once done. Unfortunately, we are well advanced and we can't do it that way due to other constraints in the project. Another bad point is that, since we are not really experts in autoconf and libtool scripts, we started from a pre-configured source tree and adapted the files of the cryptdll library (the simplest one). So we will definitely need the help of the community to integrate our source seamlessly into the wine source tree. Mounir IDRASSI IDRIX - Cryptography And IT Security Experts http://www.idrix.fr
Winscard support (for smart cards)
Hi, We have noticed that wine doesn't have the winscard dll responsible for the support of smart cards under windows. For the need of one of our projects, we are currently developing this dll for wine under Linux based on the pcsc-lite library. Once done, we'll share it with the community. However, we would like to known the reason behind the lack of winscard support. Is it simply because no one needed it before or maybe there is an issue with the pcsc-lite license? Thanks in advance for your information. Cheers, Mounir IDRASSI IDRIX http://www.idrix.fr
