From owner-freebsd-security@freebsd.org Mon Aug 31 12:35:14 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B9F89C693C for ; Mon, 31 Aug 2015 12:35:14 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6BFFA33 for ; Mon, 31 Aug 2015 12:35:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B226955.dip0.t-ipconnect.de [91.34.105.85]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t7VCcesU070073; Mon, 31 Aug 2015 14:38:40 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t7VCZ5K8018123; Mon, 31 Aug 2015 14:35:05 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t7VCYm3c005189; Mon, 31 Aug 2015 14:35:00 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201508311235.t7VCYm3c005189@fire.js.berklix.net> To: Benjamin Kaduk cc: freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sat, 29 Aug 2015 12:38:36 -0400." Date: Mon, 31 Aug 2015 14:34:47 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:35:14 -0000 Hi, Benjamin Kaduk wrote: > On Sat, 29 Aug 2015, Julian H. Stacey wrote: > > > Presumably there's no delays eg for PR, giving longer quiet periods before > > a release, slipping out bad news immediately after good. > > That seems highly unlikely. Hope so. Just considering what might add to floods. > > What else might be causing batch flooding of alerts ? > > It's an awful lot of work to actually put all the pieces together to > release security advisories; Sure, realised :-) > batching reduces the workload for the team. Batching for a common lib or tool, Yes. But alerting pre existing issues just after new releases will reduce security for all who can't spare enough time, so must skip the flood. > This is true no matter what project you look at, be it FreeBSD or MIT > Kerberos (where I am on the security team and can speak from personal > experience) or something else. This is why errata notices are delayed > until they can go out with a security advisory; it's explicitly a way to > reduce the workload on the security team. There were 5 Errata & 3 Advisories with Sender: owner-freebsd-announce@freebsd.org after 13 Aug 2015 announcement of 10.2-RELEASE. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. Subsidise contraception V. Global warming, pollution, famine, migration. From owner-freebsd-security@freebsd.org Tue Sep 1 12:02:32 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52E1B9C842B for ; Tue, 1 Sep 2015 12:02:32 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA501F9A for ; Tue, 1 Sep 2015 12:02:31 +0000 (UTC) (envelope-from des@des.no) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 63BBBC630; Tue, 1 Sep 2015 12:02:24 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 1C7F1C90; Tue, 1 Sep 2015 14:02:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Julian H. Stacey" Cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? References: <201508311235.t7VCYm3c005189@fire.js.berklix.net> Date: Tue, 01 Sep 2015 14:02:23 +0200 In-Reply-To: <201508311235.t7VCYm3c005189@fire.js.berklix.net> (Julian H. Stacey's message of "Mon, 31 Aug 2015 14:34:47 +0200") Message-ID: <86zj16cpps.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 12:02:32 -0000 "Julian H. Stacey" writes: > But alerting pre existing issues just after new releases will reduce > security for all who can't spare enough time, so must skip the flood. We can't always hold back a release, even when there are known issues. Users are waiting for it, release engineers need to move on to other work, and the very fact that we're holding it back with no explanation and no visible activity tells people that something is up. Also, how long are we going to hold it? There is *never* a point in time where the security team does not know of or suspect at least one issue in a current or upcoming release. The line has to be drawn somewhere. In the case of 10.2, the three ENs published on 2015-08-18 were for issues that would only affect a very small minority of users, and the expat issue was not raised until the release was almost complete. The ENs and SAs published on 2015-08-25 were either unknown or still in the very early investigation phase at the time of the release. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Tue Sep 1 17:35:10 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1B059C8492 for ; Tue, 1 Sep 2015 17:35:10 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51C59DDE for ; Tue, 1 Sep 2015 17:35:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B226C78.dip0.t-ipconnect.de [91.34.108.120]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t81Hccj6007353; Tue, 1 Sep 2015 19:38:39 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t81HYweh030475; Tue, 1 Sep 2015 19:34:58 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t81HYTx8026045; Tue, 1 Sep 2015 19:34:48 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201509011734.t81HYTx8026045@fire.js.berklix.net> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 01 Sep 2015 14:02:23 +0200." <86zj16cpps.fsf@nine.des.no> Date: Tue, 01 Sep 2015 19:34:29 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:35:10 -0000 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > "Julian H. Stacey" writes: > > But alerting pre existing issues just after new releases will reduce > > security for all who can't spare enough time, so must skip the flood. > > We can't always hold back a release, even when there are known issues. > Users are waiting for it, release engineers need to move on to other > work, and the very fact that we're holding it back with no explanation > and no visible activity tells people that something is up. Also, how > long are we going to hold it? There is *never* a point in time where > the security team does not know of or suspect at least one issue in a > current or upcoming release. The line has to be drawn somewhere. In > the case of 10.2, the three ENs published on 2015-08-18 were for issues > that would only affect a very small minority of users, and the expat > issue was not raised until the release was almost complete. The ENs and > SAs published on 2015-08-25 were either unknown or still in the very > early investigation phase at the time of the release. Thanks DES, I wasn't suggesting delaying releases, just how to smooth down alert waves after releases. But I had forgotten inevitably some issues that people worked hard on to meet releases, will just miss, & often continue to be worked hard on, so more than usual is ready to be announced just after release. Perhaps if core@ extend their presumed per release Thank You notes to re@ & beyond "Thanks for rolling a release", & append "Please take a short break, you deserve it + it will help minimise an immediate post release notification wave". Might that help ? Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. Subsidise contraception V. Global warming, pollution, famine, migration. From owner-freebsd-security@freebsd.org Wed Sep 2 07:29:42 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D9979C889F for ; Wed, 2 Sep 2015 07:29:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 55D56BD1 for ; Wed, 2 Sep 2015 07:29:41 +0000 (UTC) (envelope-from des@des.no) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id F1368C664; Wed, 2 Sep 2015 07:29:38 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id AFCC0D54; Wed, 2 Sep 2015 09:29:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Julian H. Stacey" Cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? References: <201509011734.t81HYTx8026045@fire.js.berklix.net> Date: Wed, 02 Sep 2015 09:29:38 +0200 In-Reply-To: <201509011734.t81HYTx8026045@fire.js.berklix.net> (Julian H. Stacey's message of "Tue, 01 Sep 2015 19:34:29 +0200") Message-ID: <86vbbtcm8t.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 07:29:42 -0000 "Julian H. Stacey" writes: > I wasn't suggesting delaying releases, just how to smooth down alert > waves after releases. So you're suggesting holding back advisories? > But I had forgotten inevitably some issues that people worked hard on > to meet releases, will just miss, & often continue to be worked hard > on, so more than usual is ready to be announced just after release. Not more than usual. There just happened to be a cluster immediately after 10.2. There was no such cluster after 10.1; three advisories were published four weeks after the release and a fourth a week after that. Besides, even if there were such a wave after each release, would it really matter? Most organizational users need weeks if not months to test a new version and plan its deployment, so that hypothetical wave would not affect them any more than any other batch of advisories. > Perhaps if core@ extend their presumed per release Thank You notes > to re@ & beyond "Thanks for rolling a release", & append "Please > take a short break, you deserve it + it will help minimise an > immediate post release notification wave". Might that help ? You want the security team to take a vacation after each release so we can maintain the illusion, at least for a couple of weeks, that there are no bugs or vulnerabilities in FreeBSD? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Wed Sep 2 14:07:42 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08CC39C8E3E for ; Wed, 2 Sep 2015 14:07:42 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86E9BFE2 for ; Wed, 2 Sep 2015 14:07:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5083CE4E.dip0.t-ipconnect.de [80.131.206.78]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t82EBIb0026246; Wed, 2 Sep 2015 16:11:19 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t82E7YeU035617; Wed, 2 Sep 2015 16:07:34 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t82E7AaX003325; Wed, 2 Sep 2015 16:07:22 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201509021407.t82E7AaX003325@fire.js.berklix.net> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 02 Sep 2015 09:29:38 +0200." <86vbbtcm8t.fsf@nine.des.no> Date: Wed, 02 Sep 2015 16:07:10 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:07:42 -0000 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > "Julian H. Stacey" writes: > > I wasn't suggesting delaying releases, just how to smooth down alert > > waves after releases. > > So you're suggesting holding back advisories? No. Not once they're researched & ready to publish. See below. > > But I had forgotten inevitably some issues that people worked hard on > > to meet releases, will just miss, & often continue to be worked hard > > on, so more than usual is ready to be announced just after release. > > Not more than usual. There just happened to be a cluster immediately > after 10.2. There was no such cluster after 10.1; three advisories were > published four weeks after the release and a fourth a week after that. Sounds OK re 10.1, I had the impression over years there's been flurries of announcements shortly after [some] releases. > Besides, even if there were such a wave after each release, would it > really matter? Yes. It would suggest possible bad management &/or poor product, & bad press. > Most organizational users need weeks if not months to > test a new version and plan its deployment, so that hypothetical wave > would not affect them any more than any other batch of advisories. OK, but for those supporting on a mix of stable + latest releases, it's a wave of extra time consuming work. > > Perhaps if core@ extend their presumed per release Thank You notes > > to re@ & beyond "Thanks for rolling a release", & append "Please > > take a short break, you deserve it + it will help minimise an > > immediate post release notification wave". Might that help ? > > You want the security team to take a vacation after each release so we > can maintain the illusion, at least for a couple of weeks, that there > are no bugs or vulnerabilities in FreeBSD? No. It was brief, expecting sensible extrapolation: Management includes both asking people to work hard before a release, and easing off a bit just after. Urgent issues could continue to be solved, but researching longer existant less urgent issues could be slackened for a bit, Without delay to publication once complete. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. Subsidise contraception V. Global warming, pollution, famine, migration. From owner-freebsd-security@freebsd.org Wed Sep 2 21:07:13 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBBF69C9B07 for ; Wed, 2 Sep 2015 21:07:13 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D18E7D4B; Wed, 2 Sep 2015 21:07:13 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id D0404158A; Wed, 2 Sep 2015 21:07:13 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-15:23.bind Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20150902210713.D0404158A@freefall.freebsd.org> Date: Wed, 2 Sep 2015 21:07:13 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 21:07:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-15:23.bind Security Advisory The FreeBSD Project Topic: BIND remote denial of service vulnerability Category: contrib Module: bind Announced: 2015-09-02 Credits: ISC Affects: FreeBSD 9.x Corrected: 2015-09-02 20:06:46 UTC (stable/9, 9.3-STABLE) 2015-09-02 20:07:03 UTC (releng/9.3, 9.3-RELEASE-p25) CVE Name: CVE-2015-5722 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. The libdns library is a library of DNS protocol support functions. II. Problem Description Parsing a malformed DNSSEC key can cause a validating resolver to exit due to a failed assertion in buffer.c. III. Impact A remote attacker can deliberately trigger the failed assertion which will cause an affected server to terminate, by using a query that requires a response from a zone containing a malformed key, resulting in a denial of service condition. Recursive servers are at greatest risk, however, an authoritative server could also be affected, if an attacker controls a zone that the server must query against to perform its zone service. IV. Workaround No workaround is available, but hosts not running named(8) are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. The named service has to be restarted after the update. A reboot is recommended but not required. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install The named service has to be restarted after the update. A reboot is recommended but not required. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 9.3] # fetch https://security.FreeBSD.org/patches/SA-15:23/bind.patch # fetch https://security.FreeBSD.org/patches/SA-15:23/bind.patch.asc # gpg --verify bind.patch.asc Please note that FreeBSD 9.3-STABLE is also affected by another issue (CVE-2015-5986), and a different patch should be used. b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the named(8) daemon, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r287409 releng/9.3/ r287410 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References CVE-2015-5986 is listed here for completeness and affects FreeBSD 9.3-STABLE but not FreeBSD 9.3-RELEASE: The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.7 (FreeBSD) iQIcBAEBCgAGBQJV52K9AAoJEO1n7NZdz2rnYQEP/1MY+pxPVMWT86qNKZ8upUpH LadLmtYAERrT9SMBrEFNCgylRdwNabTPKU0ZtxW8I57rks+j4bci053qo9Z7Hyo0 tbK3hTtxJZHNBO1G+NFfQxx9U+R+86Korx3NvDiB78XkJaab5On3dSgIMJYPEIL+ h0NEfYqe+X+LYg3W46faPdIuOsgxWSYN1T6mcZ5B5lucbT+LXjA5sRj+rUcE+a4O 2lIdM1oesWOZrEZo9FjK3UPvBbiEZkspr5IBd0zA825+BZNOpk06SOS/f3N0Pz8u S2vGlxcT37CzC9fPgjQpcNBmB+76xLgz74Inj4uPDSvCz+wmmcr95YOgheZb2N6K Bqakzy9TyRNk1aa8VXb8XpfyfMzroWG/vNjV6trI5wry7U0zRSl4dz+XAoz0A/eO 9ue88iWsVh97HBWKH94K8ZCA49G3NLgkbDkJ3awS4TfIKwwh9bGDiDepu1KMqnC1 EzyRk2fnr9JIreLj5zR1ctL1xGUvBIzWvHeT72PjgdZ/hqDoXTHKSVnDoR0c6T+U bJBJSLi3KUqaMkKRJez84r7G8RKtudLT292l4UQ3qgbiuaXagY6m1W0WBpLvw/zv RQOsG3HPpDrrV/LiSWKybEX2hIqIHd3tssfjQqvMa4WLO3h8wVONjw74YgRzZaYb t/1F4r4UYtfIJ7omydxx =B0u1 -----END PGP SIGNATURE-----