Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#15273 closed defect (fixed)

HTTPS Link contents shown via IE cache on Windows 8

Reported by: kibmcz Owned by: datallah
Milestone: 2.10.7 Component: winpidgin (gtk)
Version: 2.10.6 Keywords: Windows 8 https file
Cc:

Description

On Windows 8 (RTM) when any https link is clicked the page is saved to the IE cache then displayed via file://.

Example


Expected: https://accounts.google.com

Actual link in browser: file:///C:/Users/<Username>/AppData/Local/Microsoft/Windows/Temporary?%20Internet%20Files/Content.IE5/Z36UNOV8/CALZC1RG

Attachments (1)

win8-notify-15273.diff (1.4 KB) - added by csalgau 6 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 6 years ago by QuLogic

  • Component changed from libpurple to winpidgin (gtk)
  • Owner set to datallah

comment:2 follow-up: Changed 6 years ago by datallah

This is odd - something must have changed about the way that IE is handling ShellExecute?(). I'm unlikely to have a Windows 8 VM any time soon, so if someone is interestd, they'll need to investigate.

comment:3 in reply to: ↑ 2 Changed 6 years ago by kibmcz

Not sure if this helps but you can get a 90 day evaluation of win8 enterprise rtm from http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx.

Replying to datallah:

This is odd - something must have changed about the way that IE is handling ShellExecute?(). I'm unlikely to have a Windows 8 VM any time soon, so if someone is interestd, they'll need to investigate.

comment:4 Changed 6 years ago by mkasu

I just played around with ShellExecute?. It seems to work correctly if I discard the line 159 in win32/gtkwin32dep.c

wsinfo.fMask |= SEE_MASK_CLASSNAME;

I'm not quite sure what this mask is doing, as I'm not that used to the Windows API.

Edit: Ok, lol, just looked it up. It doesn't use the http class anymore, if you discard the line. Tried a little bit more, it seems to work with the mask if you set lpClass to 'https' for secured links.

Last edited 6 years ago by mkasu (previous) (diff)

comment:5 Changed 6 years ago by EionRobb

removing the SEE_MASK_CLASSNAME isn't 100% correct, this just turns on auto-detect of the path which probably opens things up to problems. I've found that sending in the correct handler is more valid:

@@ -174,7 +174,10 @@
 	/* We'll allow whatever URI schemes are supported by the
 	 * default http browser.
 	 */
-	winpidgin_shell_execute(uri, "open", "http");
+	if (g_str_has_prefix(uri, "https://"))
+		winpidgin_shell_execute(uri, "open", "https");
+	else
+		winpidgin_shell_execute(uri, "open", "http");
 }
 
 #define PIDGIN_WM_FOCUS_REQUEST (WM_APP + 13)

comment:6 follow-up: Changed 6 years ago by mkasu

Thats what I meant with my edit. But yeah, also works for me.

comment:7 in reply to: ↑ 6 Changed 6 years ago by EionRobb

Replying to mkasu:

Thats what I meant with my edit. But yeah, also works for me.

Oops, sorry. Missed the edit :)

comment:8 Changed 6 years ago by jaraco

I've encountered this issue as well. Is the fix adequate? Will it be rolled into the next release?

comment:9 Changed 6 years ago by mmanley

This fix is adequate. I do have a build of Pidgin with this fix applied for people who don't want to compile themselves @ http://nasutek.org/~mmanley/custombuilds/pidgin/Pidgin-2.10.7devel-win8urlfixtstbld.7z

Also This bug seems to happen also on FTP and the like, so i did a quick and dirty patch (my build don't have this as I'm writing a cleaner way of doing it but it does at least fix this issue at hand.)

@@ -174,7 +174,10 @@
 	/* We'll allow whatever URI schemes are supported by the
 	 * default http browser.
 	 */
-	winpidgin_shell_execute(uri, "open", "http");
+	if (g_str_has_prefix(uri, "http://"))
+		winpidgin_shell_execute(uri, "open", "http");
+	else if (g_str_has_prefix(uri, "https://"))
+		winpidgin_shell_execute(uri, "open", "https");
+	else if (g_str_has_prefix(uri, "ftp://"))
+		winpidgin_shell_execute(uri, "open", "ftp");
+	// Add any additional URI Schemes here. Having it
+	// Open can allow any url scheme including file://
+	// which can be a security hole
 }
 
 #define PIDGIN_WM_FOCUS_REQUEST (WM_APP + 13)

Maybe a couple of new functions to determine the uri scheme and if its not a blacklisted scheme then run winpidgin_shell_execute?

