[Please cc: me on any replies since I'm not subscribed to the list.]
Hi,
Is there a specific process for reporting security-related bugs in Wine?
I've looked through winehq.org but haven't found any mention of such; I
just wanted to make sure I haven't overlooked anything before posting the
bug i
Thank you for your feedback. I'll adjust the tests with your comments and
I'll try to use testbot.
2013/8/8 Dan Kegel
> Minor problem:
>
> +static void test_strncpy(void)
> +{
> +size_t len = 10;
> +char *ret;
> +char dst[len + 1];
>
> Hmm. That last line is a VLA, and might not co
Hi,
On Sun, Aug 11, 2013 at 12:33 PM, Hugh McMaster
wrote:
> Jason Edmeades and I have developed a patch that handles Ctrl-C and
> Ctrl-Break events in wineconsole's cmd.exe.
>
> The patch supports interactive mode, batch contexts and both the cmd /c and
> cmd /k modes, meaning that pressing Ct
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26661
Your paranoid android
Hi,
On Sat, Aug 10, 2013 at 01:12:24PM +0900, Andrew Church wrote:
> [Please cc: me on any replies since I'm not subscribed to the list.]
>
> Hi,
>
> Is there a specific process for reporting security-related bugs in Wine?
> I've looked through winehq.org but haven't found any mention of such;
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
On Mon, Aug 12, 2013 at 10:40:48PM +0900, Andrew Church wrote:
> 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 throu
> This is awfully overcomplicated (plus I do not know how to make such a
> "global" variable in wine) so I was wondering is it OK to implement this
> differently than windows does it.
If the implementation does not have to be the same to preserve
compatibility, then you should ignore those details
Following my previous e-mail
(http://www.winehq.org/pipermail/wine-devel/2013-August/100754.html) I
have since moved from Wheezy to Sid to work around a Debian bug.
libxml2 has been updated (2.8.0+dfsg1-7+nmu1 --> 2.9.1+dfsg1-3) as a
result and introduced some new compiler warnings:
/home/ke
It seems that xmlBufPtr was renamed to xmlBufferPtr in new libxml.
On Mon, Aug 12, 2013 at 9:15 PM, Mislav Blazevic wrote:
> It seems that xmlBufPtr was renamed to xmlBufferPtr in new libxml.
>
>
>
> On Mon, Aug 12, 2013 at 9:11 PM, Ken Sharp wrote:
>
>> Following my previous e-mail (http://www
On 12/08/13 20:15, Mislav Blazevic wrote:
It seems that xmlBufPtr was renamed to xmlBufferPtr in new libxml.
It does seem that way. :-)
Or maybe :-(
On Monday, 12 August 2013 at 10:57 PM, Ruslan Kabatsayev wrote:
>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.
No problems, Ruslan. I'm not sure Ctrl-C can be intercepted when running 'wine
cmd.exe' but i
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
wrote:
> On Monday, 12 August 2013, Ruslan Kabatsayev wrote:
>>I've tried applying you
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
>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
15 matches
Mail list logo
