From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16304 invoked from network); 7 Feb 2022 02:21:56 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Feb 2022 02:21:56 -0000 Received: (qmail 15932 invoked by uid 550); 7 Feb 2022 02:21:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26121 invoked from network); 7 Feb 2022 01:29:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yG0YIuwXux/SLF7+LMnenIZEkX5cANwWPKB5FdQGfx0=; b=fopX/FngFJJDrZA9Bynr4GGmxD7ntLcB7fmYaOWuBK0L2Uf6Hm7sa+v5ktV3YzzNOI F0k8c0ELiMEgeUbQUbbO5dWfFQo2gwQgB0pnaRIvuOKg/FvxbkOJ+taT9wjlK7XOv2pP IXk53r2dXySaKUU8Pw49+Ln8yIvzmelEborcF6lTQz7EpQX8/AmWpXrfKVcv4zFCtsRW pJeiADH/WQvSZ7xCghz0mG3XZ3DkWi/UU/mZpJIq0T+rz0fTavmEiaszzFZ1kd8kZDri zaTFILq0NJR/Lyj7yzHgkMbcqMnzJGCHzsKnyDomQ40WgTKzHllbmWZ8lUwtNJmkjMJu 76jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yG0YIuwXux/SLF7+LMnenIZEkX5cANwWPKB5FdQGfx0=; b=FwI82tlK7ZD0wC0E9FY12zgCOxXCWmiOqW30BalclLGd+H/jKxKCSkYAlQtobbl1gW 1l238enm6hQ120rFUpZ8mxnpVA5pC2wriJ6M6EruUY1QaO8JjKpKKkDh5nJDe2BJphSz kHA48XyWY+PNTxv9g/zqD4iMWGMj82PfPGuQFdXeRN13qScrAUQO51ab5yQd8RW5lkmj 9Sap3+ydnudOdfXNEd9Os7+OBN5A84Mwh3NcH5k+tDiagWZw4OhV7A3Z0FquFSlgO8LL cOOKjFprL2uRrLeo55zCX9YPc3mrDSFQNQSrmrjIfP5bsHVcGQSNJe7duIKzEBA5nvmh 0U8w== X-Gm-Message-State: AOAM532GlTVl29pHzW/fZR8Z5GTD0JEQfsX6IU3XUAYzQ9D63/6pcKmJ 79fnJaYy9hZs4TbqBkx3b80w0bKg0QO2JRsP1FUnmUQKk78= X-Google-Smtp-Source: ABdhPJzreQzX6d+YnVhYRgCOoFe/kz7WbdpSvnRykWYubuFIVTuGpS+A3/nkLMUNWNsC36+jEI2JMhfqi2DYk8E4Rt8= X-Received: by 2002:a2e:3c03:: with SMTP id j3mr7521779lja.497.1644197370544; Sun, 06 Feb 2022 17:29:30 -0800 (PST) MIME-Version: 1.0 References: <20220206213032.GU7074@brightrain.aerifal.cx> <20220206234405.GW7074@brightrain.aerifal.cx> In-Reply-To: <20220206234405.GW7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Sun, 6 Feb 2022 20:29:16 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/mixed; boundary="0000000000003677d805d7638837" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --0000000000003677d805d7638837 Content-Type: multipart/alternative; boundary="0000000000003677d705d7638835" --0000000000003677d705d7638835 Content-Type: text/plain; charset="UTF-8" Here are illustrative logs of output and strace logs. Note that while the musl toolchain is built in a container on a much more powerful machine, this "musl_getaddrinfo_test" app is built locally on the machine with the 3.8 kernel. I ran the following to get the output on the smaller i686 machine immediately after the app is built. Apologies for the ruby code wrapping the shell commands. @musl_ver = `#{CREW_MUSL_PREFIX}/lib/libc.so 2>&1 >/dev/null | head -2 | tail -1 | awk '{print $2}'`.chomp puts 'Testing the musl resolver to see if it can resolve google.com: '.lightblue system "./musl_getaddrinfo_test google.com set_ai_family 2>&1 |tee -a /tmp/musl_#{@musl_ver}_getaddrinfo_test_google.com_set_ai_family.txt " system "./musl_getaddrinfo_test google.com 2>&1 |tee -a /tmp/musl_#{@musl_ver}_getaddrinfo_test_google.com.txt" system "strace -o /tmp/musl_#{@musl_ver}_getaddrinfo_test_google.com_set_ai_family_STRACE.txt ./musl_getaddrinfo_test google.com set_ai_family" system "strace -o /tmp/musl_#{@musl_ver}_getaddrinfo_test_google.com_STRACE.txt ./musl_getaddrinfo_test google.com" And here is the output for each run before running again via strace. Note how IPv6 addresses show up sporadically, and for 1.2.2 nothing at all shows up, but everything works fine according to the strace logs. (Strace is built against glibc 2.23.) ==> musl_1.2.0-git-17-g33338ebc_getaddrinfo_test_google.com_set_ai_family.txt <== AF_INET: 142.251.40.110 ==> musl_1.2.0-git-17-g33338ebc_getaddrinfo_test_google.com.txt <== AF_INET: 142.251.40.110 ==> musl_1.2.0-git-39-g5cf1ac24_getaddrinfo_test_google.com_set_ai_family.txt <== AF_INET: 142.251.40.142 ==> musl_1.2.0-git-39-g5cf1ac24_getaddrinfo_test_google.com.txt <== getaddrinfo: Try again ==> musl_1.2.0-git-40-g1b4e84c5_getaddrinfo_test_google.com_set_ai_family.txt <== AF_INET: 142.251.40.206 ==> musl_1.2.0-git-40-g1b4e84c5_getaddrinfo_test_google.com.txt <== AF_INET6: 2607:f8b0:4006:81f::200e AF_INET: 142.251.40.206 ==> musl_1.2.0-git-6-g2f2348c9_getaddrinfo_test_google.com_set_ai_family.txt <== AF_INET: 142.250.65.206 ==> musl_1.2.0-git-6-g2f2348c9_getaddrinfo_test_google.com.txt <== AF_INET: 142.250.65.206 ==> musl_1.2.1_getaddrinfo_test_google.com_set_ai_family.txt <== AF_INET: 142.251.40.110 ==> musl_1.2.1_getaddrinfo_test_google.com.txt <== getaddrinfo: Try again ==> musl_1.2.2_getaddrinfo_test_google.com_set_ai_family.txt <== getaddrinfo: Try again ==> musl_1.2.2_getaddrinfo_test_google.com.txt <== getaddrinfo: Try again Regards, Satadru On Sun, Feb 6, 2022 at 6:44 PM Rich Felker wrote: > On Sun, Feb 06, 2022 at 06:25:34PM -0500, Satadru Pramanik wrote: > > So here's the funny thing. These test binaries always work when run > through > > strace, sometimes even working once the binary been run after it has been > > run with strace, but tends to fail when musl is installed, and then run > for > > the first time after being built against musl. (It isn't just these test > > case binaries which have this issue. I've seen the same issue with the > test > > binaries from c_ares.) > > > > Does that ring a bell at all? Does it make sense for this to run > > correctly when run with strace (built against glibc) but have problems > when > > run w/o strace? > > Can you include that strace, even if it's for a run that worked? It > might include evidence of the cause. My best guess based on this > symptom is a buggy Docker version blocking time64 syscalls with EPERM. > > > Happy to provide binaries as a well as instructions for a container setup > > to build musl like I'm doing, which can generate such binaries. > > > > Of course this could be a buggy nameserver issue. My test setup uses an > > OpenWRT dnsmasq name server forwarding to 9.9.9.9, 8.8.8.8, and 1.1.1.1 > > > > Satadru > > > > On Sun, Feb 6, 2022 at 4:30 PM Rich Felker wrote: > > > > > On Sun, Feb 06, 2022 at 03:32:40PM -0500, Satadru Pramanik wrote: > > > > Hello, > > > > > > > > I'm a dev for the Chromebrew linux distribution, and we've been > trying to > > > > support older EOL i686 chromebooks stuck on older kernels. > > > > > > > > We have noticed that running newer versions of musl on such machines > > > breaks > > > > getaddrinfo in musl. This is a problem as we are trying to build > > > > musl-static builds of curl and git which will work on these older > > > machines. > > > > (This is really irritating since these binaries work fine in i686 > > > > containers on newer machines running newer kernels, but then fail > when > > > run > > > > on the hardware which has the older kernels.) > > > > > > The problem is almost surely not the kernel or musl but either buggy > > > nameservers or buggy Docker. Can you post the strace log of the > > > failing test case? That would quickly determine which it is. > > > > > > > I have been attempting to bisect where this happens, and have > > > > determined that the first commit which breaks DNS resolution on musl > for > > > > these older machines is > > > > > > > > https://git.musl-libc.org/cgit/musl/commit/?id=2f2348c9588d61680123bbe438db38acf5dfea4c > > > > > > This commit does not change anything in musl, which does not use those > > > macros at all internally, just the public headers. So the bisect > > > result must be wrong. > > > > > > > (I emailed you since you are the person who made that commit.) > > > > > > Please mail the list. I've CC'd it in my reply here. > > > > > > > Just applying a reverse of that commit allows musl networking to work > > > > properly up to the (2020-03-14) > 2b2c8aafce9d80f9d58652643538f4d58e82b856 > > > > commit. I'm trying newer commits with a > > > > 2f2348c9588d61680123bbe438db38acf5dfea4c reversal patch to see if > where > > > > networking breaks again, as later commits such as the (2020-05-18) > > > > fd7ec068efd590c0393a612599a4fab9bb0a8633 commit have broken ipv6 DNS > > > > resolving. > > > > > > > > I'd like to be able to get this issue fixed, as we would like to use > a > > > > newer version of musl not susceptible to CVE-2020-28928. > > > > > > > > The test case I'm using is the code at > > > > https://www.openwall.com/lists/musl/2021/07/19/1 > > > > > > > > Our implementation is here: > > > > > > > > https://github.com/skycocker/chromebrew/blob/master/packages/musl_getaddrinfo_test.rb > > > > > > > > Once I find other commits which are breaking this, I'd like to be > able to > > > > get a patch integrated into musl so that we don't have to maintain a > > > > patchset for older machines. > > > > > > > > Would that be feasible? And my apologies if this should have gone to > one > > > of > > > > the mailing lists first. I figured I should ask you since you might > have > > > > the most insight into this breaking installs. > > > > > > > > Here is the current reversal patch we are testing with: > > > > > > > > --- b/include/arpa/inet.h > > > > +++ a/include/arpa/inet.h > > > > @@ -24,6 +24,11 @@ > > > > in_addr_t inet_lnaof(struct in_addr); > > > > in_addr_t inet_netof(struct in_addr); > > > > > > > > +#undef INET_ADDRSTRLEN > > > > +#undef INET6_ADDRSTRLEN > > > > +#define INET_ADDRSTRLEN 16 > > > > +#define INET6_ADDRSTRLEN 46 > > > > + > > > > #ifdef __cplusplus > > > > } > > > > #endif > > > > --- b/include/netinet/in.h > > > > +++ a/include/netinet/in.h > > > > @@ -60,6 +60,8 @@ > > > > > > > > extern const struct in6_addr in6addr_any, in6addr_loopback; > > > > > > > > +#undef INET_ADDRSTRLEN > > > > +#undef INET6_ADDRSTRLEN > > > > #define INET_ADDRSTRLEN 16 > > > > #define INET6_ADDRSTRLEN 46 > > > > > > > > Thanks, > > > > > > > > Satadru Pramanik > > > > Dev Team > > > > Chromebrew > > > > --0000000000003677d705d7638835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are illustrative logs of output and strace logs.
=
Note that while the musl toolchain is built in a container o= n a much=C2=A0more powerful=C2=A0machine, this "musl_getaddrinfo_test&= quot; app is built locally on the machine with the 3.8 kernel.
I ran the following to get the output on the smaller i686 machine im= mediately after the app is built.
Apologies for the ruby code wra= pping the shell commands.