Last edited 6 years ago by mmanley (previous) (diff)

comment:10 Changed 6 years ago by jaraco

mmanley, thanks for posting the link to the development build. Unfortunately, it appears to be buggy. I replaced my 2.10.6 install with the files from this 7z file, but it fails to connect to AIM (error establishing SSL connection) and then crashes when I close chat Windows (ones that pop up on some IRC channels).

I look forward to subsequent builds.

comment:11 Changed 6 years ago by mmanley

My mistake, I was using the latest dev code which is probably extremely buggy, I will do a rebuild with 2.10.6 stable.

EDIT: Fixed and patched on 2.10.6 and here is the patch of how I achieved it

@@ -170,12 +170,21 @@
 
 }
 
-void winpidgin_notify_uri(const char *uri) {
-	/* We'll allow whatever URI schemes are supported by the
-	 * default http browser.
-	 */
-	winpidgin_shell_execute(uri, "open", "http");
-}
+const char *winpidgin_get_uri_scheme(const char *uri) {
+	//FIXME: This was quick and dirty, there has to be a cleaner way to execute this
+	gchar **strings = g_strsplit(uri, ":", 0);
+	const char *retVal = strings[0];
+	g_strfreev(strings);
+	return retVal;
+}
+
+void winpidgin_notify_uri(const char *uri) {
+	/* We'll allow whatever URI schemes are supported by the
+	 * default http browser.
+	 */
+	const char *uriScheme = winpidgin_get_uri_scheme(uri);
+	winpidgin_shell_execute(uri, "open", uriScheme);
+}
 
 #define PIDGIN_WM_FOCUS_REQUEST (WM_APP + 13)
 #define PIDGIN_WM_PROTOCOL_HANDLE (WM_APP + 14)

and a link to the updated build http://nasutek.org/~mmanley/custombuilds/pidgin/Pidgin-2.10.6-win8urlfixtstbld.7z

Last edited 6 years ago by mmanley (previous) (diff)

comment:12 follow-up: Changed 6 years ago by datallah

Hmm... the crashing with the latest development code is concerning - it's not expected to be buggy (there haven't been all that many code changes) and I've been using it without any problems. Was it built with all the latest dependencies and etc. according to the BuildingWinPidgin page?

comment:13 in reply to: ↑ 12 Changed 6 years ago by mmanley

Replying to datallah:

Hmm... the crashing with the latest development code is concerning - it's not expected to be buggy (there haven't been all that many code changes) and I've been using it without any problems. Was it built with all the latest dependencies and etc. according to the BuildingWinPidgin page?

I built off the wrong branch, I built with whatever was the latest commit on the release-2.x.y branch.

comment:14 follow-up: Changed 6 years ago by csalgau

Unless I misunderstand, the above described crash has nothing to do with the branch. g_strsplit() creates a new array of null-terminated strings. The patch proceeds to obtain a pointer to the first string, then frees the array. There is no guarantee, and none should be provided, that after g_strfreev() returns the string is still usable. This could very well be the reason for the crash.

Changed 6 years ago by csalgau

comment:15 Changed 6 years ago by csalgau

I've attached a patch addressing my concerns, but a list of permitted schemes should probably be proposed and consulted before opening each URI. Somebody willing to commit it might also find it ​in my bitbucket patch queue.

comment:16 Changed 6 years ago by csalgau

My relevant build with this and my patch for #15381 can be found here.

Last edited 6 years ago by csalgau (previous) (diff)

comment:17 follow-up: Changed 6 years ago by jaraco

Thanks for the new build. I'm sad to report that this build does not work for me. I extracted the files and ran pidgin.exe, but I got this error message:

http://paste.jaraco.com/iBZWl

The procedure entry point gdk_window_id_destroyed could not be located in the dynamic link library C:\Program Files (x86)\pidgin-2.10.7devel-win32bin\pidgin.dll.

I tried loading pidgin.exe in dependency walker to determine what might be missing, but I only have the 64-bit dependency walker. Let me know if i can help by getting the 32-bit dependency walker or any other information.

comment:18 in reply to: ↑ 17 ; follow-ups: Changed 6 years ago by csalgau

An explanation: gdk_window_is_destroyed() was added in gtk+ 2.18. I use 2.22, Pidgin supports 2.14 and distributes 2.16. Obviously I didn't really test the build properly. Sorry about that.

I've updated the build at the above link. Please try again. It's really my first time making builds for other people. Just to make sure there are no confusions. This is not v2.10.6. I'm using head for release-2.x.y.

