Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2276
Your paranoid andr
On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang wrote:
> Ah. Thanks for following the existing style then :-/ No, don't bother
> changing the existing code. I leave it up to you whether to follow my
> suggestion or ignore it, either is fine in this case.
Patch sent, thanks Juan Lang and Daniel Jelińs
On Fri, Jun 28, 2013 at 9:16 AM, Qian Hong wrote:
> Dear Juan,
>
> Thanks for reviewing!
>
> On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> > It's more in line with most C code to use !memcmp(...) instead of
> > memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to
> !
>
Dear Juan,
Thanks for reviewing!
On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> It's more in line with most C code to use !memcmp(...) instead of
> memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to !
> comparisons to check equality in memcmp, strcmp, and variants.
>
Hi Qian,
On Fri, Jun 28, 2013 at 3:44 AM, Qian Hong wrote:
> Hi Daniel, new patches sent with improving from your hints, would you
> mind have a look? Thanks in advance!
>
nice work! These look fine to me, but a stylistic nit:
+
ok(memcmp(pbData,cTestData[i].decstr,cTestData[1].enclen)==0,"dec
Hi Daniel, new patches sent with improving from your hints, would you
mind have a look? Thanks in advance!
Hi Daniel,
On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński wrote:
> I'm not convinced that a failed call to CryptDecrypt actually resets
> the key state. It's also possible that CryptDecrypt returns FALSE
> before even trying to decrypt if data length is invalid. To check it,
> you would need to
ch
>> you do not restore before calling the function again.
>
> Thanks a lot of the hint, with your help I finally resolve it! I've
> improved my test and submit two rsaenh patches, would you mind help to
> review them?
>
> Thanks again!
>
>
> --
> Regards,
> Qian Hong
>
> -
> http://www.winehq.org
>
ith Final =
> TRUE should return the same result.
>
> Your testcase fails because CryptDecrypt changes the value of dwLen, which
> you do not restore before calling the function again.
Thanks a lot of the hint, with your help I finally resolve it! I've
improved my test and submit two
It is definitely valid to call CryptDecrypt multiple times with the same
key. Calls with Final = FALSE change the internal state of the key, calls
with Final = TRUE restore the initial state. Subsequent calls with Final =
TRUE should return the same result.
Your testcase fails because CryptDecrypt
Hello,
I was investigating Bug 33898 [1] hardly and get a partial result, I
have a special test case demonstrate the behavior of Aliwangwang [2],
however, I failed to expand the special case to a common test case. My
attempting is shown in [3]. The hack in [3] works for Aliwangwang, but
the test c
etLastError());
> +todo_wine ok(broken(!result && GetLastError() == NTE_BAD_KEY) ||
> result /* Win7 */,
> + "CryptGetKeyParam failed, got %08x\n", GetLastError());
>
> Why don't you fix rsaenh while you're at it? It'd be an
; GetLastError() == NTE_BAD_KEY) ||
result /* Win7 */,
+ "CryptGetKeyParam failed, got %08x\n", GetLastError());
Why don't you fix rsaenh while you're at it? It'd be an exceedingly
easy patch. Look for KP_SALT in rsaenh.c, and you'll see what I mean.
--Juan
> ULL constants are not portable and should be avoided.
Ah, right. Sorry, I only glanced at the source after checking the
license. I'll fix and resend (and have a closer look.)
--Juan
Juan Lang writes:
> +/* Hash constant words K for SHA-384 and SHA-512: */
> +const static sha2_word64 K512[80] = {
> + 0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
> + 0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL,
ULL constants are not portable and should be avoided.
--
Alexandre Jull
> Is the patch missing some files?
Damn, yes. I thought "git am" would be clever enough to handle that,
but apparently not. Thanks.
--Juan
On 8 March 2010 22:36, Juan Lang wrote:
> Uses implementation from Aaron Gifford,
> http://www.aarongifford.com/computers/sha.html (It's BSD licensed.)
>
Is the patch missing some files?
Michael Stefaniuc [mailto:mstef...@redhat.com]
> > But we are already returning a few lines above:
> >
> > 271 result = CryptCreateHash(hProv, CALG_MD2, 0, 0, &hHash);
> > 272 if (!result) {
> > 273 /* rsaenh compiled without OpenSSL *
up.
>>>>>
>>>>> Found with the help of Coccinelle and the CocciCheck scripts.
>>>>>
>>>>> Changelog
>>>>> Don't check result twice (Coccinelle)
>>>>>
>>>> --- a/dlls/rsaenh/tests/rsaenh.c
check result twice (Coccinelle)
--- a/dlls/rsaenh/tests/rsaenh.c
+++ b/dlls/rsaenh/tests/rsaenh.c
@@ -275,7 +275,6 @@ static BOOL derive_key(ALG_ID aiAlgid, HCRYPTKEY
*phKey, DWORD len)
return FALSE;
}
ok(result, "%08x\n", GetLastError());
-if (!resul
Changelog
>>> Don't check result twice (Coccinelle)
>>>
>> --- a/dlls/rsaenh/tests/rsaenh.c
>> +++ b/dlls/rsaenh/tests/rsaenh.c
>> @@ -275,7 +275,6 @@ static BOOL derive_key(ALG_ID aiAlgid, HCRYPTKEY
>> *phKey, DWORD len)
>>
On 01/12/2010 02:32 PM, Michael Stefaniuc wrote:
Hi Paul,
Paul Vriens wrote:
We already check and return FALSE a few lines up.
Found with the help of Coccinelle and the CocciCheck scripts.
Changelog
Don't check result twice (Coccinelle)
--- a/dlls/rsaenh/tests/rsaenh.c
+++ b/dlls/r
Hi Paul,
Paul Vriens wrote:
> We already check and return FALSE a few lines up.
>
> Found with the help of Coccinelle and the CocciCheck scripts.
>
> Changelog
> Don't check result twice (Coccinelle)
>
--- a/dlls/rsaenh/tests/rsaenh.c
+++ b/dlls/rsaenh/tests
On 11/05/2009 07:11 PM, Juan Lang wrote:
--Juan
Hi Juan,
This one introduces some test failures on Win9x and WinMe:
http://test.winehq.org/data/tests/rsaenh:rsaenh.html
Could you have a look?
--
Cheers,
Paul.
> It fails for me:
The trouble is, the test is invalid. It imports a key using
CRYPT_IPSEC_HMAC_KEY, which Wine currently ignores. rsaenh currently
doesn't implement HMAC. The chromium tests, on which this test case
was built, also checks the resulting output from using this key,
Juan Lang writes:
>> It fails for me:
>>
>> ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p
>> advapi32_test.exe.so crypt.c && touch crypt.ok
>> crypt.c:972: Test failed: CryptImportKey error 2148073481
>> make: *** [crypt.ok] Error 1
>
> Odd. On a clean wineprefix, I presume?
> It fails for me:
>
> ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p
> advapi32_test.exe.so crypt.c && touch crypt.ok
> crypt.c:972: Test failed: CryptImportKey error 2148073481
> make: *** [crypt.ok] Error 1
Odd. On a clean wineprefix, I presume?
--Juan
Juan Lang writes:
> Commit d3c482250a8232e9657ecefb3e61fff0194e3fbe added a test that
> showed that the default provider should accept RC2 keys of up to 128
> bits in length. The trouble is the fix was wrong: the default
> provider in Wine was the base cryptographic provider, but it has been
>
On Tuesday 13 October 2009 08:46:59 am Dmitry Timoshkov wrote:
> +ret = pCryptImportKey(provider, (BYTE*)&key_blob,
> + sizeof(BLOBHEADER)+sizeof(DWORD)+key_length,
> + 0, CRYPT_IPSEC_HMAC_KEY, &hkey);
> +ok(ret, "CryptImportKey error %u\n", GetLas
Francois Gouget wrote:
> The bug is with -O3 which is not the default and which I would not
> personally care about. I'd be more open about maintenance issues.
>
My inclination would be to make the functions static. However, how to handle
the comments is an issue to consider. Also, I probably ma
On Sat, 23 May 2009, Andrew Talbot wrote:
[...]
> I made a few of the functions in mpi.c static a while back, but stopped when
> there was a bug report (http://bugs.winehq.org/show_bug.cgi?id=17406)
> that seemed consequential but turned out to be apparently due to a bug gcc.
The bug is with -O3 w
Francois Gouget wrote:
>
> So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So
> they could be made static by tweaking mpi.c and tomcrypt.h.
>
> However my understanding is that this files has been imported in Wine
> from another project so maybe it&#x
So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So
they could be made static by tweaking mpi.c and tomcrypt.h.
However my understanding is that this files has been imported in Wine
from another project so maybe it's not a good idea to diverge much from
them.
What d
Usually i don't feel the need to respond to messages on wine-devel, but now i
do:
> What in the hell does this patch do? Why is it needed? What does it
> fix/implement? Doees this change affect any Bugzilla issues? Where is
> the Changelog?
> This is what I have been trying to get you to do.
James, please show a little more courtesy.
> Who is this and why is this so important?
Karsten wrote a patch to address an issue he had with Eve Online.
It's important because of attribution: I wanted people to realize
that I was indebted to him for thinking of it. I didn't use his code,
though
Juan Lang wrote:
> Inspired by a patch by Karsten Elfenbein.
>
Who is this and why is this so important?
> --Juan
>
Per:
http://winehq.org/site/sending_patches
What in the hell does this patch do? Why is it needed? What does it
fix/implement? Doees this change affect any Bugzilla issues?
> Did you mean to test that block twice?
Good question, and yes. I wanted to test it with at least two
different keys/algorithms, to make sure the restrictions were not
particular to any algorithm.
--Juan
On Mon, Jul 28, 2008 at 9:58 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> Inspired by a patch by Karsten Elfenbein.
+/* What sizes salt can I set? */
+salt.pbData = pbData;
+for (i=0; i<24; i++)
+{
+salt.cbData = i;
+result = CryptSetKeyParam(h
-/* salt length can't be greater than 128 bits = 16 bytes */
-if (blob->cbData > 16)
-{
-SetLastError(ERROR_INVALID_PARAMETER);
-return FALSE;
-}
memcpy(pCryptKey->abKeyValue + pCryptKey->dwKeyLen, blob->pb
Hi,
Please let me know why this patch has been rejected.
http://www.winehq.org/pipermail/wine-patches/2008-February/049817.html
It seems this patch has gone completely unnoticed.
Please Comment.
Somehow, my patches are not getting commited/reviewed.
Did I do anything wrong, please do tell me.
On Nov 20, 2007 4:29 PM, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
> Damn, I have to reset the git tree.
> Then apply patches manually and resend them :(
> Should I wait.? :(
> ---
> VJ
>
You should be able to join the commits with git-rebase then regenerate
the patches.
--
> Damn, I have to reset the git tree.
> Then apply patches manually and resend them :(
This isn't hard. Assuming you have these as the last three patches in
your tree:
git reset HEAD~2
git commit -a
This will rewind your tree two steps without changing your local
files, then commit them again.
T
On Nov 20, 2007 4:23 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> > The test fail due to missing implementation, Hence I put them in todo's.
> > After the implementation is there, they do not fail.
> > I think thats the procedure followed.
> > I have put the remove todo's in separate patch, as its la
> The test fail due to missing implementation, Hence I put them in todo's.
> After the implementation is there, they do not fail.
> I think thats the procedure followed.
> I have put the remove todo's in separate patch, as its large.
James is correct, patches 2 and 3 should be concatenated. 2 is
On Nov 20, 2007 3:57 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
>
> On 11/20/07, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > This is a description of patch series which I am now going to send.
> > It adds the new Enhanced RSA AES provi
On 11/20/07, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is a description of patch series which I am now going to send.
> It adds the new Enhanced RSA AES provider to the rsaenh.
> The one application which I know uses it is Office 2007.
> The first patc
todo_wine, it looks loke a hack
> > and its ugly
> > As that function is used alot.
> >
> > ---
> > VJ
> >
> > On Nov 16, 2007 5:45 PM, Reece Dunn <[EMAIL PROTECTED]> wrote:
> >>
> >> On 16/11/2007, Vijay Kiran Kamuju <[EMAIL P
-
> VJ
>
> On Nov 16, 2007 5:45 PM, Reece Dunn <[EMAIL PROTECTED]> wrote:
>>
>> On 16/11/2007, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
>>> ChangeLog
>>> --
>>> Add tests for RSA_AES provider in rsaenh
>>>
>>&
EMAIL PROTECTED]> wrote:
> > ChangeLog
> > --
> > Add tests for RSA_AES provider in rsaenh
> >
> > Note:
> > ---
> > Some tests might fail as there is no RSA_AES provider in wine.
> > These will be fixed once the implementation is in plac
On 16/11/2007, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
> ChangeLog
> --
> Add tests for RSA_AES provider in rsaenh
>
> Note:
> ---
> Some tests might fail as there is no RSA_AES provider in wine.
> These will be fixed once the implementation is
Mounir IDRASSI schreef:
> 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 sta
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_VERIFYCONTE
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> 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
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 comple
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 unfortuna
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> From: Mounir IDRASSI <[EMAIL PROTECTED]>
> Date: Wed, 9 May 2007 03:33:45 +0200
> Subject: rsaenh: fix bug in RSAENH_CPGetProvParam
Could you please provide a more meaningful subject line to describe
your patch? "fix bug&qu
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
>
Hi again Mounir,
> 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
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
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 t
On Mo, 2007-05-07 at 18:29 +0200, Mounir IDRASSI wrote:
> 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
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
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 PR
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,
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.
>
Hi,
Patches should go to [EMAIL PROTECTED] :-)
pgpiFsHZzRqcO.pgp
Description: PGP signature
On Sa, 2007-05-05 at 19:16 +0200, Mounir IDRASSI wrote:
> --- a/include/wincrypt.h
> +++ b/include/wincrypt.h
> +/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */
> +#define CRYPT_SEC_DESCR 0x0001
> +#define CRYPT_PSTORE0x0002
> +#define CRYPT_UI_PROMPT
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 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 <[E
dd
tests to verify the behavior is correct. 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,
Maarten
<[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
* test for importing a PlainPublicKey
* test for the correct ALG_ID after the import
* test for the correct PlainPublicKey after exporting the key again
Karsten
rsa1.diff
Description: Binary data
On Friday 15 September 2006 14:01, Paul Vriens wrote:
> The tests run as of XP (so XP and W2K3, Vista?)
Ah, good to know, thanks.
Kai
--
Kai Blin,
WorldForge developerhttp://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.
pgpeKdpUTaFS
On Fri, 2006-09-15 at 13:25 +0200, Kai Blin wrote:
> On Friday 15 September 2006 09:16, Hans Leidekker wrote:
> > On Thursday 14 September 2006 20:57, Kai Blin wrote:
> > > What windows version is that? I checked on Win2k and the tests wouldn't
> > > execute. tests.winehq.org/data/ doesn't show the
On Friday 15 September 2006 09:16, Hans Leidekker wrote:
> On Thursday 14 September 2006 20:57, Kai Blin wrote:
> > What windows version is that? I checked on Win2k and the tests wouldn't
> > execute. tests.winehq.org/data/ doesn't show them running either.
>
> I tested on WinXP. Did you get any er
On Thursday 14 September 2006 20:57, Kai Blin wrote:
> What windows version is that? I checked on Win2k and the tests wouldn't
> execute. tests.winehq.org/data/ doesn't show them running either.
I tested on WinXP. Did you get any error message?
-Hans
On Thursday 14 September 2006 13:33, Hans Leidekker wrote:
> On Thursday 14 September 2006 11:13, Kai Blin wrote:
> > MD4_CTX and MD5_CTX have the same elements, declare them in the same
> > order.
>
> Tell Microsoft about it ;-) Your patch breaks the md5 test on Windows
> because it depends on the
On Thursday 14 September 2006 11:13, Kai Blin wrote:
> MD4_CTX and MD5_CTX have the same elements, declare them in the same order.
Tell Microsoft about it ;-) Your patch breaks the md5 test on Windows
because it depends on the struct layout:
crypt_md5.c:90: Test failed: invalid initialization
cr
Hi Karl,
Send a copy of both the patches to wine-patches also.
Thanks,
VJ
On 7/25/06, Karsten Elfenbein <[EMAIL PROTECTED]> wrote:
Hi,
Same question for this one.
It fixes the case when CryptGetHashParam is called with pbData=NULL to
determine
the needed buffer size for the hash value.
It f
sten
rsaenh-gethashparam.diff
Description: Binary data
.cgi?id=5639
Karsten
rsaenh-cpencrypt.diff
Description: Binary data
Tom wrote:
Michael Stefaniuc wrote:
Jonathan Ernst wrote:
Le mercredi 23 fÃvrier 2005 Ã 13:50 +0100, Michael Jung a Ãcrit :
Ok, that makes rsabase a really trivial dll. Please remove
dlls/rsabase/main.c from cvs (Is there any way to capture this in a
diff?)
diff -u dlls/rsabase/main.c /dev/null
Michael Stefaniuc wrote:
Jonathan Ernst wrote:
Le mercredi 23 fÃvrier 2005 Ã 13:50 +0100, Michael Jung a Ãcrit :
Ok, that makes rsabase a really trivial dll. Please remove
dlls/rsabase/main.c from cvs (Is there any way to capture this in a
diff?)
diff -u dlls/rsabase/main.c /dev/null >> rsabase.
Michael Stefaniuc <[EMAIL PROTECTED]> writes:
> Jonathan Ernst wrote:
>> Le mercredi 23 février 2005 à 13:50 +0100, Michael Jung a écrit :
>>
>>> Ok, that makes rsabase a really trivial dll. Please remove
>>> dlls/rsabase/main.c from cvs (Is there any way to capture this in a
>>> diff?)
>> diff -u
Jonathan Ernst wrote:
Le mercredi 23 fÃvrier 2005 Ã 13:50 +0100, Michael Jung a Ãcrit :
Ok, that makes rsabase a really trivial dll. Please remove dlls/rsabase/main.c
from cvs (Is there any way to capture this in a diff?)
diff -u dlls/rsabase/main.c /dev/null >> rsabase.diff
Not realy as this emp
Le mercredi 23 fÃvrier 2005 Ã 13:50 +0100, Michael Jung a Ãcrit :
> Ok, that makes rsabase a really trivial dll. Please remove
> dlls/rsabase/main.c
> from cvs (Is there any way to capture this in a diff?)
diff -u dlls/rsabase/main.c /dev/null >> rsabase.diff
signature.asc
Description: Ceci e
Michael Jung <[EMAIL PROTECTED]> writes:
> As suggested by Alexandre, I removed all implementation code from rsabase and
> made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's
> unicows.dll to do so.
You don't need that, you can for
On Sunday 20 February 2005 20:21, Paul Vriens wrote:
> It looks like RSAENH_CPReleaseContext released 'everything' where it
> shouldn't, hence the failure of CryptDestroyHash.
I will have a look into it, but probably won't have the time to do so before
next weekend.
Ciao,
--
Michael Jung
[EMAIL
Hi,
I've download a bunch of demo-apps and this one
(http://www.gamershell.com/news/10306.html) has some problems with the
builtin rsaenh.dll/advapi32.dll. The trace (+crypt,+loaddll) shows:
fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e39320): not verifying image
trace:crypt:RSAENH_CPAcquireCo
Michael Jung <[EMAIL PROTECTED]> writes:
> On Wednesday 09 February 2005 13:38, Alexandre Julliard wrote:
> > The test fails for me:
> >
> > rsaenh.c:1383: Test failed: 0103
> > rsaenh.c:1391: Test failed: 0, 0103
>
> It doesn't fail for me on a clean .wine directory and a fresh wine cvs
d version of the patch with some added
tracing code. If you find a minute, could you please try it and send me a
'crypt' debug channel trace? Do not apply this patch to cvs, please.
Thanks,
--
Michael Jung
[EMAIL PROTEC
Michael Jung <[EMAIL PROTECTED]> writes:
> Changelog:
> Implemented CPGetProvParam's PP_ENUMCONTAINERS parameter type
> Added corresponding test
> Removed some tabs that slipped in with the last patch
The test fails for me:
rsaenh.c:1383: Test failed: 0103
rsaenh.c:1391: Test failed: 0, 0
Michael Jung <[EMAIL PROTECTED]> writes:
> Changelog:
> Support for TLS1 pseudo random function
> Some helper functions for DATA_BLOB's
> Computing TLS1 master secret from the pre-master secret
> Deriving the master hash from the master secret
> Deriving TLS1 MAC and encryption keys from the
On Fri, Dec 03, 2004 at 11:49:22AM +0100, Michael Jung wrote:
> Greetings,
> Michael
>
> Changelog:
> Added a missing break in encrypt_block_impl
>
> Index: dlls/rsaenh/implglue.c
JFYI,
we (Novell) are now working on reapproving WINE for US
export due to your cryptog
Michael Jung <[EMAIL PROTECTED]> writes:
> The attached program produces the following output on my WinXP SP2:
>
> Loaded rsaenh.dll successfully!
> Got CPAcquireContext address!
> Success! Last error:
Cool, thanks for taking the time to do this. I'll put the patch in.
--
Alexandre Ju
possibilities:
> > 1.) It's done in rsaenh. Then we are ok.
> > 2.) It's done in advapi32: Then it doesn't matter if we already have set
> > it in rsaenh, because it will be overwritten.
>
> But if Windows doesn't set it in rsaenh, then we are just hidi
Michael Jung <[EMAIL PROTECTED]> writes:
> I agree that if this is done on Windows in advapi32, we have to do it there,
> too. What I meant to say was the following:
>
> There are basically two possibilities:
> 1.) It's done in rsaenh. Then we are ok.
> 2.) I
is if this should be set in
> > advapi32/CryptAcquireContext or in rsaenh/CPAcquireContext. However,
> > setting it in rsaenh can do no harm.
>
> Famous last words... It definitely matters where it's done, because we
> can use various native/builtin combinations, so we h
Michael Jung <[EMAIL PROTECTED]> writes:
> The test is in dlls/advapi32/tests/crypt.c, line 117. It passes at least on
> WinXP SP2.
OK great, I missed that one.
> What I don't know is if this should be set in
> advapi32/CryptAcquireContext or in rsaenh/CPAcquireContext.
have a test demonstrating that Windows does it in this case?
The test is in dlls/advapi32/tests/crypt.c, line 117. It passes at least on
WinXP SP2. What I don't know is if this should be set in
advapi32/CryptAcquireContext or in rsaenh/CPAcquireContext. However, setting
it in rsaenh can do no harm.
Greetings,
Michael
1 - 100 of 126 matches
Mail list logo