=C2=A0 =C2=A0 @musl_= ver =3D `#{CREW_MUSL_PREFIX}/lib/libc.so 2>&1 >/dev/null | head -= 2 | tail -1 | awk '{print $2}'`.chomp
=C2=A0 =C2=A0 puts 'Te= sting the musl resolver to see if it can resolve google.com:'.lightblue=
=C2=A0 =C2=A0 system "./musl_getaddrinfo_test google.com set_ai_family 2>&1 |tee -a /tmp/musl_#{@mus= l_ver}_getaddrinfo_test_google.com_set_ai_family.txt "
=C2=A0 =C2= =A0 system "./musl_getaddrinfo_test goog= le.com 2>&1 |tee -a /tmp/musl_#{@musl_ver}_getaddrinfo_test_goog= le.com.txt"
=C2=A0 =C2=A0 system "strace -o /tmp/musl_#{@musl_= ver}_getaddrinfo_test_google.com_set_ai_family_STRACE.txt ./musl_getaddrinf= o_test google.com set_ai_family"
= =C2=A0 =C2=A0 system "strace -o /tmp/musl_#{@musl_ver}_getaddrinfo_tes= t_google.com_STRACE.txt ./musl_getaddrinfo_test google.com"

And here is the output= for each run before running again via strace. Note how IPv6 addresses show= up sporadically, and for 1.2.2 nothing at all shows up, but everything wor= ks fine according to the strace logs. (Strace is built against glibc 2.23.)=

