Re: [1/2] cmd: Add handler support for Ctrl-C and Ctrl-Break events
Hi Hugh, You're right, I had to run cmd via wineconsole, and I tried it before with plain wine. OK, this way your patches do indeed work. Thanks. Regards, Ruslan On Mon, Aug 12, 2013 at 4:18 PM, Hugh McMaster hugh.mcmas...@masterindexing.com wrote: On Monday, 12 August 2013, Ruslan Kabatsayev wrote: I've tried applying your both patches, and it appears that Ctrl+C at cmd prompt still closes cmd, although pressing it while dir /s /w is running works as expected. Hi Ruslan, I've just tested the Ctrl-C patches on the most recent version of Wine available from the Git repository. After patching, compiling and installing, I found no problems with either of the patches as you described. Ctrl-C did nothing when cmd.exe was open and no command was running. To be clear, I was running cmd.exe via wineconsole in Linux Mint 14: 1. wineconsole cmd.exe 2. Press Ctrl-C -- cmd.exe remains open. But if you run cmd.exe via wine itself, the terminal will terminate cmd.exe when Ctrl-C is pressed. 1. wine cmd.exe 2. Press Ctrl-C -- returned to terminal prompt. I hope this helps. If the patch still doesn't seem to work correctly, please let me know what operating system you use, and I'll run further tests. Hugh
Re: Process for reporting security bugs?
Hi Marcus, If it is not a high severe issue you can also just mail this mailinglist here (wine-devel). Thanks for the info. As it turns out, it's an already-known issue (unixfs allows full host filesystem access through Windows APIs even if there's no equivalent dosdevices link -- reported as http://bugs.winehq.org/show_bug.cgi?id=22450) so I just added a comment onto the bug. Thanks, --Andrew Church achu...@achurch.org http://achurch.org/
Re: Process for reporting security bugs?
Depending on what attack scenario you envision, disabling unixfs is not enough. If you want to avoid actually executed malware from accessing the UNIX fs directly, you are out of luck as the malware could just do systemcalls itself (int 0x80 on x86 for instance). Yup, I'm aware of that -- if I'm going to run potentially malicious code I'll run it in a VM. (: My concern is more for cases like otherwise well-behaved programs that passively report to some remote server what they see, such as when listing folders via the shell interface -- ideally I'd like to limit what they see without the overhead of setting up a full VM. Might it be worth adding a note about both unixfs and the syscall issue to the documentation? The only reference I found to host filesystem access is under section 4.1.4 Drive Settings. Maybe add some text like: Wine also provides a Windows share which allows modern applications to access native Unix paths even without a drive mapping. This will show up as / in file dialogs. Note that removing the default z: drive mapping will NOT prevent Windows applications from reading your entire filesystem! In addition to the Windows share, malicious programs could detect that they are running under Wine and execute native Linux system calls to get around any restrictions imposed by Wine. Consider running programs you don't trust in a virtual machine instead. Just a thought, --Andrew Church achu...@achurch.org http://achurch.org/
Wine Gecko repo
Hi, A few months ago, SourceForge did some deep changes in their Git (and not only) repo hosting. While doing it, the location of repos has changed (which is extremely stupid, if you ask me). The problem is that while doing the update, they also switched to their own Web interface for git. And this shiny new interface doesn't work at all for Wine Gecko repo (wine-gecko.git probably too big and complicated). See [1], it claims to be analyzing the repo, but it has been like that since the switch was done. I contacted them [2] and they are aware of the problem, but it's still not fixed. I already got some questions about outdated sources. Also, our Wiki points to this Git in a few places. I never updated those links because I was waiting for the new repo to work. I think it's time to move the repo. The question is, where should it go? - Github seems to be the choice for most project currently and it's already used by Wine Mono. - Reconsider source.winehq.org. This was not chosen due to account management overhead, but that's the only way to avoid problems similar to recent Sourceforge one (Github nor anyone else is going to give us any guarantees) - Other ideas? I'd appreciate opinions. Thanks, Jacek [1] https://sourceforge.net/p/wine/wine-gecko/ci/master/tree/ [2] https://sourceforge.net/p/forge/site-support/4299/
Re: Process for reporting security bugs?
On Mon, 12 Aug 2013 23:29:51 JST achurch+wine-de...@achurch.org (Andrew Church) wrote: Note that removing the default z: drive mapping will NOT prevent Windows applications from reading your entire filesystem! In addition to the Windows share, malicious programs could detect that they are running under Wine and execute native Linux system calls to get around any restrictions imposed by Wine. Consider running programs you don't trust in a virtual machine instead. Already in the FAQ: 11.2. How good is Wine at sandboxing Windows apps? Wine does not sandbox in any way at all. When run under Wine, a Windows app can do anything your user can. Wine does not (and cannot) stop a Windows app directly making native syscalls, messing with your files, altering your startup scripts, or doing other nasty things. You need to use AppArmor, SELinux or some type of virtual machine if you want to properly sandbox Windows apps. -- Rosanne DiMesio dime...@earthlink.net
Re: Wine Gecko repo
On 13 August 2013 12:28, Jacek Caban ja...@codeweavers.com wrote: The question is, where should it go? - Github seems to be the choice for most project currently and it's already used by Wine Mono. - Reconsider source.winehq.org. This was not chosen due to account management overhead, but that's the only way to avoid problems similar to recent Sourceforge one (Github nor anyone else is going to give us any guarantees) - Other ideas? I'd appreciate opinions. I'm not much of a fan of github in general, and I think it's a bit awkward that Wine Gecko and Wine Mono aren't available from WineHQ, so I'd be in favour of hosting it at source.winehq.org. If account management is the issue, perhaps we could have a setup where Alexandre pulls from from Vincent and you and pushes to those repositories, but then perhaps that's worse in terms of overhead.
wine-bugs change?
Hi all, I've been subscribed to the lists for several years now, archiving all of the conversations in case a situation ever arises where a backup copy is needed. I've had a filter setup in gmail for wine-bugs that has worked perfectly fine for a long time now, but over the last couple of days, I've noticed that all emails sent to or from wine-bugs are now being directed to my inbox in addition to the folder I have the filter setup for. I'm planning on contacting Google as well, but thought I should cover all of the bases by asking here if there have been any changes made to that list specifically that might have caused the filter to not work. I've tried editing the filter so that I can see what messages it searches for, and it appears to be working properly, in that it appears to locate the emails I have the filter setup for, including those that are currently in both my inbox and the folder I specified to have them moved to, so it could be that there is an issue with the Skip Inbox setting of the filter, specifically. But again, I thought I would ask (because Google will and I'll need to have an answer for them) what changes, if any, have been made recently on the mailman side of things. Thank you, Thomas
Re: wine-bugs change?
On Tue, Aug 13, 2013 at 12:14 PM, Thomas Spear speeddy...@gmail.com wrote: Hi all, I've been subscribed to the lists for several years now, archiving all of the conversations in case a situation ever arises where a backup copy is needed. I've had a filter setup in gmail for wine-bugs that has worked perfectly fine for a long time now, but over the last couple of days, I've noticed that all emails sent to or from wine-bugs are now being directed to my inbox in addition to the folder I have the filter setup for. I'm planning on contacting Google as well, but thought I should cover all of the bases by asking here if there have been any changes made to that list specifically that might have caused the filter to not work. I've tried editing the filter so that I can see what messages it searches for, and it appears to be working properly, in that it appears to locate the emails I have the filter setup for, including those that are currently in both my inbox and the folder I specified to have them moved to, so it could be that there is an issue with the Skip Inbox setting of the filter, specifically. But again, I thought I would ask (because Google will and I'll need to have an answer for them) what changes, if any, have been made recently on the mailman side of things. My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam The same for wine-users and testbot. Thank you, Thomas Best wishes, Bruno
Re: wine-bugs change?
Mostly the same, yes. I'll try your exact match from setting and update shortly. Thanks for the info. Thank you, Thomas On Tue, Aug 13, 2013 at 10:23 AM, Bruno Jesus 00cp...@gmail.com wrote: On Tue, Aug 13, 2013 at 12:14 PM, Thomas Spear speeddy...@gmail.com wrote: Hi all, I've been subscribed to the lists for several years now, archiving all of the conversations in case a situation ever arises where a backup copy is needed. I've had a filter setup in gmail for wine-bugs that has worked perfectly fine for a long time now, but over the last couple of days, I've noticed that all emails sent to or from wine-bugs are now being directed to my inbox in addition to the folder I have the filter setup for. I'm planning on contacting Google as well, but thought I should cover all of the bases by asking here if there have been any changes made to that list specifically that might have caused the filter to not work. I've tried editing the filter so that I can see what messages it searches for, and it appears to be working properly, in that it appears to locate the emails I have the filter setup for, including those that are currently in both my inbox and the folder I specified to have them moved to, so it could be that there is an issue with the Skip Inbox setting of the filter, specifically. But again, I thought I would ask (because Google will and I'll need to have an answer for them) what changes, if any, have been made recently on the mailman side of things. My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam The same for wine-users and testbot. Thank you, Thomas Best wishes, Bruno
Re: wine-bugs change?
On 13 August 2013 17:23, Bruno Jesus 00cp...@gmail.com wrote: My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam In case anyone finds this useful, you'll generally want to filter mailing lists based on the List-Id header.
Re: wine-bugs change?
Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just the same as the issue I originally reported. Probably a gmail problem with filtering on the List-Id, as they don't have proper support for matching it in filters, only searches. Thank you, Thomas On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet hverb...@gmail.com wrote: On 13 August 2013 17:23, Bruno Jesus 00cp...@gmail.com wrote: My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam In case anyone finds this useful, you'll generally want to filter mailing lists based on the List-Id header.
Re: Wine Gecko repo
There is dedicated git hosting software (such as gitolite and gitosis - most people in #git seem to prefer gitolite) that provides account-based access to Git repositories without providing any general shell access. Perhaps something like that could be set up on source.winehq, running on a dedicated, limiter user account? Apparently you can also set a user's shell to git-shell to limit that user to the operations needed to push or fetch. Then again, if shell accounts with limited access weren't good enough then I don't know if something like this will help.
Re: wine-bugs change?
On Tue, Aug 13, 2013 at 8:57 AM, Thomas Spear speeddy...@gmail.com wrote: Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just the same as the issue I originally reported. Probably a gmail problem with filtering on the List-Id, as they don't have proper support for matching it in filters, only searches. Thank you, Thomas On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet hverb...@gmail.com wrote: On 13 August 2013 17:23, Bruno Jesus 00cp...@gmail.com wrote: My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam In case anyone finds this useful, you'll generally want to filter mailing lists based on the List-Id header. The recent Gmail changes for bulk/social network notifications/etc. email may be the cause: http://gmailblog.blogspot.com/2013/05/a-new-inbox-that-puts-you-back-in.html -- -Austin
Re: wine-bugs change?
Austin, I think you put me on the right track. I had that disabled. I enabled it and disabled it again, which caused unintended interface changes. That forced me into the main settings for the priority inbox (not gmail settings). There, I found a radio button that was enabled by default apparently about overriding filters for important messages. I disabled that. Hopefully this will no longer be a problem. Thank you, Thomas On Tue, Aug 13, 2013 at 12:38 PM, Austin English austinengl...@gmail.comwrote: On Tue, Aug 13, 2013 at 8:57 AM, Thomas Spear speeddy...@gmail.com wrote: Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just the same as the issue I originally reported. Probably a gmail problem with filtering on the List-Id, as they don't have proper support for matching it in filters, only searches. Thank you, Thomas On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet hverb...@gmail.com wrote: On 13 August 2013 17:23, Bruno Jesus 00cp...@gmail.com wrote: My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam In case anyone finds this useful, you'll generally want to filter mailing lists based on the List-Id header. The recent Gmail changes for bulk/social network notifications/etc. email may be the cause: http://gmailblog.blogspot.com/2013/05/a-new-inbox-that-puts-you-back-in.html -- -Austin
Re: gdiplus: Only clip strings if rectangle width and height are positive.
Vincent Povirk madewokh...@gmail.com wrote:
if (!(format_flags StringFormatFlagsNoClip)
-scaled_rect.Width != 1 23 scaled_rect.Height != 1 23)
+scaled_rect.Width != 1 23 scaled_rect.Height != 1 23
+rect-Width 0.0 rect-Height 0.0)
{
/* FIXME: If only the width or only the height is 0, we should
probably still clip */
rgn = CreatePolygonRgn(corners, 4, ALTERNATE);
Probably FIXME should be removed then.
--
Dmitry.
Re: gdiplus: Only clip strings if rectangle width and height are positive.
if (!(format_flags StringFormatFlagsNoClip)
-scaled_rect.Width != 1 23 scaled_rect.Height != 1 23)
+scaled_rect.Width != 1 23 scaled_rect.Height != 1 23
+rect-Width 0.0 rect-Height 0.0)
{
/* FIXME: If only the width or only the height is 0, we should
probably still clip */
rgn = CreatePolygonRgn(corners, 4, ALTERNATE);
Probably FIXME should be removed then.
I dunno, I still haven't tested that case.
