You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
2005 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2007 |
Jan
(3) |
Feb
(48) |
Mar
(48) |
Apr
(98) |
May
(60) |
Jun
(54) |
Jul
(20) |
Aug
(5) |
Sep
(1) |
Oct
(13) |
Nov
(1) |
Dec
(17) |
2008 |
Jan
(1) |
Feb
(4) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(16) |
May
(35) |
Jun
(19) |
Jul
(37) |
Aug
(8) |
Sep
(2) |
Oct
|
Nov
|
Dec
(7) |
2010 |
Jan
(8) |
Feb
(6) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Schmidtke <eli...@iy...> - 2009-07-01 13:23:38
|
5 Signs You Have aaa Healthy sex Life www. med82. com. Mummified Petrrified Hairless Cat |
From: declarable<sca...@gi...> - 2009-06-30 20:48:00
|
Easy Steps to Seelf Pleasure For Women www. med52. net. China song-writers decrry "unhealthy" pkop tunes |
From: Jubilee<sw...@ke...> - 2009-06-24 14:35:08
|
Having Great, Smmart Casuyal sex www . shop57 . net |
From: Beliveau <jo...@fe...> - 2009-06-18 23:12:54
|
Why You Need Zinc For aa Goood sex Life! (www meds35 net) Ex-Cop Plans Video on How too Hidde Drugs |
From: Marchuk<qua...@dv...> - 2009-06-17 19:05:17
|
South Korean CEOs too have hotline too president |
From: Raven P. <ba...@ar...> - 2009-06-12 20:38:28
|
Hi,teensy tnagelo |
From: Tarlton<mis...@co...> - 2009-06-11 00:02:05
|
Hi, my pohto attached |
From: wzdftpd <tr...@wz...> - 2008-03-21 06:37:57
|
#150: windows pasv_ip config -------------------------+-------------------------------------------------- Reporter: azp | Owner: anonymous Type: defect | Status: new Priority: major | Milestone: Component: server core | Version: Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by virdiq): * cc: pollux, JGS (added) * owner: pollux => anonymous -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/150#comment:2> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-21 06:37:35
|
#150: windows pasv_ip config -------------------------+-------------------------------------------------- Reporter: azp | Owner: pollux Type: defect | Status: new Priority: major | Milestone: Component: server core | Version: Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by virdiq): pollux, I seem to recall that you fixed this a while ago. Could you please check if this ticket can be closed? -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/150#comment:1> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-21 06:36:05
|
#154: time_to_str function is not reentrant/threadsafe -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: defect | Status: new Priority: major | Milestone: 0.9.0 Component: server core | Version: Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by virdiq): * priority: normal => major -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/154#comment:1> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-21 06:34:38
|
#154: time_to_str function is not reentrant/threadsafe -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 0.9.0 Component: server core | Version: Severity: major | Keywords: -------------------------+-------------------------------------------------- Inside wzd_misc.c, the time_to_str function is not reentrant/threadsafe. It has its own static buffer which holds a string version of the time_t sent to the function as an argument. time_to_str returns a pointer to its own static buffer... but what guarantee do we have that one thread didn't pause half way through our time->string conversion and another thread comes along and overwrites everything in the static buffer? When the first thread becomes unpaused, it'll have half of its static buffer overwritten with incorrect garbage. We should really be using the reentrant/threadsafe function localtime_r with gnucc and localtime_s with Visual Studio to avoid all our own ugly conversions. There aren't any threadsafe localtime() functions defined in the C99 standards. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/154> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-21 04:51:22
|
#123: CMake treats debug/release configuration modes in Visual Studio equally -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: pollux Type: defect | Status: closed Priority: normal | Milestone: Component: server core | Version: 0.8.1 Severity: minor | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by virdiq): * status: new => closed * resolution: => invalid Comment: I think this is invalid/fixed/expired, so I'll close this ticket for now. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/123#comment:3> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-20 17:57:35
|
#153: Remove use of primative unistd.h IO and use ISO C99 compliant functions instead -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: Component: server core | Version: Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by virdiq): Well properly using an abstraction layer is my #1 option as well. But I thought that with FILE*/fwrite/fread being C99 standard... it'd also be the best "fallback" option when the arch doesn't have better arch-specific filesystem functions. It'd work on Windows, Linux and most other architectures without any hassles as it is in the C99 standard. Of course, where an operating system like Linux supports AIO, we would want to use that instead to try and enforce strict zero-copying of data. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/153#comment:3> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-20 08:27:46
|
#153: Remove use of primative unistd.h IO and use ISO C99 compliant functions instead -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: Component: server core | Version: Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by pollux): I agree on the abstraction, but not on the fwrite part .. I really would prefer to avoid FILE* here, and keep using the POSIX functions (which will allow Asynchronous IO, use of select/poll/etc.) -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/153#comment:2> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-20 07:25:02
|
#153: Remove use of primative unistd.h IO and use ISO C99 compliant functions instead -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: Component: server core | Version: Severity: minor | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by virdiq): See this page: http://www.cs.utk.edu/~plank/plank/classes/cs360/360/notes/Cat/lecture.html For more information on the performance differences of each method for reading and writing files. If we can abstract things into wzd_file.c that allows us to use even more efficient mechanisms such as POSIX AIO, native Windows API, etc whenever called for. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/153#comment:1> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-03-20 06:46:42
|
#153: Remove use of primative unistd.h IO and use ISO C99 compliant functions instead -------------------------+-------------------------------------------------- Reporter: virdiq | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: Component: server core | Version: Severity: minor | Keywords: -------------------------+-------------------------------------------------- Primitive IO functions defined in unistd.h such as write() and read() are deprecated in the current ISO C99 standards. We should be using fwrite() and fread() as more-or-less direct replacements or better yet, convert code to use the abstracted file system layer of wzd_file.c This means that we will no longer need fd_t (it is not mentioned once in the ISO C99 standard). If using fwrite() and fread(), we use FILE instead of fd_t. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/153> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-02-26 08:01:29
|
#152: Deny uploads when drive almost full -------------------------+-------------------------------------------------- Reporter: carbonated | Owner: pollux Type: enhancement | Status: new Priority: normal | Milestone: Component: server core | Version: Severity: feature | Keywords: -------------------------+-------------------------------------------------- If the server does not deny upload if the free space on device is almost consumed, it could lead to the user wasting a lot of credits. This minor feature can be a major nuisance if not present. I suggest the threshold value should be configurable in the wzd.cfg and be set to 300MB by default. -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/152> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-02-17 09:34:23
|
#144: wzd.log has a very inconsistent format ----------------------+----------------------------------------------------- Reporter: jorgenpt | Owner: pollux Type: defect | Status: closed Priority: major | Milestone: 0.9.0 Component: backends | Version: svn Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by pollux): * status: new => closed * resolution: => fixed * milestone: => 0.9.0 Comment: This is fixed in r1920 and r1923 -- Ticket URL: <http://www.wzdftpd.net/trac/ticket/144#comment:2> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-02-16 10:43:58
|
#144: wzd.log has a very inconsistent format ----------------------+----------------------------------------------------- Reporter: jorgenpt | Owner: pollux Type: defect | Status: new Priority: major | Milestone: Component: backends | Version: svn Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by pollux): * owner: anonymous => pollux Comment: This first line is not useful, so I'll suppress it. The second should not have two timestamps - is this the output from syslog, or standard log file ? -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/144#comment:1> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-02-10 13:58:38
|
#148: login resets credits for a ratio user -------------------------+-------------------------------------------------- Reporter: carbonated | Owner: virdiq Type: defect | Status: assigned Priority: critical | Milestone: 0.9.0 Component: server core | Version: Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by virdiq): Sorry carbonated, I can't fully replicate this problem in the latest SVN. What I have noticed is that if a user on a ratio uploads a file, their credits are correct for a short while. But then after a few minutes/when they login next, the credits they gained through the upload disappear. But I have tried multiple times: 1) site adduser g1u1 qwerty g1 2) site addip g1u1 * 3) site change g1u1 ratio 5 4) site change g1u1 credits 1000000 5) site user g1u1 Then I login with the new g1u1 account and logout. Doing "site user g1u1" from the siteop session still shows a credits value of 1000000. Could you please confirm whether this problem is just isolated to credits incorrectly counting on uploads (and maybe also downloads) of files? -- Ticket URL: <https://www.wzdftpd.net/trac/ticket/148#comment:2> wzdftpd <http://www.wzdftpd.net/> wzdftpd |
From: wzdftpd <tr...@wz...> - 2008-01-31 12:48:10
|
IzE1MTogQ3JlZGl0cyBzaG91bGQgYmUgYSBzaWduZWQgaW50DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogUmVwb3J0ZXI6ICB6b25wICAgICAgICAgfCAgICAgICBPd25lcjogIHBvbGx1eA0KICAgICBU eXBlOiAgZW5oYW5jZW1lbnQgIHwgICAgICBTdGF0dXM6ICBuZXcgICANCiBQcmlvcml0eTogIG1p bm9yICAgICAgICB8ICAgTWlsZXN0b25lOiAgMC45LjAgDQpDb21wb25lbnQ6ICBzZXJ2ZXIgY29y ZSAgfCAgICAgVmVyc2lvbjogIHN2biAgIA0KIFNldmVyaXR5OiAgbWlub3IgICAgICAgIHwgICAg S2V5d29yZHM6ICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBjcmVkaXRzIGFyZSB1bnNp Z25lZCBpbnQgaW4gd3pkZnRwZC4NCiB0aGUgcHJvYmxlbSBpcyB3aGVuIGFuIHVzZXIgaGFzIG5v IGNyZWRpdHMgYW5kIGdldHMgbnVrZWQsIGhpcyBjcmVkaXRzDQogc3RheSBhdCAwLg0KIEkgdGhp bmsgaXQgc2hvdWxkIGdvIG5lZ2F0aXZlIGluIHN1Y2ggYSBjYXNlLg0KDQotLSANClRpY2tldCBV Ukw6IDxodHRwczovL3d3dy53emRmdHBkLm5ldC90cmFjL3RpY2tldC8xNTE+DQp3emRmdHBkIDxo dHRwOi8vd3d3Lnd6ZGZ0cGQubmV0Lz4NCnd6ZGZ0cGQ= |
From: wzdftpd <tr...@wz...> - 2007-12-31 10:24:36
|
IzE1MDogd2luZG93cyBwYXN2X2lwIGNvbmZpZw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9y dGVyOiAgYXpwICAgICAgICAgIHwgICAgICAgT3duZXI6ICBwb2xsdXgNCiAgICAgVHlwZTogIGRl ZmVjdCAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3ICAgDQogUHJpb3JpdHk6ICBtYWpvciAgICAg ICAgfCAgIE1pbGVzdG9uZTogICAgICAgIA0KQ29tcG9uZW50OiAgc2VydmVyIGNvcmUgIHwgICAg IFZlcnNpb246ICAgICAgICANCiBTZXZlcml0eTogIG1ham9yICAgICAgICB8ICAgIEtleXdvcmRz OiAgICAgICAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogSW4gdGhlIDAuOC4zIHdpbmRvd3MgYnVp bGQgd2hpbGUgcmVhZGluZyBwYXN2X2lwIGNvbmZpZ3VyYXRpb24gaW4NCiB3emRfY29uZmlnbG9h ZGVyLmMgaXQgc2VlbXMgZ2V0aG9zdGJ5bmFtZSgpIGlzIGZhaWwgaW4NCiBzb2NrZXRfZ2V0aXBi eW5hbWUoKSBmdW5jdGlvbi4gSSB0aGluayBiZWNhdXNlIFdpblNvY2syIGRpZCBub3QgaW5pdGFs aXplDQogeWV0LiAoV1NBU3RhcnR1cCgpIG9jY3VycyBhZnRlciB0aGUgY29uZmlnIGxvYWRpbmcp DQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHBzOi8vd3d3Lnd6ZGZ0cGQubmV0L3RyYWMvdGlja2V0 LzE1MD4NCnd6ZGZ0cGQgPGh0dHA6Ly93d3cud3pkZnRwZC5uZXQvPg0Kd3pkZnRwZA== |
From: wzdftpd <tr...@wz...> - 2007-12-22 05:57:33
|
IzgxOiByZWRvY3VtZW50IGFsbCBzaXRlIGNvbW1hbmRzIGluIHRyYWMgd2lraQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgdmlyZGlxICAgfCAgICAgICAgT3duZXI6ICB2aXJkaXEg IA0KICAgICBUeXBlOiAgdGFzayAgICAgfCAgICAgICBTdGF0dXM6ICBhc3NpZ25lZA0KIFByaW9y aXR5OiAgbWlub3IgICAgfCAgICBNaWxlc3RvbmU6ICAgICAgICAgIA0KQ29tcG9uZW50OiAgd2Vi c2l0ZSAgfCAgICAgIFZlcnNpb246ICAgICAgICAgIA0KIFNldmVyaXR5OiAgdHJpdmlhbCAgfCAg IFJlc29sdXRpb246ICAgICAgICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgfCAgDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpDaGFuZ2VzIChieSB2aXJkaXEpOg0KDQogICogc3RhdHVzOiAgbmV3ID0+ IGFzc2lnbmVkDQoNCkNvbW1lbnQ6DQoNCiBKdXN0IGFkZGVkIGRvY3VtZW50YXRpb24gZm9yIDUg bW9yZSBjb21tYW5kcy4gSXQgd291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZQ0KIGNvdWxkIGhlbHAg d2l0aCB0aGlzIHZlcnkgYm9yaW5nIHRhc2sgOikNCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cHM6 Ly93d3cud3pkZnRwZC5uZXQvdHJhYy90aWNrZXQvODEjY29tbWVudDoyPg0Kd3pkZnRwZCA8aHR0 cDovL3d3dy53emRmdHBkLm5ldC8+DQp3emRmdHBk |
From: wzdftpd <tr...@wz...> - 2007-12-22 04:22:40
|
IzE0OTogQWRtaW5zIGNhbm5vdCB1c2UgZ2l2ZSBjb21tYW5kDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogUmVwb3J0ZXI6ICBjYXJib25hdGVkICAgfCAgICAgICAgT3duZXI6ICB2aXJkaXENCiAgICAg VHlwZTogIGRlZmVjdCAgICAgICB8ICAgICAgIFN0YXR1czogIGNsb3NlZA0KIFByaW9yaXR5OiAg bm9ybWFsICAgICAgIHwgICAgTWlsZXN0b25lOiAgMC45LjAgDQpDb21wb25lbnQ6ICBzZXJ2ZXIg Y29yZSAgfCAgICAgIFZlcnNpb246ICAgICAgICANCiBTZXZlcml0eTogIG1pbm9yICAgICAgICB8 ICAgUmVzb2x1dGlvbjogIGZpeGVkIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgIHwgIA0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQ2hhbmdlcyAoYnkgdmlyZGlxKToNCg0KICAqIHN0YXR1czogIGFz c2lnbmVkID0+IGNsb3NlZA0KICAqIHJlc29sdXRpb246ICA9PiBmaXhlZA0KDQpDb21tZW50Og0K DQogVGhhbmtzIGZvciB0aGUgYnVnIHJlcG9ydCBjYXJib25hdGVkLiBIb3BlZnVsbHkgSSBmaXhl ZCB0aGlzIHByb3Blcmx5IGluDQogcjE4OTMuIFBsZWFzZSB0ZXN0IGFuZCBjb25maXJtLiBJZiBh bnkgYnVncyByZW1haW4sIHBsZWFzZSByZW9wZW4gdGhpcw0KIHRpY2tldCB3aXRoIGRldGFpbHMg YXR0YWNoZWQuDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHBzOi8vd3d3Lnd6ZGZ0cGQubmV0L3Ry YWMvdGlja2V0LzE0OSNjb21tZW50OjI+DQp3emRmdHBkIDxodHRwOi8vd3d3Lnd6ZGZ0cGQubmV0 Lz4NCnd6ZGZ0cGQ= |
From: wzdftpd <tr...@wz...> - 2007-12-20 12:28:43
|
IzE0ODogbG9naW4gcmVzZXRzIGNyZWRpdHMgZm9yIGEgcmF0aW8gdXNlcg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIFJlcG9ydGVyOiAgY2FyYm9uYXRlZCAgIHwgICAgICAgIE93bmVyOiAgdmlyZGlx ICANCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICAgIFN0YXR1czogIGFzc2lnbmVkDQog UHJpb3JpdHk6ICBjcml0aWNhbCAgICAgfCAgICBNaWxlc3RvbmU6ICAwLjkuMCAgIA0KQ29tcG9u ZW50OiAgc2VydmVyIGNvcmUgIHwgICAgICBWZXJzaW9uOiAgICAgICAgICANCiBTZXZlcml0eTog IG1ham9yICAgICAgICB8ICAgUmVzb2x1dGlvbjogICAgICAgICAgDQogS2V5d29yZHM6ICAgICAg ICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDaGFuZ2VzIChieSB2aXJkaXEpOg0K DQogICogb3duZXI6ICBwb2xsdXggPT4gdmlyZGlxDQogICogc3RhdHVzOiAgbmV3ID0+IGFzc2ln bmVkDQogICogbWlsZXN0b25lOiAgPT4gMC45LjANCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cHM6 Ly93d3cud3pkZnRwZC5uZXQvdHJhYy90aWNrZXQvMTQ4I2NvbW1lbnQ6MT4NCnd6ZGZ0cGQgPGh0 dHA6Ly93d3cud3pkZnRwZC5uZXQvPg0Kd3pkZnRwZA== |