January 2014 - Wine-Devel - list.winehq.org

Re: spam filtering errors

by Ken Thomases

On Jan 31, 2014, at 7:59 AM, Jonas Maebe wrote: > Since the latest update of the mailing list server, a lot of mails sent to this list are wrongly classified as spam by CodeWeavers' mail server. I've already sent a mail about this to postmaster(a)codeweavers.com several months ago, but got no reply and nothing appears to have changed. > > It seems that the main culprit is the "SINGLE_HEADER_3K" spamassassin check, in combination with a very low spam score threshold (1.0). Below is an example from Stefan Dösinger's last mail (titled "dpnet patches"). > X-Spam-Flag: YES > X-Spam-Report: Spam detection software, running on the system "wine.codeweavers.com", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > the administrator of that system for details. > Content preview: Hi Alistair, A while ago I promised to have a closer look > at your dpnet patches. ItXs a bit delayed, but here are some comments. How > serious are you about dplay? Do you intend to do more work towards implementing > it, or is that just wishful thinking on my part? [...] > Content analysis details: (1.1 points, 1.0 required) > pts rule name description > ---- ---------------------- -------------------------------------------------- > 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters > 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider > (stefandoesinger[at]gmail.com) > -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% > [score: 0.0000] > 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid I do not see this in the raw email source for that same message as I received it. Would a second SpamAssassin-enabled server (mail.codeweavers.com) have stripped the first server's analysis? -Ken

Jan. 31, 2014