Last edited 6 years ago by csalgau (previous) (diff)

comment:19 in reply to: ↑ 14 Changed 6 years ago by mmanley

Replying to csalgau:

Unless I misunderstand, the above described crash has nothing to do with the branch. g_strsplit() creates a new array of null-terminated strings. The patch proceeds to obtain a pointer to the first string, then frees the array. There is no guarantee, and none should be provided, that after g_strfreev() returns the string is still usable. This could very well be the reason for the crash.

Actually my early build that crashed was on Comment 9 patch included but the Length check was a smart addition.

comment:20 in reply to: ↑ 18 ; follow-up: Changed 6 years ago by Det

Replying to csalgau:

An explanation: gdk_window_is_destroyed() was added in gtk+ 2.18. I use 2.22, Pidgin supports 2.14 and distributes 2.16. Obviously I didn't really test the build properly. Sorry about that.

I've updated the build at the above link. Please try again. It's really my first time making builds for other people. Just to make sure there are no confusions. This is not v2.10.6. I'm using head for release-2.x.y.

I don't know, if it's because of your patch but pidgin now treats has signs in links as comments.

So e.g.

http://phoronix.com/forums/showthread.php?74915-Linus-Torvalds-Switches-Back-To-KDE#post294990

becomes just (when clicking):

http://phoronix.com/forums/showthread.php?74915-Linus-Torvalds-Switches-Back-To-KDE

Last edited 6 years ago by Det (previous) (diff)

comment:21 in reply to: ↑ 20 Changed 6 years ago by csalgau

Replying to Det:

Replying to csalgau:

An explanation: gdk_window_is_destroyed() was added in gtk+ 2.18. I use 2.22, Pidgin supports 2.14 and distributes 2.16. Obviously I didn't really test the build properly. Sorry about that.

I've updated the build at the above link. Please try again. It's really my first time making builds for other people. Just to make sure there are no confusions. This is not v2.10.6. I'm using head for release-2.x.y.

I don't know, if it's because of your patch but pidgin now treats has signs in links as comments.

So e.g.

http://phoronix.com/forums/showthread.php?74915-Linus-Torvalds-Switches-Back-To-KDE#post294990

becomes just (when clicking):

http://phoronix.com/forums/showthread.php?74915-Linus-Torvalds-Switches-Back-To-KDE

I can't say I can replicate this. Not with this link, anyway. Could you please give some details? What browser are you using? Is the link showing up right in pidgin but misses the anchor after clicking?

comment:22 follow-up: Changed 6 years ago by Det