=3D=3D> musl_1.2.0-git-17-g33338ebc_getaddrinf= o_test_google.com_set_ai_family.txt <=3D=3D
AF_INET: 142.251.40.110
=3D=3D> musl_1.2.0-git-17-g33338ebc_getaddrinfo_test_google.com.tx= t <=3D=3D
AF_INET: 142.251.40.110

=3D=3D> musl_1.2.0-git-39= -g5cf1ac24_getaddrinfo_test_google.com_set_ai_family.txt <=3D=3D
AF_I= NET: 142.251.40.142

=3D=3D> musl_1.2.0-git-39-g5cf1ac24_getaddrin= fo_test_google.com.txt <=3D=3D
getaddrinfo: Try again

=3D=3D&g= t; musl_1.2.0-git-40-g1b4e84c5_getaddrinfo_test_google.com_set_ai_family.tx= t <=3D=3D
AF_INET: 142.251.40.206

=3D=3D> musl_1.2.0-git-40= -g1b4e84c5_getaddrinfo_test_google.com.txt <=3D=3D
AF_INET6: 2607:f8b= 0:4006:81f::200e
AF_INET: 142.251.40.206

=3D=3D> musl_1.2.0-gi= t-6-g2f2348c9_getaddrinfo_test_google.com_set_ai_family.txt <=3D=3D
A= F_INET: 142.250.65.206

