http://bugs.winehq.org/show_bug.cgi?id=27168
Summary: Eve Online: https pages won't load in In-Game Browser Product: Wine Version: 1.3.20 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: glibdud@hotmail.com
When trying to use the Eve in-game browser to visit any secure site (I've tried lots), the following error is returned:
Error loading requested URL Unable to process the website's SSL certficate Error Code: -202
Running Wine 1.3.20 on Ubuntu Natty 32-bit, compiled from source. The same issue was present on Ubuntu Maverick 32-bit via a precompiled Wine binary. For the version I compiled myself, I installed all the prereqs I could find... the only things the configure script complained about were OpenCL, OSS, and something about gstreamer (plugins?).
Not sure what sort of logs or other info would be relevant, but let me know and I'll post whatever is needed.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #1 from Austin English austinenglish@gmail.com 2011-05-14 21:13:56 CDT --- Terminal output?
http://bugs.winehq.org/show_bug.cgi?id=27168
Commander Commander.Alchemy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Commander.Alchemy@gmail.com
--- Comment #2 from Commander Commander.Alchemy@gmail.com 2011-05-15 05:10:26 CDT --- I can confirm on this, trying to open https (docs.google.com) Shows a
Error loading requested URL Error Code: -9
Will get terminal output soon.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #3 from glibdud@hotmail.com 2011-05-15 11:22:14 CDT --- Created an attachment (id=34719) --> (http://bugs.winehq.org/attachment.cgi?id=34719) Terminal output from a short session in which I tried a few secure sites.
Attached terminal output. I logged in, opened the IGB, tried a few secure sites, and logged back out. Not really sure what log server the "An exception has occurred." lines are referring to.
http://bugs.winehq.org/show_bug.cgi?id=27168
glibdud@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from glibdud@hotmail.com 2011-05-20 08:20:46 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=27168
Alexandre Rostovtsev tetromino@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tetromino@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
Kristoffer S. xycoster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xycoster@gmail.com
--- Comment #5 from Kristoffer S. xycoster@gmail.com 2011-07-12 09:45:24 CDT --- Problem is still present (wine-1.3.24), when i browse to https://www.google.com it gives the same error:
Error loading requested URL Unable to process the website's SSL certficate Error Code: -202
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2011-07-12 10:52:44 CDT --- The first thing to check is whether it's using builtin wininet or winhttp: please attach a +wininet,+winhttp trace, which ought to tell us.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #7 from Kristoffer S. xycoster@gmail.com 2011-07-12 11:21:13 CDT --- Created an attachment (id=35536) --> (http://bugs.winehq.org/attachment.cgi?id=35536) Terminal output when running some https sites
I do not know if I started eve the right way but I started eve by "wine explorer /desktop=0,1680x1050 eve.exe +wininet +winhttp"
And here is my terminal output.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #8 from Alexandre Rostovtsev tetromino@gmail.com 2011-07-12 11:22:43 CDT --- Created an attachment (id=35537) --> (http://bugs.winehq.org/attachment.cgi?id=35537) +wininet,+winhttp log
(In reply to comment #6)
The first thing to check is whether it's using builtin wininet or winhttp: please attach a +wininet,+winhttp trace, which ought to tell us.
Attaching +wininet,+winhttp log of logging into the game, opening the in-game browser, successfully opening http://www.google.com, and then trying to open https://www.google.com (and getting the "Unable to process the website's SSL certficate" error message).
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2011-07-12 12:38:46 CDT --- Thanks. It appears it's not using either winhttp or wininet, so please attach a +secur32 log instead. I may also ask for a +secur32,+crypt,+chain log.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #10 from Alexandre Rostovtsev tetromino@gmail.com 2011-07-12 12:59:38 CDT --- Created an attachment (id=35538) --> (http://bugs.winehq.org/attachment.cgi?id=35538) +secur32,+crypt,+chain
(In reply to comment #9)
Thanks. It appears it's not using either winhttp or wininet, so please attach a +secur32 log instead. I may also ask for a +secur32,+crypt,+chain log.
Attaching +secur32,+crypt,+chain log (xz-compressed, since it's 28 MB when in uncompressed form) of logging into the game, opening the in-game browser, successfully opening http://www.google.com, and then trying to open https://www.google.com (and getting the "Unable to process the website's SSL certficate" error message).
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2011-07-12 15:28:22 CDT ---
From your log:
trace:chain:CRYPT_BuildSimpleChain Couldn't find issuer, halting chain creation trace:chain:CRYPT_CheckSimpleChain checking chain with 1 elements for time (null) (snip) trace:chain:dump_element issued by L"Thawte SGC CA" (snip) trace:chain:dump_element issued to L"www.google.com" (snip) trace:chain:CertGetCertificateChain error status: 00010000
It appears as though the app is verifying the cert on its own, and since it doesn't provide any certificate except the end certificate, this is failing. (It should also provide the Thawte SGC CA certificate, since it's present in the TLS session.)
I don't know if it's an app bug, or an expected interaction between secur32 and crypt32 that isn't happening: since secur32 has already validated the cert (on Windows), it may have cached the chain, in which case a subsequent validation with just the end cert would succeed on Windows, but not on Wine. Tests needed.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #12 from Alexandre Rostovtsev tetromino@gmail.com 2011-07-12 17:02:48 CDT --- (In reply to comment #11)
I don't know if it's an app bug, or an expected interaction between secur32 and crypt32 that isn't happening
I don't think it's an app bug: the in-game browser works perfectly under Windows 7, and correctly loads https pages.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2011-07-12 17:18:52 CDT --- (In reply to comment #12)
I don't think it's an app bug: the in-game browser works perfectly under Windows 7, and correctly loads https pages.
Sorry, I should have said, an app bug that only appears in Wine due to some other unknown condition.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #14 from glibdud@hotmail.com 2011-08-15 09:44:26 CDT --- Still present after Incarna expansion.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #15 from Kristoffer S. xycoster@gmail.com 2011-08-15 15:34:31 CDT --- Did some research on the ingame browser and it appears to be running EVE/bin/Awesomium.dll version 1.5.0 ( http://awesomium.com ), and it seems that the source code is downloadable(a sdk atleast, but only v1.6).
I am crappy at programing and debugging but it could be useful for those who had more talent for it.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #16 from Ilya Konovalov aragaer@gmail.com 2011-09-11 08:55:17 CDT --- Created an attachment (id=36326) --> (http://bugs.winehq.org/attachment.cgi?id=36326) Store intermediate certificates to in-memory store
If you want something done, do it yourself...
Investigation shows that both https sites I've tried to open in IGB are signed with certificates which require some intermediate certificates (provided by the same servers as well). Current implementation of secur32 does nothing with certificates other than first one.
I've added the following: if there is more than one certificate, create an in-memory store for that certificate and push all extra certificates into it. The result is working https in IGB. See the attached patch.
The only problem is that the store has to be removed once the certificate is no longer used.
I've also found a few bugs in crypt32 during my investigation. The patch could be found here: https://gist.github.com/1209583
http://bugs.winehq.org/show_bug.cgi?id=27168
Ilya Konovalov aragaer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aragaer@gmail.com
--- Comment #17 from Ilya Konovalov aragaer@gmail.com 2011-09-11 09:08:17 CDT --- (In reply to comment #13)
(In reply to comment #12)
I don't think it's an app bug: the in-game browser works perfectly under Windows 7, and correctly loads https pages.
Sorry, I should have said, an app bug that only appears in Wine due to some other unknown condition.
The application calls CertGetCertificateChain supplying certificate's own store as an additional store.
http://codesearch.google.com/#-jYZujsTozo/trunk/src/net/base/x509_certificat...
http://bugs.winehq.org/show_bug.cgi?id=27168
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |secur32
--- Comment #18 from Juan Lang juan_lang@yahoo.com 2011-09-12 12:03:24 CDT --- Nice work. It should be possible to create test cases for secur32 to see whether this is really what it does. Like you say, there's the issue of freeing the certificate store when freeing the certificate. Probably the certificate should increase the reference count on the store, and decrement it when it's freed. This might take a bit of work to get right. I'm marking this as a secur32 bug, even though it probably involves crypt32 changes too.
Your crypt32 patch should be easier to get in, via a test case for CERT_KEY_IDENTIFIER_PROP_ID.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #19 from glibdud@hotmail.com 2011-09-13 07:36:37 CDT --- (In reply to comment #16)
Created an attachment (id=36326)
--> (http://bugs.winehq.org/attachment.cgi?id=36326) [details]
Store intermediate certificates to in-memory store
<snip>
I can confirm that this patch (I applied to Wine 1.3.28) allowed me to get in and browse a few https sites. Nice one!
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2011-09-14 10:55:00 CDT --- (In reply to comment #16)
I've also found a few bugs in crypt32 during my investigation. The patch could be found here: https://gist.github.com/1209583
Actually, the bulk of this patch appears incorrect, according to the test case at http://source.winehq.org/source/dlls/crypt32/tests/cert.c#L588 So don't send that one ;)
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #21 from Ilya Konovalov aragaer@gmail.com 2011-09-14 11:39:41 CDT --- (In reply to comment #20)
(In reply to comment #16)
I've also found a few bugs in crypt32 during my investigation. The patch could be found here: https://gist.github.com/1209583
Actually, the bulk of this patch appears incorrect, according to the test case at http://source.winehq.org/source/dlls/crypt32/tests/cert.c#L588 So don't send that one ;)
If nonexistent, searches for the szOID_SUBJECT_KEY_IDENTIFIER extension. If that fails, a SHA1 hash is done on the certificate's SubjectPublicKeyInfo member to produce the identifier values. (http://msdn.microsoft.com/en-us/library/aa376079(v=vs.85).aspx)
As of two other changes in that patch they don't really change anything.
Also I don't really know how to send patches at all so I'll pass for now anyway 8)
Currently I'm thinking on freeing the temporary store. Ref counters there are quite a mess.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #22 from Juan Lang juan_lang@yahoo.com 2011-09-14 14:41:10 CDT --- (In reply to comment #21)
If nonexistent, searches for the szOID_SUBJECT_KEY_IDENTIFIER extension. If that fails, a SHA1 hash is done on the certificate's SubjectPublicKeyInfo member to produce the identifier values. (http://msdn.microsoft.com/en-us/library/aa376079(v=vs.85).aspx)
MSDN is frequently wrong, and I think it is in this case, as the existing test case I pointed you too demonstrates.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #23 from Ilya Konovalov aragaer@gmail.com 2011-09-18 05:41:56 CDT --- (In reply to comment #18)
Probably the certificate should increase the reference count on the store, and decrement it when it's freed. This might take a bit of work to get right.
Trying to do it... And finding all the certificate store stuff is a bit overcomplicated. Duplicating, freeing, duplicating again... Seems quite a mess really.
I've wrote a simple app (https://gist.github.com/a0531270636f407b4a1d) that queries certificate from a google (and it also brings an intermediate certificate) then frees the certificate explicitly using CertFreeCertificateContext. The temporary store is freed (on windows). I'm trying to implement the same in wine but that's where the problem is - removing a certificate from store calls the same CertFreeCertificateContext. What's worse - enumerating certificates in store calls CertFreeCertificateContext.
Looks like it'll take more time to get my head around all the machinery here.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #24 from Ilya Konovalov aragaer@gmail.com 2011-09-18 08:18:29 CDT --- Just an idea - currently Context_Release accepts a dataContextFree pointer to a function which will free a data context once its reference count is down to 0. Now we need some way to free a certStore when reference counter on a link in that store is down to 0. Is adding something like linkContextFree a good idea?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #25 from Juan Lang juan_lang@yahoo.com 2011-09-18 12:23:51 CDT --- (In reply to comment #23)
Trying to do it... And finding all the certificate store stuff is a bit overcomplicated. Duplicating, freeing, duplicating again... Seems quite a mess really.
The design is partially imposed by the Crypto API. Of course, if it there was a simpler way to do it that I didn't see, that's my fault ;)
I've wrote a simple app (https://gist.github.com/a0531270636f407b4a1d) that queries certificate from a google (and it also brings an intermediate certificate) then frees the certificate explicitly using CertFreeCertificateContext. The temporary store is freed (on windows). I'm trying to implement the same in wine but that's where the problem is - removing a certificate from store calls the same CertFreeCertificateContext. What's worse - enumerating certificates in store calls CertFreeCertificateContext.
The last statement is due to how CertEnumCertificatesInStore works. From MSDN: "The returned pointer is freed when passed as the pPrevCertContext parameter on a subsequent call. Otherwise, the pointer must be freed by calling CertFreeCertificateContext."
But let's have a look at your test:
printf("Got the certificate %p, store = %p\n", cert, store = cert->hCertStore);
Don't assign to store in a print statement, it's easy to miss. Also, it would be preferable to assign store using CertDuplicateStore, i.e.:
store = CertDupicateStore(cert->hCertStore);
Otherwise, it's possible that the last remaining store reference is closed when you call CertEnumCertificatesInStore for the last cert in the store, implicitly closing the store and freeing it.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #26 from Ilya Konovalov aragaer@gmail.com 2011-09-18 12:27:15 CDT --- (In reply to comment #25)
Don't assign to store in a print statement, it's easy to miss.
My bad, was trying to make it all as short as possible and in some places I've shortened it a bit too much.
Also, it would be preferable to assign store using CertDuplicateStore, i.e.:
store = CertDupicateStore(cert->hCertStore);Otherwise, it's possible that the last remaining store reference is closed when you call CertEnumCertificatesInStore for the last cert in the store, implicitly closing the store and freeing it.
That's the point - once the certificate is freed the associated temporary storage is closed and CertEnumCertificatesInStore returns nothing.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #27 from Juan Lang juan_lang@yahoo.com 2011-09-18 12:28:42 CDT --- (In reply to comment #24)
Just an idea - currently Context_Release accepts a dataContextFree pointer to a function which will free a data context once its reference count is down to 0. Now we need some way to free a certStore when reference counter on a link in that store is down to 0. Is adding something like linkContextFree a good idea?
linkContextFree implies it'd only be done on link contexts? I don't think that's true. I think you need to increment the ref count of a cert's (/CRL's/CTL's) store when returning a cert (/CRL/CTL) from the store, e.g. from CertEnumCertificatesInStore, and decrement the store's ref count when freeing it. The difficulty comes in cascading the ref count to all the stores the cert is in, e.g. if the store is part of a collection. That's really pretty complicated, because collections know which stores are part of them, but stores do not know which stores they belong to.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #28 from Ilya Konovalov aragaer@gmail.com 2011-09-18 12:35:25 CDT --- (In reply to comment #27)
(In reply to comment #24)
Just an idea - currently Context_Release accepts a dataContextFree pointer to a function which will free a data context once its reference count is down to 0. Now we need some way to free a certStore when reference counter on a link in that store is down to 0. Is adding something like linkContextFree a good idea?
linkContextFree implies it'd only be done on link contexts? I don't think that's true. I think you need to increment the ref count of a cert's (/CRL's/CTL's) store when returning a cert (/CRL/CTL) from the store, e.g. from CertEnumCertificatesInStore, and decrement the store's ref count when freeing it. The difficulty comes in cascading the ref count to all the stores the cert is in, e.g. if the store is part of a collection. That's really pretty complicated, because collections know which stores are part of them, but stores do not know which stores they belong to.
CertEnumCertificatesInStore actually returns not data context, but link context (or at least that's what I'm seeing). On the other hand, data context doesn't know that it has a link to it which is stored in some store - only link does. When we perform CertFreeCertificateContext on a link (and what we're getting from Enum and Query are both links) we have to catch the fact that it is the only pointer to temporary store before we descend to actual data context below it. linkContextFree would perform actions needed to remove the context from stores it belongs to. And in case of temporary store remove the store itself.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #29 from Juan Lang juan_lang@yahoo.com 2011-09-18 12:41:46 CDT --- (In reply to comment #28)
CertEnumCertificatesInStore actually returns not data context, but link context (or at least that's what I'm seeing). On the other hand, data context doesn't know that it has a link to it which is stored in some store - only link does. When we perform CertFreeCertificateContext on a link (and what we're getting from Enum and Query are both links) we have to catch the fact that it is the only pointer to temporary store before we descend to actual data context below it. linkContextFree would perform actions needed to remove the context from stores it belongs to. And in case of temporary store remove the store itself.
I still think you have to solve this more generally: MSDN documents (see especially CertCloseStore) how certificate contexts increment a reference count of stores, and a little about how this should behave. I didn't do it this way because I didn't need it when I started, and so far I hadn't found an app that depended on it. Now it appears we do have one.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #30 from Ilya Konovalov aragaer@gmail.com 2011-09-20 16:39:36 CDT --- (In reply to comment #29)
I still think you have to solve this more generally: MSDN documents (see especially CertCloseStore) how certificate contexts increment a reference count of stores, and a little about how this should behave. I didn't do it this way because I didn't need it when I started, and so far I hadn't found an app that depended on it. Now it appears we do have one.
Had to understand how it all works. Tried to describe it all to myself here: http://tinyurl.com/5v8b3cl Also found yet another possible workaround for the case described here. While it is looking good, I'm not going to implement it actually and will concentrate on ref counts for stores instead.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #31 from Ilya Konovalov aragaer@gmail.com 2011-09-21 09:29:41 CDT --- Created an attachment (id=36492) --> (http://bugs.winehq.org/attachment.cgi?id=36492) Store intermediate certificates to in-memory store and properly free it later
Here's the updated patch. Now it properly tracks ref counters on store and uses it to clean up everything. No hacking.
Unfortunately it doesn't properly track ref counters on collections and as result it frees "world" collection too early and fails to build a chain. Will focus on collections now.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #32 from Juan Lang juan_lang@yahoo.com 2011-09-22 07:26:17 CDT --- (In reply to comment #31)
Here's the updated patch. Now it properly tracks ref counters on store and uses it to clean up everything. No hacking.
I think you'll want to add test cases in the form of Wine regression tests.
Unfortunately it doesn't properly track ref counters on collections and as result it frees "world" collection too early and fails to build a chain. Will focus on collections now.
Like I mentioned, collections will be the hard part.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #33 from Juan Lang juan_lang@yahoo.com 2011-09-22 15:24:11 CDT --- Out of curiosity, I wrote a brief test for the cert store that a cert created via CertCreateCertificateContext has; see commit 546bfa2c1ce82f80613cce7870d306faf2de653a. It appears as though the cert isn't actually in this store, so somehow the cert contains a reference to the store even though it isn't part of it.
I'd like to add similar tests when verifying a chain, as I think they might help persuade us a little more about the behavior of schannel with respect to certs and stores. Is this something special that schannel is supposed to be doing, or is it implicit in its use of crypt32? That's what I'd like to try to find out.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #34 from Ilya Konovalov aragaer@gmail.com 2011-09-28 14:10:57 CDT --- (In reply to comment #33)
Out of curiosity, I wrote a brief test for the cert store that a cert created via CertCreateCertificateContext has; see commit 546bfa2c1ce82f80613cce7870d306faf2de653a. It appears as though the cert isn't actually in this store, so somehow the cert contains a reference to the store even though it isn't part of it.
It seems it's not a real store after all. I ran the test several times, created lots of certs in a loop and every time it pointed to the same store. Which seemed weird enough. I tried to duplicate the store - that succeeded. I tried to close the duplicate and that failed with E_UNEXPECTED (8000ffff).
I believe that creation of memstore with intermediate certs is indeed the function of schannel (msdn explicitly mentions the store and intermediate certs in QueryContextAttributes page for schannel).
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #35 from Ilya Konovalov aragaer@gmail.com 2011-09-28 15:47:02 CDT --- In theory whenever a cert context is duplicated we want to increase the ref counter of a store it belongs. However if we have a collection which contains a store which contains a cert (and we have link1 in collection, link2 in store and data somewhere) if we duplicate a link1 we can increase ref counter only on collection, but not on store. At the same time all ref counters on all cert contexts are increased.
This is because Context_AddRef doesn't know which kind of contexts it is handling. The same actually applies to Context_Release.
The problem is not really related to collections per se. It is actually about how link contexts and their reference counters work currently. The only idea I have is to provide every context with contextInterface which will be used in AddRef and Release.
Another solution, which could sound strange actually, is to not do cascade addref/release at all. Even if some link is duplicated it is still just one reference to whatever it links to. If we need to duplicate that we can do it explicitly.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #36 from Juan Lang juan_lang@yahoo.com 2011-09-28 17:33:54 CDT --- I'm glad you're thinking about the problem: what exists is what grew as I wrote it, not from any well-thought-out design. So I'm not surprised that there are bugs in reference counting.
I think you may be right in wanting to isolate the problem of context reference counts from store reference counts. That might make it possible to reason about them separately. (It also might be possible to implement features of stores that aren't yet supported, e.g. CERT_CLOSE_STORE_CHECK_FLAG and CERT_CLOSE_STORE_FORCE_FLAG, but that's beyond the scope of this bug.)
I'm not sure if that's useful advice or not. So could you talk about collection stores, and what problems you were having with them?
http://bugs.winehq.org/show_bug.cgi?id=27168
Pavel Ondračka pavel.ondracka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pavel.ondracka@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #37 from Dan Kegel dank@kegel.com 2011-09-29 08:24:02 CDT --- http://tinyurl.com/5v8b3cl is a broken link...
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #38 from Juan Lang juan_lang@yahoo.com 2011-09-29 10:35:04 CDT --- (In reply to comment #37)
http://tinyurl.com/5v8b3cl is a broken link...
True, but it's easy enough to figure out: delete the first portion of the url such that you have only one https://docs.google.com.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #39 from Ilya Konovalov aragaer@gmail.com 2011-09-29 23:52:36 CDT --- (In reply to comment #37)
http://tinyurl.com/5v8b3cl is a broken link...
Right, sorry for that - I failed to find a way to edit either my comment or tinyurl when I found that link is broken.
More research here: http://tinyurl.com/67z76cf (and I hope this url will work). I've wrote a simple app with collections (link to code in the document) and tried to predict what should be reference counters on all objects using current implementation and using "no cascade" implementation.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #40 from Ilya Konovalov aragaer@gmail.com 2011-10-08 05:06:30 CDT --- Created attachment 36770 --> http://bugs.winehq.org/attachment.cgi?id=36770 Consistent ref counters
Yet another patch. This one does show https pages AND properly frees stores. However it is a bit ugly and requires some nice comments. I've got an explanation on how ref counters work now but it is a 6-page google doc: https://docs.google.com/document/d/1IFfhXOkXvh-NPmpUEPlHyKNS3G9ttAwfc8wXEIdR...
Next step would be to streamline the whole ref counting business. Assuming my approach is correct.
https://github.com/aragaer/wine/tree/https_debug - this branch contains the same code filled with a lot of debugging stuff. I used it to verify that temp store is actually freed.
http://bugs.winehq.org/show_bug.cgi?id=27168
Ilya Konovalov aragaer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36770|0 |1 is obsolete| |
--- Comment #41 from Ilya Konovalov aragaer@gmail.com 2011-10-15 15:55:04 CDT --- Created attachment 36923 --> http://bugs.winehq.org/attachment.cgi?id=36923 Consistent ref counters (fixed)
Yet another patch. I've fixed a small problem (data context ref counts weren't adjusted when stores they were in were closed) and added some comments through the code. I hope it all now makes sense without reading the whole 6-page long article on topology I've linked before.
I'd be happy to get any callback about the code actually.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #42 from Juan Lang juan_lang@yahoo.com 2011-10-15 19:57:25 CDT --- (In reply to comment #41)
I'd be happy to get any callback about the code actually.
My comments aren't going to be that nice to hear, unfortunately. I'm happy that you're trying to fix this, but I have to say your patch is difficult to understand. (Admittedly, so is the code, but that's a different problem.) That, combined with its length, and a lack of tests, means that I think the odds of it getting accepted are basically nil.
Furthermore, assuming it's correct for certificates, it's still not entirely correct: the complicated reference logic applies to CRLs and CTLs too, so you'd have to adjust those too.
So how to get there: 1. I can't emphasize enough the importance of test cases that demonstrate what's wrong. 2. See if you can split your patch in some way. Often, when the patch is large, that means there are several problem you're addressing at once. In that case, one fix per patch is a good way to split the patch.
I hope that helps. If you'd like to chat more about it sometime, try emailing me at juan dot lang at gmail dot com or at wine-devel.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #43 from Ilya Konovalov aragaer@gmail.com 2011-12-06 23:57:43 CST --- Created attachment 37843 --> http://bugs.winehq.org/attachment.cgi?id=37843 Test showing the problem
Here's the test that shows the problem. Sorry it took that long.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #44 from Juan Lang juan.lang@gmail.com 2011-12-07 10:11:03 CST --- (In reply to comment #43)
Here's the test that shows the problem. Sorry it took that long.
Thanks! Some suggestions before sending it to wine-patches:
+ if (ret) + skip("Can't init winsock 2.2\n");
You should skip, then return. skip just adds something to the output. Likewise elsewhere where you skip.
+ /* Create client credentials */ + memset(&cred, 0, sizeof cred);
Bad indent (using a tab instead of spaces.)
+ buffers[0].pBuffers[0].BufferType = SECBUFFER_TOKEN; Ditto.
+ buffers[0].pBuffers[0].cbBuffer = buf_size; This should already be done by init_buffers, no? + buffers[1].pBuffers[0].cbBuffer = buf_size; Likewise.
+ printf("Got the certificate %p, store = %p\n", cert, store); Please remove the printfs :)
http://bugs.winehq.org/show_bug.cgi?id=27168
Ilya Konovalov aragaer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37843|0 |1 is obsolete| |
--- Comment #45 from Ilya Konovalov aragaer@gmail.com 2011-12-07 11:51:51 CST --- Created attachment 37851 --> http://bugs.winehq.org/attachment.cgi?id=37851 fixed test
Updated as requested.
I'm still unsure I've used todo_wine properly. That's what I'm getting when running test under wine:
schannel.c:871: Test failed: Expected intermediate store, got NULL schannel: 47 tests executed (0 marked as todo, 1 failure), 0 skipped.
while in code it is
todo_wine ok(store != NULL, "Expected intermediate store, got NULL\n");
so I'd expect "1 marked as todo, 0 failure" result.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #46 from Dan Kegel dank@kegel.com 2011-12-07 12:00:58 CST --- How'd you run the test? Maybe you ran it without setting WINETEST_PLATFORM? "make test" uses tools/runtests, which does export WINETEST_PLATFORM=wine Without that, todo_wine doesn't know what platform it's on, so it doesn't work as expected.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #47 from Ilya Konovalov aragaer@gmail.com 2011-12-07 12:03:18 CST --- (In reply to comment #46)
How'd you run the test? Maybe you ran it without setting WINETEST_PLATFORM? "make test" uses tools/runtests, which does export WINETEST_PLATFORM=wine Without that, todo_wine doesn't know what platform it's on, so it doesn't work as expected.
That's how: $ ../../../wine ./secur32_test.exe.so schannel
With WINETEST_PLATFORM=wine I've got the expected result indeed. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #48 from Juan Lang juan.lang@gmail.com 2011-12-08 12:44:07 CST --- Comment on attachment 37851 --> http://bugs.winehq.org/attachment.cgi?id=37851 fixed test
One more tab:
+ if (status != SEC_E_OK) { + skip("Query cert expected OK, got %08x\n", status); + goto out; + }
(Before skip.) Fix, and it should be ready for wine-patches. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=27168
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
--- Comment #49 from fracting fracting@gmail.com 2011-12-13 12:29:29 CST --- *** Bug 29075 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27168
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Eve Online: https pages |chromium-based apps can't |won't load in In-Game |load https sites |Browser |
--- Comment #50 from Juan Lang juan.lang@gmail.com 2011-12-14 10:34:37 CST --- Adjusting summary, as this affects more than just Eve Online.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #51 from Qian Hong fracting@gmail.com 2012-01-25 08:11:06 CST --- (In reply to comment #48)
Comment on attachment 37851 [details] fixed test
One more tab:
- if (status != SEC_E_OK) {
- skip("Query cert expected OK, got %08x\n", status);
goto out;- }
(Before skip.) Fix, and it should be ready for wine-patches. Thanks!
Still in wine-1.3.37-378-gdfa9f4b Any updates?
Thanks a lot!
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #52 from Commander Commander.Alchemy@gmail.com 2012-04-03 09:15:28 CDT --- Still cannot load https links in Wine 1.5.1
http://bugs.winehq.org/show_bug.cgi?id=27168
Felyza felyza@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felyza@gmail.com
--- Comment #53 from Felyza felyza@gmail.com 2012-05-30 13:15:52 CDT --- (In reply to comment #48)
Comment on attachment 37851 [details] fixed test
One more tab:
- if (status != SEC_E_OK) {
- skip("Query cert expected OK, got %08x\n", status);
goto out;- }
(Before skip.) Fix, and it should be ready for wine-patches. Thanks!
Still not working in 1.5.5.
Reading through the comments over the last year, it appears the one final change needed to submit the fix to wine-patches, per this post by Juan Lang, is changing \t to " " (without quotes). Digging through wine-devel and wine-patches archives, it doesn't appear this patch ever made submission, so it unfortunately appears the original person to work on this left after that comment.
I'm in the process of building against 1.5.5. If all is well, tests succeed, and https:// is working, I'll make the required change and submit it. As this bug affects more than a single application, hopefully it will be well received.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #54 from Ilya Konovalov aragaer@gmail.com 2012-05-30 13:32:33 CDT --- (In reply to comment #53)
Still not working in 1.5.5.
Reading through the comments over the last year, it appears the one final change needed to submit the fix to wine-patches, per this post by Juan Lang, is changing \t to " " (without quotes). Digging through wine-devel and wine-patches archives, it doesn't appear this patch ever made submission, so it unfortunately appears the original person to work on this left after that comment.
I'm in the process of building against 1.5.5. If all is well, tests succeed, and https:// is working, I'll make the required change and submit it. As this bug affects more than a single application, hopefully it will be well received.
I am still around just don't have time to do anything useful actually.
The patch you are looking at is not the fix for the bug described here. It is just a set of tests which would reveal a missing functionality. What this test lacks is actually testing if https sites will work. That is - it tests if certificates are fetched and tests that there are several certificates and that they are kept in intermediate storage. It does not attempt to verify those certificates.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #55 from Juan Lang juan.lang@gmail.com 2012-05-30 14:04:41 CDT --- (In reply to comment #54)
The patch you are looking at is not the fix for the bug described here. It is just a set of tests which would reveal a missing functionality. What this test lacks is actually testing if https sites will work. That is - it tests if certificates are fetched and tests that there are several certificates and that they are kept in intermediate storage. It does not attempt to verify those certificates.
I still think adding the tests would be valuable, so at least we document a shortcoming of secur32. Would you have time to submit?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #56 from Ilya Konovalov aragaer@gmail.com 2012-05-30 14:34:06 CDT --- (In reply to comment #55)
I still think adding the tests would be valuable, so at least we document a shortcoming of secur32. Would you have time to submit?
Will try later this week.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #57 from Felyza felyza@gmail.com 2012-05-30 14:47:49 CDT --- Glad to hear I mistook the sudden disappearance last year as something worse than it was. If you're playing eve, one of the apps affected, I'd be more than happy to send an in game donation for the cause.
Regardless, thank you for the updates!
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #58 from Ilya Konovalov aragaer@gmail.com 2012-06-02 12:09:42 CDT --- Sent the tests patch to wine-patches.
http://bugs.winehq.org/show_bug.cgi?id=27168
rmlipman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rmlipman@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #59 from rmlipman@gmail.com 2012-08-27 17:43:16 CDT --- *** Bug 31479 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27168
Nick Bowler nbowler@draconx.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nbowler@draconx.ca
http://bugs.winehq.org/show_bug.cgi?id=27168
voidcastr cephryx@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cephryx@gmx.net
--- Comment #60 from voidcastr cephryx@gmx.net 2012-09-09 13:08:17 CDT --- Is this still being worked on?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #61 from voidcastr cephryx@gmx.net 2012-09-16 07:49:05 CDT --- Well, apparently not. Why can't the patch be merged into mainline? Does it break anything or is it incomplete / a hack?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #62 from Dan Kegel dank@kegel.com 2012-09-16 10:40:59 CDT --- Folks are just busy. If anyone else wants to pick this up and run with it, that would probably be ok.
http://bugs.winehq.org/show_bug.cgi?id=27168
Anthony Mattheakakis antony256@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |antony256@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #63 from voidcastr cephryx@gmx.net 2012-09-25 04:06:03 CDT --- Well, so we got a partial implementation here (the attachment from comment #41) that is known to fix dealbreakers for some applications (i.e. Guild Wars 2 and EVE Online).
And we got a test case showing what's missing/incorrect... right?
So, my questions are:
- Why exactly can't the actual patch be merged into mainline? Granted, it's a longish and quite complicated one. But even though it's not complete, it is likely to improve things for many users. Unless it breaks other things or it comprises security issues (it's about https after all), it should at least be considered to merge the patch in its current state.
- In case that is absolutely unacceptable, someone need to pick this up. It seems like Ilya Konovalov already completed the major part of this. So some first-hand hints about where and how to go on might be very useful... given that the code is really tricky.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #64 from Ilya Konovalov aragaer@gmail.com 2012-09-25 04:18:41 CDT --- I'll try explaining what the patch in #41 is and what it is not.
If you apply the patch the result is that it does not really behave as Windows implementation does. I tried to do everything "the right way" but apparently windows implementation is not doing it "the right way" I assumed. Basically, windows implementation fails one of tests I used to demonstrate why the patch is needed in its current form.
On the other hand the patch simply works so if you need it just for yourself, you can use it (and it's tested and should not break anything).
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #65 from voidcastr cephryx@gmx.net 2012-09-25 05:06:32 CDT --- My point is: To me, personally, it is not a big deal to patch and recompile wine. But I suppose, for 99% of its users it is a major barrier. This is why I asked about the mainline merge, etc. ... so, what remains to be done in order to achieve this?
Or in general: How could we proceed from here? I'd like to help debugging and coding, but I don't know where to start.
Sadly, in case Windows does not implement something "the right way", this behavior should be mimiced by wine after all, shouldn't it? This is not meant as criticism, I'm just wondering.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #66 from Ilya Konovalov aragaer@gmail.com 2012-09-25 05:11:20 CDT --- (In reply to comment #65)
Sadly, in case Windows does not implement something "the right way", this behavior should be mimiced by wine after all, shouldn't it? This is not meant as criticism, I'm just wondering.
Indeed. That's the only way to justify a large patch - demonstrate that it mimics windows implementation.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #67 from voidcastr cephryx@gmx.net 2012-09-25 05:23:45 CDT --- Well, but isn't the above test about this demonstration? So if we have that patch AND tests showing its "correctness" in terms of matching Windows' behavior, why wasn't it merged? Maybe I'm missing something but I still don't get the point here.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #68 from Ilya Konovalov aragaer@gmail.com 2012-09-25 06:29:52 CDT --- The test above doesn't (In reply to comment #67)
Well, but isn't the above test about this demonstration? So if we have that patch AND tests showing its "correctness" in terms of matching Windows' behavior, why wasn't it merged? Maybe I'm missing something but I still don't get the point here.
The test is submitted to wine-patches, but it does not actually justify the patch. It just demonstrates that there's something missing in crypt32 and secur32.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #69 from voidcastr cephryx@gmx.net 2012-09-25 06:55:25 CDT --- (In reply to comment #68)
The test is submitted to wine-patches, but it does not actually justify the patch. It just demonstrates that there's something missing in crypt32 and secur32.
So we need - a test showing Windows' behavior, - another test showing the behavior of the above patch, and - a comparison of the results in order to get the patch merged?
Or are the missing parts in crypt32 and secur32 mandatory?
My apologies for being that insistent, but I have the impression that any progress here would be appreciated by many users.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #70 from Ilya Konovalov aragaer@gmail.com 2012-09-25 08:12:05 CDT --- (In reply to comment #69)
So we need
- a test showing Windows' behavior,
- another test showing the behavior of the above patch, and
- a comparison of the results
in order to get the patch merged?
Unfortunately no, the patch above is not likely to be ever merged.
We need - a test showing the difference between windows and current crypt32/secur32 implementation (sent to wine-patches already, don't know the current state though) - some "hacky" patch "fixing" crypt32 - simple patch to secur32 (could be taken from patch above)
"Hacky" means it is not really doing complex job of keeping reference counters and stuff and instead .. doing something simple but allowing us to keep certificate storage without reference to it. Windows implementation does that (and I don't doubt it's indeed some workaround).
The problem is that we can't look into windows' solution as it would be reverse engineering and it is not something we want. The solution discussed here in #21 - #28 (before considering a more generic way) might work. Or might not.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #71 from voidcastr cephryx@gmx.net 2012-09-25 09:54:56 CDT --- I think I understand most parts of the actual problem now... together with your above explanation the discussion in #21 - #28 was quite helpful. It's indeed tricky because Windows' behavior seems weird here and appears to be not well documented... solving this issue doubtlessly involves lots of trial and error approaches. I'm planning on further investigating this, but it will take plenty of time.
http://bugs.winehq.org/show_bug.cgi?id=27168
voidcastr cephryx@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|cephryx@gmx.net |
http://bugs.winehq.org/show_bug.cgi?id=27168
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |voidcastr@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
George Gibbs vash63@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vash63@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
http://bugs.winehq.org/show_bug.cgi?id=27168
sl1pkn07 sl1pkn07@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sl1pkn07@gmail.com
--- Comment #72 from sl1pkn07 sl1pkn07@gmail.com 2012-10-03 12:03:06 CDT --- awesomium patch dont work for me in 1.5.14 in GuildWars2 (ring roll in bazar)
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #73 from sl1pkn07 sl1pkn07@gmail.com 2012-10-03 12:21:56 CDT --- (In reply to comment #72)
awesomium patch dont work for me in 1.5.14 in GuildWars2 (ring roll in bazar)
in GIT (ea151639737f08ca76bcec0ae174296cacdc572c) dont work or works with errors
http://sl1pkn07.no-ip.com/GW2/gw009.bmp http://sl1pkn07.no-ip.com/GW2/gw010.bmp
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #74 from voidcastr voidcastr@gmail.com 2012-10-03 13:14:28 CDT --- For me (on Ubuntu 12.04 x64), the patch still works with the current git version (still ea151639737f08ca76bcec0ae174296cacdc572c).
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #75 from sl1pkn07 sl1pkn07@gmail.com 2012-10-03 14:54:21 CDT --- what library is depend of the patch?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #76 from voidcastr voidcastr@gmail.com 2012-10-03 15:49:54 CDT --- I don't think the patch brings a new dependency.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #77 from sl1pkn07 sl1pkn07@gmail.com 2012-10-03 17:03:20 CDT --- not new dependedency, i mean the pacth what library affect? libreypto? lib"wath"? is for view diference of version library build between ubuntu and archlinux
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #78 from sl1pkn07 sl1pkn07@gmail.com 2012-10-03 21:56:03 CDT --- i try install ubuntu in virtualbox (12.04 64bits) to build wine like official DSC with awesomium patch and screenshot patch (http://bugs.winehq.org/show_bug.cgi?id=31557)
build whit prefix looking folder like my arch installation. after install in ubuntu compress the folder and uncompress in my arch
same result, bazar don't work, and screenshot in jpg looks bad (in bmp looks ok)
any ideas?
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #79 from voidcastr voidcastr@gmail.com 2012-10-04 03:00:58 CDT --- That might be hard to tell... as seen in the diff (attachment to comment #41), the patch is altering multiple files:
dlls/crypt32/... ...cert.c ...collectionstore.c ...context.c ...crypt32_private.h ...store.c dlls/secur32/schannel_gnutls.c
The new stuff in there mostly allows for dealing with https connections (especially certificates) in chromium/awesomium based apps...
When you just see the "circle of doom" (endlessly rolling ring in the bazar), it might indicate that the new https part implemented by the patch does not work for you, for some reason.
But if you get bazar rendering issues I'm quite sure that the patch actually works but some code beyond its scope (i.e. from mainline or a specific lib) is failing because of some dependency trouble you got. Most likely, this would be quite hard to identify... tough -- in this case -- I think it's related to chromium based website rendering in general.
Most likely Ilya Konovalov is more into this -- he wrote the patch.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #80 from Ilya Konovalov aragaer@gmail.com 2012-10-04 03:07:33 CDT --- The patch changes two things.
1. It enables certificates to keep reference to internal temporary store of intermediate certificates (which are then used to prove validity of site certificate) and allows the clean removal of that store.
2. It alters secur32 to properly initialize that internal temporary store.
Nothing else.
http://bugs.winehq.org/show_bug.cgi?id=27168
JR zorael@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zorael@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
Forest winehq@tibit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@tibit.com
--- Comment #81 from Forest winehq@tibit.com 2012-11-03 13:07:07 CDT --- I think it's safe to mark this bug confirmed.
I've built an ubuntu package of wine 1.5.16 with the Consistent ref counters (fixed) patch. Get it here: https://launchpad.net/~foresto/+archive/winepatched/
http://bugs.winehq.org/show_bug.cgi?id=27168
winehq@psycho3d.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@psycho3d.de
http://bugs.winehq.org/show_bug.cgi?id=27168
Robert Gladson hiddenfoxling@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hiddenfoxling@gmail.com
--- Comment #82 from Robert Gladson hiddenfoxling@gmail.com 2012-11-13 06:39:19 CST --- As of 1.5.17, at least in Guildwars 2 Black Lion Market, seems to be fixed for trading items and the market, with the 'fallback to TLS' added in this version. As for the gem to gold/gold to gem pane, I couldn't get it to load still, although I could just simply be down.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #83 from Qian Hong fracting@gmail.com 2012-11-13 07:12:37 CST --- Retest with wine-1.5.17, still affects chromium
http://bugs.winehq.org/show_bug.cgi?id=27168
Sander svl_wine@juima.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |svl_wine@juima.org
http://bugs.winehq.org/show_bug.cgi?id=27168
David Philippi david@torangan.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@torangan.de
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #84 from Forest winehq@tibit.com 2012-11-27 03:06:18 CST --- (In reply to comment #82)
As of 1.5.17, at least in Guildwars 2 Black Lion Market, seems to be fixed for trading items and the market, with the 'fallback to TLS' added in this version.
GW2 isn't fixed for me. Some of the Black Lion Trading Company panels open in wine 1.5.18, but not all of them. I still need to patch wine in order to see the Items I'm Buying panel, for example.
http://bugs.winehq.org/show_bug.cgi?id=27168
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #85 from Jacek Caban jacek@codeweavers.com 2013-01-21 10:45:16 CST --- Too bad I didn't see the bug earlier... I've sent patches that should fix the problem:
http://source.winehq.org/patches/data/93791 http://source.winehq.org/patches/data/93792 http://source.winehq.org/patches/data/93793
About storing reference to cert store in cert context, I ran into the same problem. According to my quick tests, cert context should not hold refference to the store, so the store may be freed while cert still point to it. I may have missed something, do you have any test showing that the refference is kept? In my patch, I simply keep the store in schannel context.
Any feedback and test are welcomed.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #86 from Jacek Caban jacek@codeweavers.com 2013-01-21 15:35:21 CST --- Patches are in Git, please retest.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #87 from sworddragon2@aol.com 2013-01-21 18:20:48 CST --- I have now tested the newest git with Guild Wars 2 and finally all https sites are loading but there are still problems:
- Sometimes a site doesn't load. If so all next tries are failing until the game is restarted. - All sites have visual corruptions. Some pictures are not drawed and some objects are overlapping.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #88 from sl1pkn07 sl1pkn07@gmail.com 2013-01-21 18:26:39 CST --- i agree. i have corruptions (http://wstaw.org/m/2013/01/22/gw132.png) and some times get GROTD (gold ring of the death)
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #89 from sworddragon2@aol.com 2013-01-21 18:36:38 CST --- @Jacek Caban: There was already a patch which was working fine with Guild Wars 2: http://bugs.winehq.org/attachment.cgi?id=36923 But it seems it doesn't meet the the requirements to get into the official git repository. But maybe the patch helps you to find the problem.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #90 from Jacek Caban jacek@codeweavers.com 2013-01-22 05:04:01 CST --- (In reply to comment #89)
@Jacek Caban: There was already a patch which was working fine with Guild Wars 2: http://bugs.winehq.org/attachment.cgi?id=36923
As I said, I didn't see it before sending a patch, but crypt32 changes seem questionable and need tests.
But it seems it doesn't meet the the requirements to get into the official git repository. But maybe the patch helps you to find the problem.
Well, remaining problems don't seem related. It would be interesting to see if current Git with my patches reverted and that one applied work any better. And if yes, what happens if you leave my patch, but apply crypt32 part of that one.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #91 from sl1pkn07 sl1pkn07@gmail.com 2013-01-22 07:11:30 CST --- i test latest git with http://bugs.winehq.org/attachment.cgi?id=36923, but witout dlls/secur32/schannel_gnutls.c patch (reject if applied)
works like expected
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #92 from sworddragon2@aol.com 2013-01-22 12:40:35 CST --- The current git with a modified awesomium patch (the changes from dlls/secur32/schannel_gnutls.c are removed) works fine here too.
http://bugs.winehq.org/show_bug.cgi?id=27168
Selman ULUG selman.ulug@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |selman.ulug@gmail.com
--- Comment #93 from Selman ULUG selman.ulug@gmail.com 2013-01-22 13:05:35 CST --- only applied "crypt32" part (https://gist.github.com/4597314) of awesomium still working without problem after 1 hour of play.
(In reply to comment #90)
(In reply to comment #89)
@Jacek Caban: There was already a patch which was working fine with Guild Wars 2: http://bugs.winehq.org/attachment.cgi?id=36923
As I said, I didn't see it before sending a patch, but crypt32 changes seem questionable and need tests.
But it seems it doesn't meet the the requirements to get into the official git repository. But maybe the patch helps you to find the problem.
Well, remaining problems don't seem related. It would be interesting to see if current Git with my patches reverted and that one applied work any better. And if yes, what happens if you leave my patch, but apply crypt32 part of that one.
http://bugs.winehq.org/show_bug.cgi?id=27168
Stefan Reimer it@stefanreimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |it@stefanreimer.de
--- Comment #94 from Stefan Reimer it@stefanreimer.de 2013-02-03 16:43:50 CST --- Just tested https sites with EVE online in game browser. Works like a charm since 1.5.23!
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #95 from Forest winehq@tibit.com 2013-02-04 15:06:47 CST --- I just tried the Guild Wars 2 trading post with the official wine 1.5.23 Ubuntu package. It's working better than it was with previous versions, but some images are still not loading.
The chromium_no_cascade2 patch now fails to apply, but removing the the schannel_gnutls.c part makes it apply cleanly and fixes the trading post.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #96 from glibdud@hotmail.com 2013-02-05 07:23:12 CST --- I can confirm that the IGB in Eve appears to be behaving much better, however I did hit one temporary issue. The first time I tried to log into Eve Gate and go to the forums, it gave me a different-but-similar error to the one that spawned this ticket (It had a "-202" and mentioned certificates). Sadly, I didn't write it down... I closed the browser, started again, and was able to get through the second time. So I'm not sure if the IGB caches and it was related to that, or if there's still an edge case issue. Leagues better than it was before, though.
http://bugs.winehq.org/show_bug.cgi?id=27168
davide.monge@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davide.monge@gmail.com
--- Comment #97 from davide.monge@gmail.com 2013-02-05 09:05:57 CST --- tested https sites with EVE online in game browser. Works since 1.5.23!
http://bugs.winehq.org/show_bug.cgi?id=27168
Samu Voutilainen samu.voutilainen@kolumbus.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |samu.voutilainen@kolumbus.f | |i
--- Comment #98 from Samu Voutilainen samu.voutilainen@kolumbus.fi 2013-03-23 12:35:05 CDT --- It looks like TERA Online still needs this patch.
http://bugs.winehq.org/show_bug.cgi?id=27168
nwt tastky@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tastky@gmail.com
--- Comment #99 from nwt tastky@gmail.com 2013-05-11 07:11:00 CDT --- The partial patch as provided by Selman also continues to be required for Guild Wars 2 to properly work (auctions, etc.) — how come it hasn't been committed yet?
http://bugs.winehq.org/show_bug.cgi?id=27168
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, patch URL| |http://patch.tera.enmasse-g | |ame.com/TERA-Setup.exe CC| |fgouget@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=27168
Joo julianmelvynjones@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julianmelvynjones@gmail.com
--- Comment #100 from Joo julianmelvynjones@gmail.com 2013-06-13 14:42:59 CDT --- Still an issue as of 1.6-rc1. Would like to see this committed, would give you all big snogs.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #101 from Dan Kegel dank@kegel.com 2013-06-13 14:51:28 CDT --- Jacek suggested in #90 that the crypt32 patch ( e.g. the one in #93 ) still needs testcases to show it's right before it can be accepted.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #102 from Joo julianmelvynjones@gmail.com 2013-06-13 15:01:27 CDT --- (In reply to comment #101)
Jacek suggested in #90 that the crypt32 patch ( e.g. the one in #93 ) still needs testcases to show it's right before it can be accepted.
Fair enough! Here's hoping.
http://bugs.winehq.org/show_bug.cgi?id=27168
Karsten Elfenbein kelfe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kelfe@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=27168
Arnoud Willemsen mail@lynthium.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@lynthium.com
--- Comment #103 from Arnoud Willemsen mail@lynthium.com 2013-09-05 21:18:46 CDT --- Updated patch for git (after commit 9cee96be). Seems the new Battle.net app needs this as well to display its news, etc. I'm not that familiar with this code however so it might have gotten some unintended side effects, but it seems to run fine here. http://sprunge.us/LQWS
http://bugs.winehq.org/show_bug.cgi?id=27168
James Eder jimportal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jimportal@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
kernelpanix@rocketmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kernelpanix@rocketmail.com
--- Comment #104 from kernelpanix@rocketmail.com 2013-09-08 15:04:06 CDT --- (In reply to comment #103)
Updated patch for git (after commit 9cee96be). Seems the new Battle.net app needs this as well to display its news, etc. I'm not that familiar with this code however so it might have gotten some unintended side effects, but it seems to run fine here. http://sprunge.us/LQWS
Thanks for the patch.
I can confirm that, this patch apply successfully on the git tree at least on the '88c2a18' commit.
This patch fix the https/ssl problem, of the new Blizzard Desktop App.
http://bugs.winehq.org/show_bug.cgi?id=27168
Adrian xadrianx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xadrianx@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #105 from Samu Voutilainen samu.voutilainen@kolumbus.fi 2013-09-15 08:22:48 CDT --- Created attachment 45961 --> http://bugs.winehq.org/attachment.cgi?id=45961 Patch against current git (15.09.2013)
There was again an update in git, so this contains very little difference compared to previous patch. I substituted owner of this change by foo, since I have no idea who actually did the original change...
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #106 from sl1pkn07 sl1pkn07@gmail.com 2013-10-08 17:10:54 CDT --- (In reply to comment #105)
Created attachment 45961 [details] Patch against current git (15.09.2013)
There was again an update in git, so this contains very little difference compared to previous patch. I substituted owner of this change by foo, since I have no idea who actually did the original change...
not apply in gbb2c32d
http://sl1pkn07.no-ip.com/paste/view/aea9ceb1
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #107 from Arnoud Willemsen mail@lynthium.com 2013-10-09 05:22:36 CDT --- http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #108 from sl1pkn07 sl1pkn07@gmail.com 2013-10-11 13:35:06 CDT --- (In reply to comment #107)
http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
the patch don't apply in 1.7.4 release today
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #109 from sl1pkn07 sl1pkn07@gmail.com 2013-10-11 14:47:40 CDT --- (In reply to comment #108)
(In reply to comment #107)
http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
the patch don't apply in 1.7.4 release today
greetings
the log http://sl1pkn07.no-ip.com/paste/view/eff543d5
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #110 from James Eder jimportal@gmail.com 2013-10-11 15:59:02 CDT --- (In reply to comment #108)
(In reply to comment #107)
http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
the patch don't apply in 1.7.4 release today
greetings
Have you tried your application without it? Blizzard's Desktop App previously required this patch but now works without it. (It still requires the patch from Bug 33947, however.)
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #111 from sl1pkn07 sl1pkn07@gmail.com 2013-10-11 16:35:20 CDT --- (In reply to comment #110)
(In reply to comment #108)
(In reply to comment #107)
http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
the patch don't apply in 1.7.4 release today
greetings
Have you tried your application without it? Blizzard's Desktop App previously required this patch but now works without it. (It still requires the patch from Bug 33947, however.)
without patch not working in GuildWars2
still need patch
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #112 from sl1pkn07 sl1pkn07@gmail.com 2013-10-11 17:36:46 CDT --- (In reply to comment #111)
(In reply to comment #110)
(In reply to comment #108)
(In reply to comment #107)
http://sprunge.us/WDKE updated for gbb2c32d.
Compiles fine & quick testing with battle.net & tera launcher shows it works. But I've done this during my class so I didn't have time to test it thoroughly.
the patch don't apply in 1.7.4 release today
greetings
Have you tried your application without it? Blizzard's Desktop App previously required this patch but now works without it. (It still requires the patch from Bug 33947, however.)
without patch not working in GuildWars2
still need patch
greetings
reverting fa0b7b7d3dfd4c3dcad1438596da9e5a7a60fff1 and da24f543f4304048a2b65cbc0deb35a27e17daf6 + apply Arnoud Willemsen patch (http://sprunge.us/WDKE) works in guildWars2
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #113 from Arnoud Willemsen mail@lynthium.com 2013-10-12 02:56:53 CDT --- Created attachment 46264 --> http://bugs.winehq.org/attachment.cgi?id=46264 SSL fix for tera/wow
Patch updated for 1.7.4
Wow still needs this to display news & game upgrades. As does TERA for it to reliably show the login screen.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #114 from sl1pkn07 sl1pkn07@gmail.com 2013-10-12 03:43:23 CDT --- (In reply to comment #113)
Created attachment 46264 [details] SSL fix for tera/wow
Patch updated for 1.7.4
Wow still needs this to display news & game upgrades. As does TERA for it to reliably show the login screen.
works in guildwars2
thanks and greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
Pelz pelzigeswaldtier@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pelzigeswaldtier@gmail.com
--- Comment #115 from Pelz pelzigeswaldtier@gmail.com 2013-10-14 16:53:43 CDT --- (In reply to comment #112)
reverting fa0b7b7d3dfd4c3dcad1438596da9e5a7a60fff1 and da24f543f4304048a2b65cbc0deb35a27e17daf6 + apply Arnoud Willemsen patch (http://sprunge.us/WDKE) works in guildWars2
I reverted to 73ca9d2 (fa0b7b7 and da24f54 were undone), applied the patch and built it but my problem remains.
The Battle.net app still shows the BLZBNTBNA000003E8 (1007) error and not the news, friends lists etc.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #116 from sl1pkn07 sl1pkn07@gmail.com 2013-10-14 23:26:11 CDT --- (In reply to comment #115)
(In reply to comment #112)
reverting fa0b7b7d3dfd4c3dcad1438596da9e5a7a60fff1 and da24f543f4304048a2b65cbc0deb35a27e17daf6 + apply Arnoud Willemsen patch (http://sprunge.us/WDKE) works in guildWars2
I reverted to 73ca9d2 (fa0b7b7 and da24f54 were undone), applied the patch and built it but my problem remains.
The Battle.net app still shows the BLZBNTBNA000003E8 (1007) error and not the news, friends lists etc.
then you no need latest patch. the patch only works if you use GuildWars2
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #117 from sl1pkn07 sl1pkn07@gmail.com 2013-10-14 23:40:02 CDT --- (In reply to comment #116)
(In reply to comment #115)
(In reply to comment #112)
reverting fa0b7b7d3dfd4c3dcad1438596da9e5a7a60fff1 and da24f543f4304048a2b65cbc0deb35a27e17daf6 + apply Arnoud Willemsen patch (http://sprunge.us/WDKE) works in guildWars2
I reverted to 73ca9d2 (fa0b7b7 and da24f54 were undone), applied the patch and built it but my problem remains.
The Battle.net app still shows the BLZBNTBNA000003E8 (1007) error and not the news, friends lists etc.
then you no need latest patch. the patch only works if you use GuildWars2
mm. is not true at all. several commits added in GIT about crypt32, the latest patch (http://bugs.winehq.org/attachment.cgi?id=46264) works on up to 18556fd (1.7.4)
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #118 from Pelz pelzigeswaldtier@gmail.com 2013-10-15 06:29:46 CDT --- (In reply to comment #117)
mm. is not true at all. several commits added in GIT about crypt32, the latest patch (http://bugs.winehq.org/attachment.cgi?id=46264) works on up to 18556fd (1.7.4)
Ok, now I tried that (applied the patch on 18556fd and built wine again) but the issue remains.[1]
I am a bit new to this but I did make sure that I installed this patched version of wine and that the battle.net application is using this version. Wine builds without errors, no deps are missing. Everything seems fine. What might be going wrong here?
[1]: http://i.imgur.com/FTlv2DQ.png (Screenshot of the Battle.net app with the error message)
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #119 from sl1pkn07 sl1pkn07@gmail.com 2013-10-15 10:19:46 CDT --- (In reply to comment #118)
(In reply to comment #117)
mm. is not true at all. several commits added in GIT about crypt32, the latest patch (http://bugs.winehq.org/attachment.cgi?id=46264) works on up to 18556fd (1.7.4)
Ok, now I tried that (applied the patch on 18556fd and built wine again) but the issue remains.[1]
I am a bit new to this but I did make sure that I installed this patched version of wine and that the battle.net application is using this version. Wine builds without errors, no deps are missing. Everything seems fine. What might be going wrong here?
[1]: http://i.imgur.com/FTlv2DQ.png (Screenshot of the Battle.net app with the error message)
try GIT version without any patch. if dont work need waith to possible patch to fix
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #120 from Jacek Caban jacek@codeweavers.com 2013-10-17 09:43:23 CDT --- Created attachment 46331 --> http://bugs.winehq.org/attachment.cgi?id=46331 Proper fix
I attached a diff of my tree against current Wine Git version. It contains both patches that I send today (so the patch won't apply after they are committed) and fixes for store/context ref counting (which should finally fix this bug). I would appreciate help with testing those.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #121 from Arnoud Willemsen mail@lynthium.com 2013-10-17 10:35:31 CDT --- (In reply to comment #120)
Created attachment 46331 [details] Proper fix
I attached a diff of my tree against current Wine Git version. It contains both patches that I send today (so the patch won't apply after they are committed) and fixes for store/context ref counting (which should finally fix this bug). I would appreciate help with testing those.
I can confirm it works (at least it does for me) with Battle.net and the TERA launcher using git version g9a02c62. The regular wine log doesn't show any errors related to crypt, nor does a crypt trace show anything to take note of.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #122 from sl1pkn07 sl1pkn07@gmail.com 2013-10-17 12:46:29 CDT --- (In reply to comment #121)
(In reply to comment #120)
Created attachment 46331 [details] Proper fix
I attached a diff of my tree against current Wine Git version. It contains both patches that I send today (so the patch won't apply after they are committed) and fixes for store/context ref counting (which should finally fix this bug). I would appreciate help with testing those.
I can confirm it works (at least it does for me) with Battle.net and the TERA launcher using git version g9a02c62. The regular wine log doesn't show any errors related to crypt, nor does a crypt trace show anything to take note of.
i can conform works with Guildwars2 (Blak lion trade ingame)
greetings
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #123 from sl1pkn07 sl1pkn07@gmail.com 2013-10-17 12:46:58 CDT --- irm* XD
http://bugs.winehq.org/show_bug.cgi?id=27168
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46331|0 |1 is obsolete| |
--- Comment #124 from Jacek Caban jacek@codeweavers.com 2013-10-18 03:08:10 CDT --- Created attachment 46348 --> http://bugs.winehq.org/attachment.cgi?id=46348 Updated patch
Thanks for testing. Here is an updated diff after yesterday's commits.
http://bugs.winehq.org/show_bug.cgi?id=27168
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |9fb1e4d675043bd078552a7c0de | |8eec317473cd0 Status|NEW |RESOLVED Component|secur32 |crypt32 Resolution| |FIXED
--- Comment #125 from Jacek Caban jacek@codeweavers.com 2013-10-18 15:41:32 CDT --- Fixed in Git.
http://bugs.winehq.org/show_bug.cgi?id=27168
Felix Hellmann privat@cirk2.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |privat@cirk2.de
http://bugs.winehq.org/show_bug.cgi?id=27168
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #126 from Alexandre Julliard julliard@winehq.org 2013-10-25 12:54:59 CDT --- Closing bugs fixed in 1.7.5.
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #127 from Austin English austinenglish@gmail.com --- *** Bug 33783 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27168
--- Comment #128 from Austin English austinenglish@gmail.com --- *** Bug 33784 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org