(ITS#7761) Issue with modifying loglevel during long search operation
by mwarren＠symas.com
Full_Name: Mark Warren
Version: 2.4.38
OS: RHEL 5 x86-64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (199.190.53.83)
There is an issue where OpenLDAP will stop sending search results and fail to
update a dynamic config when the loglevel is modified during a long search
operation.
Symptoms:
* No further search results sent to client although internally the operation
continues.
* Log level change does not take effect
Cause(Via Howard):
* send_search_entry() correctly returns an error because back-config wants a
pause
* back-bdb/back-hdb ignores this error
* The entry it tried to send doesn't get sent, and it just loops back to fetch
the next entry instead of quitting
Steps to reproduce:
1. Create large sample database. 2 million entries was more than sufficient
locally.
2. Issue a search request for all entries.
3. Submit a modify request on olcLogLevel within cn=config while the above
search is still in progress.
Notes(Also via Howard):
* This is not a total hang as everything should resume after the internal search
operation finishes.
Regards,
Mark Warren
9 years, 5 months
Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------050905040301060400050300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lukas Slebodnik wrote:
> On (09/12/13 04:01), Howard Chu wrote:
>>>> Meanwhile you can refer to draft-behera-ldap-password-policy for the
>>>> specification of the response control. The control value is mandatory
>>>> for this control.
>>> If I read draft "6.2. Response Control" correctly,
>>> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2
>>> response can be sequence of "PasswordPolicyResponseValue".
>>> I think that sequence means "0 or more values"
>>
>> The sequence is required to begin with a Sequence marker.
>>
>>> In theory, there needn't be any password policy response value after control
>>> type. In this case, either my patch or your patch are wrong.
>>> Did I miss something?
>>>
>>> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
>>> the BER encoding of the following type:
>>
>> "the controlValue is the BER encoding of a Sequence." - even if the
>> sequence has zero members, it cannot be omitted.
>>
> Thank you for your explanation.
>
> I am attaching output from ldapwhoami with enabled ppolicy,
> but I am sure that problem is in the server apacheds, because there is nothing
> after controlType 1.3.6.1.4.1.42.2.27.8.5.1
> (at least Sequence marker should be after controlType)
Agreed, that looks like an ApacheDS bug.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------050905040301060400050300
Content-Type: text/plain; charset=UTF-8;
name="ldapwhoami.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ldapwhoami.log"
W3Jvb3RAdm0tMjE5IH5dIyBsZGFwd2hvYW1pIC1kNyAtRCAiY249V2lsbGlhbSBCdXNoLG91
PXBlb3BsZSxkYz1leGFtcGxlLGRjPXNrIiAtdyBqYWhvZGEuMTIzIC1IIGxkYXA6Ly92bS0x
MzcuaWRtLmxhYi5sb2NhbCAtZSBwcG9saWN5CmxkYXBfdXJsX3BhcnNlX2V4dChsZGFwOi8v
dm0tMTM3LmlkbS5sYWIubG9jYWwpCmxkYXBfY3JlYXRlCmxkYXBfdXJsX3BhcnNlX2V4dChs
ZGFwOi8vdm0tMTM3LmlkbS5sYWIubG9jYWw6Mzg5Lz8/YmFzZSkKbGRhcF9zYXNsX2JpbmQK
bGRhcF9zZW5kX2luaXRpYWxfcmVxdWVzdApsZGFwX25ld19jb25uZWN0aW9uIDEgMSAwCmxk
YXBfaW50X29wZW5fY29ubmVjdGlvbgpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVENQIHZtLTEz
Ny5pZG0ubGFiLmxvY2FsOjM4OQpsZGFwX25ld19zb2NrZXQ6IDMKbGRhcF9wcmVwYXJlX3Nv
Y2tldDogMwpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVHJ5aW5nIDEwLjM0LjQ3LjEzNzozODkK
bGRhcF9wdnRfY29ubmVjdDogZmQ6IDMgdG06IC0xIGFzeW5jOiAwCmF0dGVtcHRpbmcgdG8g
Y29ubmVjdDogCmNvbm5lY3Qgc3VjY2VzcwpsZGFwX29wZW5fZGVmY29ubjogc3VjY2Vzc2Z1
bApsZGFwX3NlbmRfc2VydmVyX3JlcXVlc3QKYmVyX3NjYW5mIGZtdCAoe2l0KSBiZXI6CmJl
cl9zY2FuZiBmbXQgKHtpKSBiZXI6CmJlcl9mbHVzaDI6IDk3IGJ5dGVzIHRvIHNkIDMKbGRh
cF93cml0ZTogd2FudD05Nywgd3JpdHRlbj05NwogIDAwMDA6ICAzMCA1ZiAwMiAwMSAwMSA2
MCAzYiAwMiAgMDEgMDMgMDQgMmEgNjMgNmUgM2QgNTcgICAwXy4uLmA7Li4uLipjbj1XICAK
ICAwMDEwOiAgNjkgNmMgNmMgNjkgNjEgNmQgMjAgNDIgIDc1IDczIDY4IDJjIDZmIDc1IDNk
IDcwICAgaWxsaWFtIEJ1c2gsb3U9cCAgCiAgMDAyMDogIDY1IDZmIDcwIDZjIDY1IDJjIDY0
IDYzICAzZCA2NSA3OCA2MSA2ZCA3MCA2YyA2NSAgIGVvcGxlLGRjPWV4YW1wbGUgIAogIDAw
MzA6ICAyYyA2NCA2MyAzZCA3MyA2YiA4MCAwYSAgNmEgNjEgNjggNmYgNjQgNjEgMmUgMzEg
ICAsZGM9c2suLmphaG9kYS4xICAKICAwMDQwOiAgMzIgMzMgYTAgMWQgMzAgMWIgMDQgMTkg
IDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAgMjMuLjAuLi4xLjMuNi4xLiAgCiAgMDA1MDog
IDM0IDJlIDMxIDJlIDM0IDMyIDJlIDMyICAyZSAzMiAzNyAyZSAzOCAyZSAzNSAyZSAgIDQu
MS40Mi4yLjI3LjguNS4gIAogIDAwNjA6ICAzMSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAKbGRhcF9yZXN1bHQg
bGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMQp3YWl0NG1zZyBsZCAweDdmYzBlODU3YmQ1MCBt
c2dpZCAxIChpbmZpbml0ZSB0aW1lb3V0KQp3YWl0NG1zZyBjb250aW51ZSBsZCAweDdmYzBl
ODU3YmQ1MCBtc2dpZCAxIGFsbCAxCioqIGxkIDB4N2ZjMGU4NTdiZDUwIENvbm5lY3Rpb25z
OgoqIGhvc3Q6IHZtLTEzNy5pZG0ubGFiLmxvY2FsICBwb3J0OiAzODkgIChkZWZhdWx0KQog
IHJlZmNudDogMiAgc3RhdHVzOiBDb25uZWN0ZWQKICBsYXN0IHVzZWQ6IE1vbiBEZWMgIDkg
MTM6MTU6MTQgMjAxMwoKCioqIGxkIDB4N2ZjMGU4NTdiZDUwIE91dHN0YW5kaW5nIFJlcXVl
c3RzOgogKiBtc2dpZCAxLCAgb3JpZ2lkIDEsIHN0YXR1cyBJblByb2dyZXNzCiAgIG91dHN0
YW5kaW5nIHJlZmVycmFscyAwLCBwYXJlbnQgY291bnQgMAogIGxkIDB4N2ZjMGU4NTdiZDUw
IHJlcXVlc3QgY291bnQgMSAoYWJhbmRvbmVkIDApCioqIGxkIDB4N2ZjMGU4NTdiZDUwIFJl
c3BvbnNlIFF1ZXVlOgogICBFbXB0eQogIGxkIDB4N2ZjMGU4NTdiZDUwIHJlc3BvbnNlIGNv
dW50IDAKbGRhcF9jaGtSZXNwb25zZUxpc3QgbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBh
bGwgMQpsZGFwX2Noa1Jlc3BvbnNlTGlzdCByZXR1cm5zIGxkIDB4N2ZjMGU4NTdiZDUwIE5V
TEwKbGRhcF9pbnRfc2VsZWN0CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCBtc2dpZCAx
IGFsbCAxCmJlcl9nZXRfbmV4dApsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgKICAwMDAwOiAg
MzAgMmIgMDIgMDEgMDEgNjEgMDcgMGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCsu
Li5hLi4gICAgICAgICAgCmxkYXBfcmVhZDogd2FudD0zNywgZ290PTM3CiAgMDAwMDogIDAx
IDAwIDA0IDAwIDA0IDAwIGEwIDFkICAzMCAxYiAwNCAxOSAzMSAyZSAzMyAyZSAgIC4uLi4u
Li4uMC4uLjEuMy4gIAogIDAwMTA6ICAzNiAyZSAzMSAyZSAzNCAyZSAzMSAyZSAgMzQgMzIg
MmUgMzIgMmUgMzIgMzcgMmUgICA2LjEuNC4xLjQyLjIuMjcuICAKICAwMDIwOiAgMzggMmUg
MzUgMmUgMzEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOC41LjEgICAg
ICAgICAgICAgCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDQzIGNvbnRlbnRzOgpyZWFk
MW1zZzogbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBtZXNzYWdlIHR5cGUgYmluZApiZXJf
c2NhbmYgZm10ICh7ZUFBKSBiZXI6CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCAwIG5l
dyByZWZlcnJhbHMKcmVhZDFtc2c6ICBtYXJrIHJlcXVlc3QgY29tcGxldGVkLCBsZCAweDdm
YzBlODU3YmQ1MCBtc2dpZCAxCnJlcXVlc3QgZG9uZTogbGQgMHg3ZmMwZTg1N2JkNTAgbXNn
aWQgMQpyZXNfZXJybm86IDAsIHJlc19lcnJvcjogPD4sIHJlc19tYXRjaGVkOiA8PgpsZGFw
X2ZyZWVfcmVxdWVzdCAob3JpZ2lkIDEsIG1zZ2lkIDEpCmxkYXBfcGFyc2VfcmVzdWx0CmJl
cl9zY2FuZiBmbXQgKHtpQUEpIGJlcjoKYmVyX3NjYW5mIGZtdCAoe2EpIGJlcjoKYmVyX3Nj
YW5mIGZtdCAofSkgYmVyOgpsZGFwX21zZ2ZyZWUKbGRhcHdob2FtaTogaW8uYzoxMDg6IGJl
cl93cml0ZTogQXNzZXJ0aW9uIGBidWYgIT0gKCh2b2lkICopMCknIGZhaWxlZC4KQWJvcnRl
ZCAoY29yZSBkdW1wZWQpCltyb290QHZtLTIxOSB+XSMK
--------------050905040301060400050300--
9 years, 5 months
Re: (ITS#7754) Unaligned MDB_DUPSORT sub-pages
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> I wrote:
>> (...)
>> A fix with a format change would be to put the padding byte in front
>> of the sub-page instead of at the end.
Sounds fine to me. back-mdb only uses even-sized keys with DUPSORT, so this
change has no impact on OpenLDAP. And most likely no one else has hit this
situation yet otherwise they'd be crashing.
> Ignore next paragraph:
>> One fix with a format change could be that the data item gets uneven
>> size too, with a padding byte in front of the sub-page.
>
> Because that's repeated as the 2nd alternative after this one:
>
>> The most general way would be to do that in all nodes with uneven-
>> sized key and even-sized data:
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com
Lukas Slebodnik wrote:
> On (09/12/13 00:59), Howard Chu wrote:
>> Lukas Slebodnik wrote:
>>> On (07/12/13 08:37), Howard Chu wrote:
>>>> lslebodn(a)redhat.com wrote:
>>>>> Full_Name: Lukas Slebodnik
>>>>> Version: 2.4.38
>>>>> OS: Fedora
>>>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz
>>>>> Submission from: (NULL) (209.132.186.34)
>>>>
>>>> Fixed now in git master.
>>>
>>> Thank you.
>>>
>>> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me
>>> I was right that ApacheDS send wrong response.
>>> Could you confirm this statement? because I am not expert in ldap protocol
>>> and I would like to file a bug to ApacheDS upstream.
>>
>> The hex dumps you included were a bit difficult to read. I couldn't
>> tell what was sent from the server vs the client and what the message
>> boundaries were.
> It is output directly from wireshark. Indented lines represent response
> from server.
>
> ldap_communication_without_PP.hexdump
> ----------------------------------------------------------------------------
> 00000000 30 5f 02 01 01 60 3b 02 01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W
> 00000010 69 6c 6c 69 61 6d 20 42 75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p
> 00000020 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc =example
> 00000030 2c 64 63 3d 73 6b 80 0a 6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1
> 00000040 32 33 a0 1d 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1.
> 00000050 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5.
> 00000060 31 1
> ^^^^^^^^
> client
>
> 00000000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a.. ......
> ^^^^^^^^
> server
>
> 00000061 30 05 02 01 02 42 00 0....B.
> ^^^^^^^^
> client
> ----------------------------------------------------------------------------
>
>> If you can reproduce the behavior using e.g.
>> ldapwhoami -d7 that would be more legible.
> output from command ldapwhoami is in the attached file screenlog.2
> but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I.
The point was to show a Bind request using the ppolicy control. The actual
WhoAmI operation was irrelevant. But you didn't specify ppolicy in your
invocation. Please read the ldapwhoami manpage.
Use -E ppolicy to use the ppolicy control, the screenlog you attached has
nothing interesting without the ppolicy traffic.
>> Meanwhile you can refer to draft-behera-ldap-password-policy for the
>> specification of the response control. The control value is mandatory
>> for this control.
> If I read draft "6.2. Response Control" correctly,
> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2
> response can be sequence of "PasswordPolicyResponseValue".
> I think that sequence means "0 or more values"
The sequence is required to begin with a Sequence marker.
> In theory, there needn't be any password policy response value after control
> type. In this case, either my patch or your patch are wrong.
> Did I miss something?
>
> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
> the BER encoding of the following type:
"the controlValue is the BER encoding of a Sequence." - even if the sequence
has zero members, it cannot be omitted.
> PasswordPolicyResponseValue ::= SEQUENCE {
> warning [0] CHOICE {
> ...snip... } OPTIONAL,
> error [1] ENUMERATED {
> ...snip... } OPTIONAL
> }
>
> Thank you very much for response.
>
> LS
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com
Lukas Slebodnik wrote:
> On (07/12/13 08:37), Howard Chu wrote:
>> lslebodn(a)redhat.com wrote:
>>> Full_Name: Lukas Slebodnik
>>> Version: 2.4.38
>>> OS: Fedora
>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz
>>> Submission from: (NULL) (209.132.186.34)
>>
>> Fixed now in git master.
>
> Thank you.
>
> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me
> I was right that ApacheDS send wrong response.
> Could you confirm this statement? because I am not expert in ldap protocol
> and I would like to file a bug to ApacheDS upstream.
The hex dumps you included were a bit difficult to read. I couldn't tell what
was sent from the server vs the client and what the message boundaries were.
If you can reproduce the behavior using e.g. ldapwhoami -d7 that would be more
legible.
Meanwhile you can refer to draft-behera-ldap-password-policy for the
specification of the response control. The control value is mandatory for this
control.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com
lslebodn(a)redhat.com wrote:
> Full_Name: Lukas Slebodnik
> Version: 2.4.38
> OS: Fedora
> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz
> Submission from: (NULL) (209.132.186.34)
Fixed now in git master.
>
> We(sssd) have an upstream ticket with crash.
> https://fedorahosted.org/sssd/ticket/2134
> But after investigation, it was not problem in sssd, but in ldap library.
>
> sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf !=
> ((void *)0)' failed.
>
> I think that problem is partially in user LDAP server, because server send wrong
> response for user binding with password policy. But on the other hand
> ldap_parse_result should not return LDAP_SUCCESS if incoming message is
> malformed, because it was a reason why 2nd ldap function
> ldap_parse_passwordpolicy_control crashed with abort.
>
> Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with
> libraries from the latest version from git repo(master branch)
>
> I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with
> client-server communication (hexdump from wireshark). 1st with enabled password
> policy on server and 2nd with disabled PP. Problem occurs only with enabled
> password policy.
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 6 months
Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com
lslebodn(a)redhat.com wrote:
> Full_Name: Lukas Slebodnik
> Version: 2.4.38
> OS: Fedora
> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz
> Submission from: (NULL) (209.132.186.34)
>
>
> We(sssd) have an upstream ticket with crash.
> https://fedorahosted.org/sssd/ticket/2134
> But after investigation, it was not problem in sssd, but in ldap library.
>
> sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf !=
> ((void *)0)' failed.
>
> I think that problem is partially in user LDAP server, because server send wrong
> response for user binding with password policy. But on the other hand
> ldap_parse_result should not return LDAP_SUCCESS if incoming message is
> malformed, because it was a reason why 2nd ldap function
> ldap_parse_passwordpolicy_control crashed with abort.
Thanks for the report, but your patch is wrong, it rejects any control with a
NULL value. Not all controls are required to have a value, so your patch would
reject otherwise valid controls.
> Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with
> libraries from the latest version from git repo(master branch)
>
> I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with
> client-server communication (hexdump from wireshark). 1st with enabled password
> policy on server and 2nd with disabled PP. Problem occurs only with enabled
> password policy.
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 6 months
Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms050205040707060002030305
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
mvohlken(a)us.ibm.com wrote:
> Do you understand my point? I make an api call to retrieve the attribut=
e
> 'countryName'. The call returns. I then go to get the value I requested=
=2E
> So I look for 'countryName' in the response. But it is not there. This
> seems broken to me.
There's nothing in LDAPv3 saying that the server has to return the same
attribute type NAME the client requested. Like it or not - the client has=
to
deal with it.
Ciao, Michael.
--------------ms050205040707060002030305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjA1MjMyOTE5WjAj
BgkqhkiG9w0BCQQxFgQUmu7U4IX5djLe1NVraSERo/ZQqcMwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAx+QmKY74wIjiSHgNUfK3vjuJ7okThwZU
L6nW+tPmk3fmAQeQ4Xuu55vZZwHTYB+BDThQx1UH5P50OM22esujOF507qW54WWQ5YOlIuni
+yE8NithSi66Q4xe3peWFRSY+5Ovv1aaeBkfvNoXR5ktKA+O8TZE9hg/NGTtQ2Dgn2YIsetC
/yoOCnjMk3QYhpjE7dOsRL+RNSuhF0Dk/suZXOxd7YhsSEtU6lHZTZVpl/5gcamDdPuXKlPS
J2GANImEIbCmAUpkzs3XP8LNCZygd3xNhT5BiJnOCKg68uakbWrkdR0r802BgVN5z5/UhdZF
A3jNquiFHIVp4ia4p4cPwgAAAAAAAA==
--------------ms050205040707060002030305--
9 years, 6 months