=3D=3D> musl_1.2.0-git-6-g2f2348c9_getaddr= info_test_google.com.txt <=3D=3D
AF_INET: 142.250.65.206

=3D= =3D> musl_1.2.1_getaddrinfo_test_google.com_set_ai_family.txt <=3D=3D=
AF_INET: 142.251.40.110

=3D=3D> musl_1.2.1_getaddrinfo_test_g= oogle.com.txt <=3D=3D
getaddrinfo: Try again

=3D=3D> musl_1= .2.2_getaddrinfo_test_google.com_set_ai_family.txt <=3D=3D
getaddrinf= o: Try again

=3D=3D> musl_1.2.2_getaddrinfo_test_google.com.txt &= lt;=3D=3D
getaddrinfo: Try again

Regards,

Satadru

=
On Sun= , Feb 6, 2022 at 6:44 PM Rich Felker <dalias@aerifal.cx> wrote:
On Sun, Feb 06, 2022 at 06:25:34PM -0500, Satadru Prama= nik wrote:
> So here's the funny thing. These test binaries always work when ru= n through
> strace, sometimes even working once the binary been run after it has b= een
> run with strace, but tends to fail when musl is installed, and then ru= n for
> the first time after being built against musl. (It isn't just thes= e test
> case binaries which have this issue. I've seen the same issue with= the test
> binaries from c_ares.)
>
> Does that ring a bell at all? Does it make sense for this to run
> correctly when run with strace (built against glibc) but have problems= when
> run w/o strace?

Can you include that strace, even if it's for a run that worked? It
might include evidence of the cause. My best guess based on this
symptom is a buggy Docker version blocking time64 syscalls with EPERM.