Re: [PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

by Pavel Shilovsky

2014-01-17 Pavel Shilovsky <piastry(a)etersoft.ru>: > This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. > > These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. > > According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why extra mount option 'sharelock' is added for switching on/off O_DENY* flags processing. It allows to avoid use of these flags on critical places (like /, /lib) and turn them on if we really want it proccessed that way. > > So, we have 3 new flags: > O_DENYREAD - to prevent other opens with read access, > O_DENYWRITE - to prevent other opens with write access, > O_DENYDELETE - to prevent delete operations > > The patchset avoids data races problem on newely created files: open with O_CREAT can return the -ESHAREDENIED error for a successfully created file if this files was locked with a sharelock by another task. Also, it turns flock/LOCK_MAND capability off for mounts with 'sharelock' option. This lets not mix one share reservation approach with another. > > Patches #1, #2 and #3 add O_DENY* flags to fcntl and implement VFS part. A patch #4 is related to CIFS client changes, #5 -- NFSD, #6 and #7 describe NFSv4 client parts. > > The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: > http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… > > The future part of open man page patch: > > ----- > O_DENYREAD, O_DENYWRIYE, O_DENYDELETE - used to inforce a mandatory share reservation scheme of the file access. If these flag is passed, the open fails with -ESHAREDENIED in following cases: > 1) if O_DENYREAD flag is specified and there is another open with READ access to the file; > 2) if O_DENYWRITE flag is specified and there is another open with WRITE access to the file; > 3) if READ access is requested and there is another open with O_DENYREAD flags; > 4) if WRITE access is requested and there is another open with O_DENYWRITE flags. > > If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ESHAREDENIED untill this open is closed. Now this flag is processed by VFS and CIFS filesystem. NFS returns -EINVAL for opens with this flag. > > This mechanism is done through flocks. If O_DENY* flags are specified, flock syscall is processed after the open. The share modes are translated into flock according the following rules: > 1) !O_DENYREAD -> LOCK_READ | LOCK_MAND > 2) !O_DENYWRITE -> LOCK_WRITE | LOCK_MAND > 3) !O_DENYDELETE -> LOCK_DELETE | LOCK_MAND > ----- > > Pavel Shilovsky (7): > VFS: Introduce new O_DENY* open flags > VFS: Add O_DENYDELETE support for VFS > locks: Disable LOCK_MAND support for MS_SHARELOCK mounts > CIFS: Add O_DENY* open flags support > NFSD: Pass share reservations flags to VFS > NFSv4: Add deny state handling for nfs4_state struct > NFSv4: Add O_DENY* open flags support > > arch/alpha/include/uapi/asm/errno.h | 2 + > arch/alpha/include/uapi/asm/fcntl.h | 3 + > arch/mips/include/uapi/asm/errno.h | 2 + > arch/parisc/include/uapi/asm/errno.h | 2 + > arch/parisc/include/uapi/asm/fcntl.h | 3 + > arch/sparc/include/uapi/asm/errno.h | 2 + > arch/sparc/include/uapi/asm/fcntl.h | 3 + > fs/cifs/cifsacl.c | 2 + > fs/cifs/cifsfs.c | 2 +- > fs/cifs/cifsglob.h | 17 +- > fs/cifs/cifssmb.c | 2 +- > fs/cifs/dir.c | 6 + > fs/cifs/file.c | 20 ++- > fs/cifs/inode.c | 12 +- > fs/cifs/link.c | 2 + > fs/cifs/netmisc.c | 2 +- > fs/cifs/smb1ops.c | 3 + > fs/cifs/smb2inode.c | 1 + > fs/cifs/smb2maperror.c | 2 +- > fs/cifs/smb2ops.c | 6 + > fs/cifs/smb2pdu.c | 2 +- > fs/fcntl.c | 5 +- > fs/locks.c | 161 ++++++++++++++++-- > fs/namei.c | 56 +++++- > fs/nfs/dir.c | 39 ++++- > fs/nfs/inode.c | 8 +- > fs/nfs/internal.h | 3 +- > fs/nfs/nfs4_fs.h | 83 ++++++++- > fs/nfs/nfs4file.c | 8 +- > fs/nfs/nfs4proc.c | 310 +++++++++++++++++++++++----------- > fs/nfs/nfs4state.c | 65 ++++--- > fs/nfs/nfs4super.c | 9 +- > fs/nfs/nfs4xdr.c | 21 ++- > fs/nfs/super.c | 7 +- > fs/nfsd/nfs4state.c | 46 ++++- > fs/nfsd/nfsproc.c | 1 + > fs/proc_namespace.c | 1 + > include/linux/fs.h | 15 ++ > include/linux/nfs_fs.h | 5 +- > include/linux/nfs_xdr.h | 1 + > include/uapi/asm-generic/errno.h | 2 + > include/uapi/asm-generic/fcntl.h | 12 ++ > include/uapi/linux/fs.h | 1 + > 43 files changed, 789 insertions(+), 166 deletions(-) > > -- > 1.7.10.4 > Any other thoughts/reviews on this patchset? -- Best regards, Pavel Shilovsky.

Jan. 31, 2014

Re: spam filtering errors

by Jeremy Newman

Strange. They must have changed some config options, or the file has moved since Squeeze. I'll look into it and get it a bit less strict. -Newman On Fri 31 Jan 2014 07:59:21 AM CST, Jonas Maebe wrote: > Since the latest update of the mailing list server, a lot of mails > sent to this list are wrongly classified as spam by CodeWeavers' mail > server. I've already sent a mail about this to > postmaster(a)codeweavers.com several months ago, but got no reply and > nothing appears to have changed. > > It seems that the main culprit is the "SINGLE_HEADER_3K" spamassassin > check, in combination with a very low spam score threshold (1.0). > Below is an example from Stefan Dösinger's last mail (titled "dpnet > patches").

Jan. 31, 2014

spam filtering errors

by Jonas Maebe

Hi, Since the latest update of the mailing list server, a lot of mails sent to this list are wrongly classified as spam by CodeWeavers' mail server. I've already sent a mail about this to postmaster(a)codeweavers.com several months ago, but got no reply and nothing appears to have changed. It seems that the main culprit is the "SINGLE_HEADER_3K" spamassassin check, in combination with a very low spam score threshold (1.0). Below is an example from Stefan Dösinger's last mail (titled "dpnet patches"). Jonas X-Spam-Flag: YES X-Spam-Report: Spam detection software, running on the system "wine.codeweavers.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Alistair, A while ago I promised to have a closer look at your dpnet patches. ItXs a bit delayed, but here are some comments. How serious are you about dplay? Do you intend to do more work towards implementing it, or is that just wishful thinking on my part? [...] Content analysis details: (1.1 points, 1.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefandoesinger[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

Jan. 31, 2014

dpnet patches

by Stefan Dösinger

Hi Alistair, A while ago I promised to have a closer look at your dpnet patches. It’s a bit delayed, but here are some comments. How serious are you about dplay? Do you intend to do more work towards implementing it, or is that just wishful thinking on my part? http://source.winehq.org/patches/data/101857: The entire patch doesn’t do all that much, I think it’s best to hold of on that change until the function is meaningfully implemented - unless having a proper return value helps you in some way I’m missing. > + void *buffer = malloc(256); Please use HeapAlloc / HeapFree. http://source.winehq.org/patches/data/101856: > +DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); Isn’t that defined somewhere already? Do you need GUID_NULL to signal an uninitialized GUID? Is there a reason why setting the pointer to NULL doesn’t work? > -IMPORTS = dpnet ole32 > +IMPORTS = ole32 I’m not sure about this one, but winetest can automatically skip tests if the tested DLL doesn’t exist. It might use the imported libraries for that, or maybe just the name of the test. In the former case I think you want to keep the dpnet import. http://source.winehq.org/patches/data/101855: http://source.winehq.org/patches/data/101854: Did you think about sharing code between IDirectPlay8Peer and IDirectPlay8Server? The interfaces themselves have no relationship, but their methods are similar. http://source.winehq.org/patches/data/101853: > +typedef struct IDirectPlay8ClientImpl > +{ > + IDirectPlay8Client IDirectPlay8Client_iface; > + LONG ref; > +} IDirectPlay8ClientImpl; Are you sure you want to move the definition out of the library-wide header? If that works out ok it’s great, but you may need something other than the public interface in some other files in this library. I recommend to work without the typedef, but that should be changed in a separate patch. > - ULONG refCount = InterlockedIncrement(&This->ref); > + ULONG ref = InterlockedIncrement(&This->ref); > - TRACE("(%p)->(ref before=%u)\n", This, refCount - 1); > + TRACE("(%p) ref=%d\n", This, ref); ULONG is unsigned, you have to use %u. http://source.winehq.org/patches/data/101852 > + 'DPNSPModemModem' > + { > + val 'Friendly Name' = s 'Modem Connection For DirectPlay' > + val 'GUID' = s '{6D4A3650-628D-11D2-AE0F-006097B01411}' > + } > + > + 'DPNSPModemSerial' > + { > + val 'Friendly Name' = s 'Serial Connection For DirectPlay' > + val 'GUID' = s '{743B5D60-628D-11D2-AE0F-006097B01411}' > + } I know that those always exist on Windows, but wouldn’t it be better to not advertise them until we have an actual implementation? I think advertising DPNSPWinsockTCP alone should be ok for the start.

Jan. 31, 2014

Re: user32/tests: Don't compare boolean expressions with TRUE or FALSE

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4560 Your paranoid android. === wxppro (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0005013E fg 00030052 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === wvista (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000602B4 fg 00020222 in hook HCBT_ACTIVATE === w2008s64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000600F0 fg 0001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w2008s64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00000000000600F0 fg 000000000001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000 === w7pro64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0000000000060106 fg 0000000000010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000

Jan. 31, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Henri Verbeet

On 31 January 2014 09:45, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > Without glPointParameter() calls I don't have those errors after > "[snip repeating messages]", but still do have CopyTexSubImage ones > (although I didn't notice such a serious slowdown as was before; and > these have also been before bisected wine commit). If the CopyTexSubImage ones aren't repeating after initial loading, they may be from the wined3d GL quirk detection code or the FBO caps detection code, in which case they would be harmless.

Jan. 31, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Ruslan Kabatsayev

On Fri, Jan 31, 2014 at 12:38 PM, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 30 January 2014 22:22, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >>> I don't know about the extend this card support pixel shaders. There >>> may be a way for the driver and/or wine to work without falling back >>> to software. But overall I disagree with the premise of this patch. >>> There's a point in shipping a < GL 2.0 driver for hardware that just >>> doesn't support GL 2.0. But there is no point in requiring the >>> application to magically know if the driver's GL 2.0 is really 2.0 or >>> just something rigged with software fallback mines. >>> >>> Can you file a Mesa bug about this issue? I think we should ask the >>> Mesa devs about their opinion. >>> >> I don't know if that's specifically the issue here, but GL 2.0 also >> introduced point sprite coordinate origin switching. We need that when >> rendering offscreen, and I seem to recall i915 hitting a software >> fallback for that. Without GL 2.0 we'd just render incorrectly >> instead. It should be easy enough to rule that out by commenting out >> the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call >> in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when >> investigating these kinds of things. > > Indeed, you're right. If I return psorigin() before any GL calls are > made (first one, not NV one is effective, btw), then it works fast > enough. Now, as to INTEL_DEBUG. Here's the output: intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_RGB565 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_RGB565 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_ARGB1555 intelCopyTexSubImage - fallback to swrast intelReadPixels: fallback to swrast intel_copy_texsubimage mismatched formats MESA_FORMAT_ARGB8888, MESA_FORMAT_ARGB4444 intelCopyTexSubImage - fallback to swrast [snip repeating messages] ENTER FALLBACK 100000: point sprite coord origin Mapping a busy BO, causing a stall on the GPU. trace:fps:glxdrv_SwapBuffers @ approx 0.04fps, total 0.04fps trace:fps:swapchain_gl_present 0x1a7ff8 @ approx 0.04fps ENTER FALLBACK 100000: point sprite coord origin Mapping a busy BO, causing a stall on the GPU. trace:fps:glxdrv_SwapBuffers @ approx 0.22fps, total 0.44fps trace:fps:swapchain_gl_present 0x1a7ff8 @ approx 0.22fps Mapping a busy BO, causing a stall on the GPU. Without glPointParameter() calls I don't have those errors after "[snip repeating messages]", but still do have CopyTexSubImage ones (although I didn't notice such a serious slowdown as was before; and these have also been before bisected wine commit).

Jan. 31, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Ruslan Kabatsayev

On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 30 January 2014 22:22, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> I don't know about the extend this card support pixel shaders. There >> may be a way for the driver and/or wine to work without falling back >> to software. But overall I disagree with the premise of this patch. >> There's a point in shipping a < GL 2.0 driver for hardware that just >> doesn't support GL 2.0. But there is no point in requiring the >> application to magically know if the driver's GL 2.0 is really 2.0 or >> just something rigged with software fallback mines. >> >> Can you file a Mesa bug about this issue? I think we should ask the >> Mesa devs about their opinion. >> > I don't know if that's specifically the issue here, but GL 2.0 also > introduced point sprite coordinate origin switching. We need that when > rendering offscreen, and I seem to recall i915 hitting a software > fallback for that. Without GL 2.0 we'd just render incorrectly > instead. It should be easy enough to rule that out by commenting out > the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call > in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when > investigating these kinds of things. Indeed, you're right. If I return psorigin() before any GL calls are made (first one, not NV one is effective, btw), then it works fast enough.

Jan. 31, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Ruslan Kabatsayev

On Fri, Jan 31, 2014 at 1:22 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-01-27 21:14, schrieb Ruslan Kabatsayev: >> Bisection gives this (with Mesa $(git >> describe)=snb-magic-15798-g4df1b98): >> 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit >> commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri >> Verbeet <hverbeet(a)codeweavers.com> Date: Wed Jul 18 21:32:34 2012 >> +0200 >> >> wined3d: Enable "AlwaysOffscreen" by default. >> >> :040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb >> 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls > Does the GPU support GL_ARB_depth_texture? If not this is potentially > a duplicate of bug 21708. According to glxinfo with Mesa before bad commits, it does support it. Also, there seem to have been some commits back in 2011 which worked with it, so I suppose it does. > >> 1) The one making wine 1.5.17 slow: >> 97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit >> commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt >> <eric(a)anholt.net> Date: Wed Apr 17 13:55:08 2013 -0700 >> >> i915: Always enable GL 2.0 support. >> >> There's no point in shipping a non-GL2 driver today. > I don't know about the extend this card support pixel shaders. There > may be a way for the driver and/or wine to work without falling back > to software. But overall I disagree with the premise of this patch. > There's a point in shipping a < GL 2.0 driver for hardware that just > doesn't support GL 2.0. But there is no point in requiring the > application to magically know if the driver's GL 2.0 is really 2.0 or > just something rigged with software fallback mines. > > Can you file a Mesa bug about this issue? I think we should ask the > Mesa devs about their opinion. Done: https://bugs.freedesktop.org/show_bug.cgi?id=74263 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJS6sKnAAoJEN0/YqbEcdMwTBsP/RpDjFuVxxv8+0LvkdT+LH62 > 9q/PfdsxBGQLCBpfJtuNjLP/2fsZ49SNs4cVY5tEj0FCU9lG8o14tPakBNfvxjXJ > R4TE6ENzSZuv2pxilG5FS3ZGMks5bKQL6lcOjBmo3QPypHNZHtu0P9b6SotvWSrU > VObpkayQGcY+hRgGvIABKvdtyJVXVeDGwbRbu+OKpFQZC27NhVx/V6lzkcBTHoAo > K2OXuLLn7ESE9YtYNewaf4l7n5BHn/Dm2GDtSdsEFbpmyO0NtWLDqLHormz7W0Wz > GPgFRgMs3/k9j+8MpT+UmbtFxgnT22afHE3f0TkS0yE145JdG5NHYuRQNUwjN5d+ > dGZP05J5KiG8CDACDiNOhxDlx3sRDCCRvHSbjH6Ob3wz7ns2KK3kwHkvmMCwTjE3 > AxB4bXxXzjr+LMUaeoRog0loF9mikDvLdDfejq9xGP68KIjisAzpH4rKkrMBESAc > VSpn373igEcoGO19SyQwrmlRnvXzM1ewgrG4XetsmhYy7JwCZH5+x07o/FMw9mKV > atV2CWqU4aTF5NKfzu1V0ys4GrtbGGvPsMuXyhq20G2q+t8xOKT/ARCGX9w6rQGX > jhr0QnaCgziQxGeQ+WRTcL76uzc231QMH/EGZujfuiZKenutVqnnHrNrxLPxcDqO > fxPnD37dUw4QnTZbLdzA > =iPQ/ > -----END PGP SIGNATURE-----

Jan. 31, 2014