Yes, it shows up right but when clicking everything after the hash (#) is discarded.

Seems like this is a Chrome bug, though. Firefox and IE works just fine.

And btw. using the latest Stable Channel Chrome (22.0.1229.96).

Last edited 6 years ago by Det (previous) (diff)

comment:23 in reply to: ↑ 22 ; follow-up: Changed 6 years ago by csalgau

Replying to Det:

Yes, it shows up right but when clicking everything after the hash (#) is discarded.

Seems like this is a Chrome bug, though. Firefox and IE works just fine.

And btw. using the latest Stable Channel Chrome (22.0.1229.96).

It seems Chrome gets run without the anchor, but it's not specific to calling it from Pidgin. You can paste a URL such as this in Run or the start screen for the same effect. If you check the command line, you can see(or not see) that it gets run without it. I'm going to stop researching this and blame it on a faulty DDE handler. It's entirely in the command line when starting IE or Opera, so there you have it. You may wish to post a bug report on the Chromium bug tracker, if none is open already.

Last edited 6 years ago by csalgau (previous) (diff)

comment:24 in reply to: ↑ 23 Changed 6 years ago by Det

Well, thank you for your research.

comment:25 in reply to: ↑ 18 Changed 6 years ago by jaraco

Replying to csalgau:

I've updated the build at the above link. Please try again.

Hi csalgau. Thanks for rebuilding. I downloaded the link again and installed over pidgin (coincidentally on a different machine), but I still get a crash when I close the a second chat window (IRC, persistent). Here's the detail in the event log:

Faulting application name: pidgin.exe, version: 2.10.7.0, time stamp: 0x50955644 Faulting module name: libpurple.dll, version: 2.10.7.0, time stamp: 0x50955643 Exception code: 0xc0000005 Fault offset: 0x0001dcf8 Faulting process id: 0x77c Faulting application start time: 0x01cddd52a465c81b Faulting application path: C:\Program Files (x86)\Pidgin\pidgin.exe Faulting module path: C:\Program Files (x86)\Pidgin\libpurple.dll Report Id: f6ef2bea-4945-11e2-be73-005056c00008 Faulting package full name: Faulting package-relative application ID:

comment:26 follow-up: Changed 6 years ago by csalgau

I've noticed this behaviour when, under some conditions I couldn't exactly determine, I close a window with URLs I've clicked. I've tracked it a week or two ago to a corruption of a pointer in the conversion list of a window being closed, but I wasn't able to pinpoint it exactly before my debugging time ran out. I'm hoping to revisit this soon. What I can say with some certainty is that it's not a problem with my patches. It appears to be related to what was already in the tree. If you have the time, I'd like to have a more detailed description of the exact steps you take to reproduce the problem with IRC. My problems showed up irregularly with Yahoo! contacts. Thanks!

Last edited 6 years ago by csalgau (previous) (diff)

comment:27 in reply to: ↑ 26 Changed 6 years ago by jaraco

Replying to csalgau:

If you have the time, I'd like to have a more detailed description of the exact steps you take to reproduce the problem with IRC. My problems showed up irregularly with Yahoo! contacts.

In my case, it happens almost immediately. I have several channels to which I'm set to Auto-Join, so as soon as I connect, these channels open windows (about 10 of them). Usually the first thing I do is start closing the windows. I can close the first one, but consistently when I close the second, Pidgin crashes.

I've currently only tested the executable against my normal, configured environment. I think what I need to do next is start with a clean config and then add services (perhaps starting with IRC) until I can reproduce the failure again. When I have time to do that, I'll report back.

comment:28 follow-up: Changed 6 years ago by csalgau

I'm not yet clear on what change introduces this, but it appears ab10a481e30f should have been merged to release-2.x.y branch in order to solve the crash. Please try this build and see if the problem persists. In case of problems please throw in the symbols and upload the RPT file. (builds contain patch for 15381, 15273, previous crash and a New IM search change) I so wish the GDB project would add core dumps on windows.

Last edited 6 years ago by csalgau (previous) (diff)

comment:29 Changed 6 years ago by datallah

Ticket #15466 has been marked as a duplicate of this ticket.

comment:30 Changed 6 years ago by ruipgpinheiro

I posted this as #15466 but was told that this was the master ticket for ShellExecute? working differently under Windows 8. This seems to be related to this problem, and as such I thought I should post here again (I'm not 100% sure, so if this is in the wrong place or wasn't needed, I'm sorry, and feel free to remove it)

If I get an "e-mail received" message from hotmail and click "Open e-mail" or "Open all e-mails", nothing happens and the e-mail disappears from the list.

The debug log shows the following message (with personally identifying parts of the URI substituted with "[...]"):

(19:11:21) winpidgin: Error opening URI: https://login.live.com/ppsecure/md5auth.srf?[...] error: 5

Error 5 represents, of course, "Access Denied" in Windows. Running pidgin as administrator does not help.

Pasting the full URI onto a conversation window and clicking it gives the same problem. Pasting the URI as above (with the "[...]") however works. I'm not able to post the full URI since it contains login information for my account.

G-mail does not have the same problem and opens in Firefox. I've tested plenty of other URIs in conversations and I haven't been able to find any that also fails other than those automatically generated by Pidgin.

I've double checked, and Firefox is set to open all file-types through the default application screen, so that's not the problem. Typing the URI into "Start -> Run" works fine (and opens firefox).

I'm running Pidgin 2.10.6 (libpurple 2.10.6) on Windows 8 Pro, 64bits.

Thanks in advance for any help!

Last edited 6 years ago by ruipgpinheiro (previous) (diff)

comment:31 Changed 6 years ago by csalgau

Thanks for pointing this out. I noticed this myself a while ago, but I have other gripes with the new email notifications that I meant to fix before this. I'll post a patch for this soon(ish).

comment:32 Changed 6 years ago by Daniel Atallah <datallah@…>

  • Milestone set to 2.10.7
  • Resolution set to fixed
  • Status changed from new to closed

(In [c76b490587d4]):
Improve URI handling on Windows 8.

  • This isn't ideal - we now pass https, ftp and mailto URIs to their specific handlers and everything else still goes to the http handler.
  • Fixes #15273

comment:33 in reply to: ↑ 28 Changed 6 years ago by jaraco

Replying to csalgau:

Please try this build and see if the problem persists.

Confirmed - works! Thanks csalgau.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!