> Happy to provide binaries as a well as instructions for a container se= tup
> to build musl like I'm doing, which can generate such binaries. >
> Of course this could be a buggy nameserver issue. My test setup uses a= n
> OpenWRT dnsmasq name server forwarding to 9.9.9.9, 8.8.8.8, and 1.1.1.= 1
>
> Satadru
>
> On Sun, Feb 6, 2022 at 4:30 PM Rich Felker <dalias@aerifal.cx> wrote:
>
> > On Sun, Feb 06, 2022 at 03:32:40PM -0500, Satadru Pramanik wrote:=
> > > Hello,
> > >
> > > I'm a dev for the Chromebrew linux distribution, and we&= #39;ve been trying to
> > > support older EOL i686 chromebooks stuck on older kernels. > > >
> > > We have noticed that running newer versions of musl on such = machines
> > breaks
> > > getaddrinfo in musl. This is a problem as we are trying to b= uild
> > > musl-static builds of curl and git which will work on these = older
> > machines.
> > > (This is really irritating since these binaries work fine in= i686
> > > containers on newer machines running newer kernels, but then= fail when
> > run
> > > on the hardware which has the older kernels.)
> >
> > The problem is almost surely not the kernel or musl but either bu= ggy
> > nameservers or buggy Docker. Can you post the strace log of the > > failing test case? That would quickly determine which it is.
> >
> > > I have been attempting to bisect where this happens, and hav= e
> > > determined that the first commit which breaks DNS resolution= on musl for
> > > these older machines is
> > >
> > h= ttps://git.musl-libc.org/cgit/musl/commit/?id=3D2f2348c9588d61680123bbe438d= b38acf5dfea4c
> >
> > This commit does not change anything in musl, which does not use = those
> > macros at all internally, just the public headers. So the bisect<= br> > > result must be wrong.
> >
> > > (I emailed you since you are the person who made that commit= .)
> >
> > Please mail the list. I've CC'd it in my reply here.
> >
> > > Just applying a reverse of that commit allows musl networkin= g to work
> > > properly up to the (2020-03-14) 2b2c8aafce9d80f9d58652643538= f4d58e82b856
> > > commit. I'm trying newer commits with a
> > > 2f2348c9588d61680123bbe438db38acf5dfea4c reversal patch to s= ee if where
> > > networking breaks again, as later commits such as the (2020-= 05-18)
> > > fd7ec068efd590c0393a612599a4fab9bb0a8633 commit have broken = ipv6 DNS
> > > resolving.
> > >
> > > I'd like to be able to get this issue fixed, as we would= like to use a
> > > newer version of musl not susceptible to CVE-2020-28928.
> > >
> > > The test case I'm using is the code at
> > > https://www.openwall.com/lists/musl/2= 021/07/19/1
> > >
> > > Our implementation is here:
> > >
> > https= ://github.com/skycocker/chromebrew/blob/master/packages/musl_getaddrinfo_te= st.rb
> > >
> > > Once I find other commits which are breaking this, I'd l= ike to be able to
> > > get a patch integrated into musl so that we don't have t= o maintain a
> > > patchset for older machines.
> > >
> > > Would that be feasible? And my apologies if this should have= gone to one
> > of
> > > the mailing lists first. I figured I should ask you since yo= u might have
> > > the most insight into this breaking installs.
> > >
> > > Here is the current reversal patch we are testing with:
> > >
> > > --- b/include/arpa/inet.h
> > > +++ a/include/arpa/inet.h
> > > @@ -24,6 +24,11 @@
> > >=C2=A0 in_addr_t inet_lnaof(struct in_addr);
> > >=C2=A0 in_addr_t inet_netof(struct in_addr);
> > >
> > > +#undef INET_ADDRSTRLEN
> > > +#undef INET6_ADDRSTRLEN
> > > +#define INET_ADDRSTRLEN=C2=A0 16
> > > +#define INET6_ADDRSTRLEN 46
> > > +
> > >=C2=A0 #ifdef __cplusplus
> > >=C2=A0 }
> > >=C2=A0 #endif
> > > --- b/include/netinet/in.h
> > > +++ a/include/netinet/in.h
> > > @@ -60,6 +60,8 @@
> > >
> > >=C2=A0 extern const struct in6_addr in6addr_any, in6addr_loop= back;
> > >
> > > +#undef INET_ADDRSTRLEN
> > > +#undef INET6_ADDRSTRLEN
> > >=C2=A0 #define INET_ADDRSTRLEN=C2=A0 16
> > >=C2=A0 #define INET6_ADDRSTRLEN 46
> > >
> > > Thanks,
> > >
> > > Satadru Pramanik
> > > Dev Team
> > > Chromebrew
> >
--0000000000003677d705d7638835-- --0000000000003677d805d7638837 Content-Type: application/gzip; name="musl_getaddrinfo_logs_i686.tgz" Content-Disposition: attachment; filename="musl_getaddrinfo_logs_i686.tgz" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzc0mrdj0 H4sIAAAAAAAAA+1de0/byBbnbz6FxZWuwi6k855xpGjFBdobXQoI2GdZRY4zptHmgZJAW7X97veM HUjiJI0TbNdN5kcpjjO2Z86cMz6vmSm/2skcCCClNH+x5Gjy7xN2MCOmFBac7yCMMZI7Ds++ajs7 D4Oh13ecnYE39Jr9h4Xlln3/g6L8qvMwaNdxmZTR4V1reIjl4R0FKN3w63caGt3st7pBrz7Ug2H9 rte7a+uy3+vUB3pY91r1wOu02p/Kw4/Dhc8wHSwYW9z/9Ln/ESN0BxFBqNhxUB4E2PL+P3pdr52f 3lQc6IAy4bjMUBmkb/d718siH8zIP4M/uMG0Yj7/lvx/U+KnsVT+JY3JP6Xcyn8uGMm/qDhEIFkJ VANVGHRXReGgUoE+0bvzhgiChB0iNgEz8i8O70hAKFO+m5L4r/H+pwRb+c8FMeFGZcGtcG8R1pX/ FdT/dfR/jKiV/zxg5X+7MSP/1D28436APZ+w72f/U8yt/OeBufY/I1b+twRr2/9Z+/+Ylf88YI37 7cba7/80/X9Exu1/Zv3/+WCihyvOTf+T4915ra4V/23B2vG/NOV/1v9HObbynwds/G+7MSH/JC1/ fxyrv/8xsvKfD+z7f7tRfjUY9j1fZ5kGtkr+F+NiB2FChc3/ygXP/Z9KGlj9+ubq6Pg09rJYMv4z QvD0+E8RF9b+ywX6o/YfdWlvpAfEe3rvwHn3je/2xoxgPk3xwt7fBw76KIMm4iRAzqufHIGdR68/ cH56te9UHbRrig/f97XXrHvwf+mz7g77n+rdh05D96uH+MBpeANdNw+twp2kFFoI/8BptzqtIZxB gcGBM9B3dUoacA4u8XvdIdxnUEUHTnhr08J6r9v+ZM6El9Zb3fq9d6cHpry5uNsb1u/7egDXmUIP A+012rqKv4b1dEpT9RL7UcVbzbBmejAojSonsb/vTKLqEOYyttu7193S3is99F+97w2GA6DVRf3q 5OL87M8vF/Wzo6s3p69rZ6dwfHx2cfrH6bF5Lt0N/O6wLViJHjiv69enN69P4OBkXGb8GLRrmmoK 7v3LGT+n4pz1fK/t/Bc+OCfAwEDPvXK5fOBgRJh5iPk7vrZ2fOCcHR2fm79XtctT5/wYjnp95yjo t+Ds9LVUjq/cezo9H6aGfrs30CW6qMhU2QmCAYF77UfgsG6QJdm6Xgf6v/+o+w52SRkLVQZD6LYL rND33zttL2o7Yco8RLpTTQ/PptR0KOv/Y2Rt2OpoaAVU+/h/9avTo7Ob2tvTSKS8BlM6rMghdk7P L67/vHZKrx+6/rDV6zrAzU6rc9/WHeBb3dyfvuXMDT8PH2EQ96sYhmjsUo7cAwdOdc05RhVHyCXy 60hi4UZ6WBoZjQfOtbnVyZuro7dfwsMRjaMP5xfn/zHPOnBql5dXFzcX9dpl1EONVjek3eeBNxos qs+3HBjh7PWH1ffDXhdEaz86FQ4Cra4ZYOCotIfK4c/e/lfgPLG/CulcgnIhnUsIlww9kU53m8Ne yDG3FHm3+BbBT/T/04+IhtNbCuPp89fYMJg6cN5evwGSXtfenB+dJSIdpwtoN8HgE/Qjave+126X 3n0OmlWopn4Mh9HLi7Oz2vlXGMxhsIR39H7Ip9h5LtePFdwH0fAfg36vM24sQRh+n1u0pMFwCboN wqaHQscxgc5Lt83vsPjbtBpG51Wks9H/p3T+69nZssJVw2wKBz4oNeFF0ccmigj47YtMqd1Wzx+2 S0Dzm9rF8Zvfa+fXfwEFPgzq/d6HKgV+gEO/165igsLjj/etj7pdFUBqEp74FJ1gHDM24sEP/dZQ P5qbvvvc6j3Wzeu1urfABQRsZ8q0dbdKKFBs4orb7sSX2PAGCTmI7eqP8Hq96/ce7kvfaKhp6i+7 P//8s2PK66bzoTV8Dy9aOGMtz3yxSP9PnAYyV+OfxhL9X0ga9/9wUKes/p8H0tP/R+q+VpQ1/FTU fYoLrO5TPE/dV5gJq+5bdT9VdV9xFeBs1H0ukRzrrEq6QhEq1dfkCnV+lVMIESpcujG2iCEdz8YW iZMOYwmaHZljixAJ/1AhzZGJar6FZyeqImUbYDKN+qTQVtNUjU33JK5t1EXP1aUs+/pysdKgnHBo GQ8mv56MRhN4b3W1P0w4oAjOKV/UlKl83KmxBYYAU0PzDkv4IAZmoVpOMzJNtdXeZNNEE6lRTYTV FgvoJupBu/fB6KThd+1wkA5bdw8fJ2qzF5/fCL/h/EYYK/4d3siQ4+mmAx90knqrWUVfzVCSkO5z qkopk6tXFQykCpOoonFAK6jSVE1daUjFK0r6UHOullf6HVFrdOJq/o0G9yb9Gw3eSODfiErl79+Y M8U1YoFo+HlyZ1CWyNdB+SreFBDggnpTZu1//NJw3wyWxf+4IDP53yb+a+3/7JF9/E8x2ZDpxP8o aNLFdQhoEcw6BAQYLNYhYB0CqToEGlIimo3NzQSnY8ORCoE4Jy7eGJvbkE5mY3PPkE6ZNBYxz+Zm /KyQFnc21qxpbaFt2ew0ZOKJSQ2ZeCqBhhyV2u10vHtSGt/lwGHIBfPAyJIRLmDAt0eX9cur2m9H N6dfzPHr2h+nJ+HRERT48+3Fr9cHjnmRhhw/UaHo3qYdU3cF1j75Eh79flW7mfOABbeVkgQ/btCy 89AFcpTG7YhoMtNNpjabFuBcFP9bbxrouvl/cib/TxKr/+eB7PX/QGqwuFPR/31U4ICgj+YFBDmn yur/Vv9PVf93XRWQjPL/JJlIYhOKcsqVYBuj/xvSiYzy/2KkY6D4giI3T/8X8I9vkQUQtXdLbQBE 9KQNgEIVc5kNgIqgUBMkiuq3tkgHq/r/k3n8p7FE/5cUsZn539L6/3NB6vl/DVc1VDr5f8wvsLsf Kjff3S+tum/V/XTz/wKX+Xm4+xmVyCVCylXy/3KsHBUUS7IxtgiQjqM8YhGMKkSVy+fGIii9KqQl Mp2kSG9pUotpM1IATbcU2mCKpyxGPWSzADPLAsTohVmAVDK28EFbmgWIdR5ZgGDcCLmpWYCB8VSM /RtBQBL4N6JSEzHO6C6pxDhHFUo9xkm/z8TMeXtz6JwSF1OIqIZU26KI6o+FRfHfpNsAJPEHrTH/ kwu7/m8uSH/+Z0PIZkr+nyIv98LmLvciibTzP63/J13/j3Yl8TJysbguHvsJiAsDvlLSXcH/k2fl FEN0g3JRDel0Rv6fGOkYcxWXfNb/81en+M4fIW8JJtvj/IE++ZE8P6PusZ6fDDw/T/sxvdDzwznm xHp+pmxoQvLx/EBHbqjnx2Xe5PpW8DHB+lajUoVwo0QskKkb5VmAC5pH8+L875ev/yQZj6//zyWy 6z/lgtTt/yb2dUr2v0sLbP+7dH66NyPW/rf2f7rLvfq6ofJI95agcyhJMV7B/s+zclQoojYn/8OQ zs8jF10yhaSkCs/J/6CE/FZ4FwClYCZuU/pH2Cs/jBMgYuYASzR+7IjBfY7Glxk2P3pzVDt3Slcw zj/0fe0MdQdq4vWhfs5D13v0Wm3zNt5PLEHNXCSIK1cJip9mcyztdOyu0ekRl1tHSlYpNC93pFAw TLB1pEwnIwS5LKTFGHU31JEiFWpMOFLgo7/ckTIqVQhHSsQC2eejFNiR8oNi1v/zzW3gslj/i3MZ n/8jiLT5H7kg+/n/nmxAZ6fiEFK0wBOCoHIBm3EIufCOsQ4h6xBK1SHku4Gf0f4/AqmJhaMZBjVB gl2Xps8lUZ2L7N1J1IDv6FcC9mhmtMdRnD2kcLmicp5fiZuUgOJ5lpJx3w/QkGxcTyH/eAg1Y64c w1ONmCtnKRlj7o2IkIX2amUXK0fepIkHH5PEyqNS41kSo7ukMUviqUKpz5KQ7LsuXBEG3LFkL563 ELZj4+ctvDT/P4k9uHT9Nzqz/yuj1v7LBTns/+q7lKRj/+mgwAkBOlgwIcAmBFj7L2X7r8kQyyXn HisJaht1Nybmbkincsm5J4hwgsncPZe4vCXbY1OMG7ydur9UTTYV3mnyJOGdsNR3VqRtwGXDsUj/ x/LwjgKUbvjZ5//G93/hEtv1n3NB6vm/bhBonE7+r/ILrO4rf566z1xmwz1W3U95uWfa8HhGKbYc TWS5cSQkE4ivsv9rjpWTWCDmio2xRQzp3IyyF2OkU4hgV6lZW6R/S6UopCEyFYNBPAwfbE0CcNQt hTaX4lEjl/qIxaJGwOENkmUCsBEhLxcRwiaDnjCRPAFYrZ4APGJzmwFc3EX0OFGLH7SlGcD5bKXL sKBsQzOAlWBqchE9wdwEi+hFpQqRAZzbVrprrkhnHVLzscj/Q93DO+4H2PMJy3z/r9n4r2B2/ncu yD7+28DKpenEf6UssEMIMMchpLCdEG4dQqlPCMdNkY3PhUs0keCpkKu46/JNmnONmxkZjDHSYfMS Y3TOmmu3hNMt2wBs1OBCOzQyVO7l1C7AQsokyn1Y6ntvqcuIVbc3GavO/0t//y8M2j6P7//FELb6 fx5IP/7LXSXTif+Cul/c6X5QubnT/YRV9626n/L+Xy73M1L3Y/O5BJwEbZ+sEP/Ns3IS7BGcai6q nYuY9R5nwB4Z2Vtx9pCSA9g8e4ugX4pnbK08E7GYzYiv1k3FLcW4gKH61eld2KZkN/dTgVjxWBQf ZLhJXzb3M2TdQlv/cwhBUifEKjdONU/CDMONXIZhiRRWiPDkeRJyPTZNv3fGEm8TMFLVjPJaKN9M +11xvM+hHjPZDiMGZr7/1KvP/ZWozuslraiiJq2swWnFT4lZdXeBlzNrUVqykN21/5RKkzK7z1st UBK1qdsuKO1PTieDjyJBOCEqNbHhZnSXVDbcHFUo9aUkhCpKelNeO0WksXBFSLWNX7jCIhWUx4Ef /K3Az2oRn2ksyf9CiMT3/8Rgg9r4Tx6Y6PKKc9P/5Hh3XqtrJXxbUF5r4dc047/z5J9KavM/c4GV /+1G0vd/pvJP4/t/gfkmrfzngQVzLOwAYGFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhUUD8H9qARbQAGAEA --0000000000003677d805d7638837--