- OpenStack-announce - lists.openstack.org

[all][elections][ptl] Project Team Lead Election Conclusion and Results
by Tony Breeds 20 Sep '23

20 Sep '23

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Dale Smith * Barbican : Grzegorz Grasza * Blazar : Pierre Riteau * Cinder : Rajat Dhasmana * Cloudkitty : Rafael Weingartner * Designate : Michael Johnson * Freezer : ge cong * Glance : Pranali Deore * Heat : Takashi Kajinami * Horizon : Vishal Manchanda * Ironic : Jay Faulkner * Keystone : Dave Wilde * Kolla : Michal Nasiadka * Kuryr : Roman Dobosz * Magnum : Jake Yip * Manila : Carlos Silva * Masakari : sam sue * Murano : Rong Zhu * Neutron : Brian Haley * Nova : Sylvain Bauza * Octavia : Gregory Thiemonge * OpenStack Charms : Felipe Reyes * OpenStack Helm : Vladimir Kozhukalov * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Takashi Kajinami * Quality Assurance : Martin Kopec * Solum : Rong Zhu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Erno Kuvaja * Vitrage : Dmitriy Rabotyagov * Watcher : chen ke * Zaqar : Hao Wang * Zun : Hongbin Lu Elections: * OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Yours Tony.

1 0

[all][elections][tc] Technical Committee Election Results
by Tony Breeds 20 Sep '23

20 Sep '23

Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Dan Smith (dansmith) Jens Harbott (frickler) Ghanshyam Mann (gmann) Jay Faulkner (JayF) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_36ebf2eba022aded Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Yours Tony.

1 0

[OSSA-2023-003] cinder, glance_store, nova, os-brick: Unauthorized volume access through deleted volume attachments (CVE-2023-2088)
by Jeremy Stanley 10 May '23

10 May '23

============================================================================ OSSA-2023-003: Unauthorized volume access through deleted volume attachments ============================================================================ :Date: May 10, 2023 :CVE: CVE-2023-2088 Affects ~~~~~~~ - Cinder: <20.2.1, >=21.0.0 <21.2.1, ==22.0.0 - Glance_store: <3.0.1, >=4.0.0 <4.1.1, >=4.2.0 <4.3.1 - Nova: <25.1.2, >=26.0.0 <26.1.2, ==27.0.0 - Os-brick: <5.2.3, >=6.0.0 <6.1.1, >=6.2.0 <6.2.2 Description ~~~~~~~~~~~ An unauthorized access to a volume could occur when an iSCSI or FC connection from a host is severed due to a volume being unmapped on the storage system and the device is later reused for another volume on the same host. **Scope:** Only deployments with iSCSI or FC volumes are affected. However, the fix for this issue includes a configuration change in Nova and Cinder that may impact you on your next upgrade regardless of what backend storage technology you use. See the *Configuration change* section below, and item 4(B) in the *Patches and Associated Deployment Changes* for details. This data leak can be triggered by two different situations. **Accidental case:** If there is a problem with network connectivity during a normal detach operation, OpenStack may fail to clean the situation up properly. Instead of force-detaching the compute node device, Nova ignores the error, assuming the instance has already been deleted. Due to this incomplete operation OpenStack may end up selecting the wrong multipath device when connecting another volume to an instance. **Intentional case:** A regular user can create an instance with a volume, and then delete the volume attachment directly in Cinder, which neglects to notify Nova. The compute node SCSI plumbing (over iSCSI/FC) will continue trying to connect to the original host/port/LUN, not knowing the attachment has been deleted. If a subsequent volume attachment re-uses the host/port/LUN for a different instance and volume, the original instance will gain access to it once the SCSI plumbing reconnects. Configuration Change -------------------- To prevent the intentional case, the Block Storage API provided by Cinder must only accept attachment delete requests from Nova for instance-attached volumes. A complicating factor is that Nova deletes an attachment by making a call to the Block Storage API on behalf of the user (that is, by passing the user's token), which makes the request indistinguishable from the user making this request directly. The solution is to have Nova include a service token along with the user's token so that Cinder can determine that the detach request is coming from Nova. The ability for Nova to pass a service token has been supported since Ocata, but has not been required until now. Thus, deployments that are not currently sending service user credentials from Nova will need to apply the relevant code changes and also make configuration changes to solve the problem. Patches and Associated Deployment Changes ----------------------------------------- Given the above analysis, a thorough fix must include the following elements: 1. The os-brick library must implement the ``force`` option for fibre channel, which which has only been available for iSCSI until now (covered by the linked patches). 2. Nova must call os-brick with the ``force`` option when disconnecting volumes from deleted instances (covered by the linked patches). 3. In deployments where Glance uses the cinder glance_store driver, glance must call os-brick with the ``force`` option when disconnecting volumes (covered by the linked patches). 4. Cinder must distinguish between safe and unsafe attachment delete requests and reject the unsafe ones. This part of the fix has two components: a. The Block Storage API will return a 409 (Conflict) for a request to delete an attachment if there is an instance currently using the attachment, **unless** the request is being made by a service (for example, Nova) on behalf of a user (covered by the linked patches). b. In order to recognize that a request is being made by a service on behalf of a user, Nova must be configured to send a service token along with the user token. If this configuration change is not made, the cinder change will reject **any** request to delete an attachment associated with a volume that is attached to an instance. Nova must be configured to send a service token to Cinder, and Cinder must be configured to accept service tokens. This is described in the following document and **IS NOT AUTOMATICALLY APPLIED BY THE LINKED PATCHES:** (Using service tokens to prevent long-running job failures) https://docs.openstack.org/cinder/latest/configuration/block-storage/servic… The Nova patch mentioned in step 2 includes a similar document more focused on Nova: doc/source/admin/configuration/service-user-token.rst 5. The cinder glance_store driver does not attach volumes to instances; instead, it attaches volumes directly to the Glance node. Thus, the Cinder change in step 4 will recognize an attachment-delete request coming from Glance as safe and allow it. (Of course, we expect that you will have applied the patches in steps 1 and 3 to your Glance nodes.) Errata ~~~~~~ An additional nova patch is required to fix a minor regression in periodic tasks and some nova-manage actions (errata 1). Also a patch to tempest is needed to account for behavior changes with fixes in place (errata 2). Patches ~~~~~~~ - https://review.opendev.org/882836 (2023.1/antelope cinder) - https://review.opendev.org/882851 (2023.1/antelope glance_store) - https://review.opendev.org/882858 (2023.1/antelope nova) - https://review.opendev.org/882859 (2023.1/antelope nova errata 1) - https://review.opendev.org/882843 (2023.1/antelope os-brick) - https://review.opendev.org/882835 (2023.2/bobcat cinder) - https://review.opendev.org/882834 (2023.2/bobcat glance_store) - https://review.opendev.org/882847 (2023.2/bobcat nova) - https://review.opendev.org/882852 (2023.2/bobcat nova errata 1) - https://review.opendev.org/882840 (2023.2/bobcat os-brick) - https://review.opendev.org/882876 (2023.2/bobcat tempest errata 2) - https://review.opendev.org/882869 (Wallaby nova) - https://review.opendev.org/882870 (Wallaby nova errata 1) - https://review.opendev.org/882839 (Xena cinder) - https://review.opendev.org/882855 (Xena glance_store) - https://review.opendev.org/882867 (Xena nova) - https://review.opendev.org/882868 (Xena nova errata 1) - https://review.opendev.org/882848 (Xena os-brick) - https://review.opendev.org/882838 (Yoga cinder) - https://review.opendev.org/882854 (Yoga glance_store) - https://review.opendev.org/882863 (Yoga nova) - https://review.opendev.org/882864 (Yoga nova errata 1) - https://review.opendev.org/882846 (Yoga os-brick) - https://review.opendev.org/882837 (Zed cinder) - https://review.opendev.org/882853 (Zed glance_store) - https://review.opendev.org/882860 (Zed nova) - https://review.opendev.org/882861 (Zed nova errata 1) - https://review.opendev.org/882844 (Zed os-brick) Credits ~~~~~~~ - Jan Wasilewski from Atman (CVE-2023-2088) - Gorka Eguileor from Red Hat (CVE-2023-2088) References ~~~~~~~~~~ - https://launchpad.net/bugs/2004555 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2088 Notes ~~~~~ - Limited Protection Against Accidents... If you are only concerned with protecting against the accidental case described earlier in this document, steps 1-3 above should be sufficient. Note, however, that only applying steps 1-3 leaves your cloud wide open to the intentional exploitation of this vulnerability. Therefore, we recommend that the full fix be applied to all deployments. - Using Configuration as a Short-Term Mitigation... An alternative approach to mitigation can be found in OSSN-0092 https://wiki.openstack.org/wiki/OSSN/OSSN-0092 - The stable/xena and stable/wallaby branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy where available. OSSA History ~~~~~~~~~~~~ - 2023-05-10 - Errata 2 - 2023-05-10 - Errata 1 - 2023-05-10 - Original Version -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

Re: [openstack-announce] [ptl][tc][winstackers] Final call for Winstackers PTL and maintainers
by Ghanshyam Mann 13 Apr '23

13 Apr '23

Thanks, James for describing the Winstacjers project (Window support in OpenStack) situation. I am forwarding it to openstack-announce ML also for a wider audience. Ref: https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.h… -gmann ---- On Thu, 13 Apr 2023 07:54:12 -0700 James Page wrote --- > Hi All > > As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects. > This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]). > This is the final call for any maintainers to step forward if this feature is important to them in OpenStack. > The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward. > Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way: * nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack* neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance Windows support* freerdp gateway > The lack of 3rd party CI for testing all of this really needs to be addressed as well. > If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the project and start the process of removing support for Windows across the various projects that support this operating system in some way - either directly or through the use of os-win. > For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as guests on OpenStack. > Regards > James > [0] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03104… https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.h…

1 0

[all][tc][vitrage] Final call for Vitrage project maintainers
by Ghanshyam Mann 13 Apr '23

13 Apr '23

Hello Everyone, You might have noticed that the Vitrage project is leaderless in this cycle[1]. Eyal, who was the previous PTL and the only maintainer of this project for more than two years[2], will not be able to continue in this project[3]. We thank and appreciate all previous maintainers' work on this project. This is the final call for maintainers. If anyone is using or interested in this project, this is the right time to step up and let us know in this email or IRC(OFTC) #openstack-tc channel. If there is no response by the end of April 2023, we will discuss the retirement of this project. [1] https://etherpad.opendev.org/p/2023.2-leaderless [2] https://www.stackalytics.io/?module=vitrage-group&release=wallaby [3] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033333.h… -gmann

1 0

OpenStack 2023.1 Antelope is officially released!
by Elõd Illés 22 Mar '23

22 Mar '23

Hello OpenStack community, I'm excited to announce the final releases for the components of OpenStack 2023.1 Antelope, which conclude the 2023.1 Antelope development cycle. You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the new release site. https://releases.openstack.org/antelope/ Congratulations to all of the teams who have contributed to this release! Our next production cycle, 2023.2 Bobcat, has already started. We will meet at the Virtual Project Team Gathering, March 27-31, 2023, to plan the work for the upcoming cycle. I hope to see you there! Thanks, OpenStack Release Management team

1 0

[all][elections][tc][ptl] 2023.2 Bobcat: Technical Committee & PTL Election Conclusion & Results
by Ian Y. Choi 24 Feb '23

24 Feb '23

Thank you to the electorate, to all those who supported and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. 1. Please join me in congratulating the 5 newly elected members of the TC: Amy Marrich (spotz) James Page (jamespage) Kristi Nikolla (knikolla) Brian Rosmaita (rosmaita) Sławek Kapłoński (slaweq) Full results: no election required. 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Dale Smith (dalees) * Barbican : Grzegorz Grasza (xek) * Blazar : Pierre Riteau (priteau) * Cinder : Rajat Dhasmana () * Cloudkitty : Rafael Weingartner () * Cyborg : alex song () * Designate : Michael Johnson (johnsom) * Ec2 Api : Andrey Pavlov (andrey-mp) * Freezer : ge cong () * Glance : Pranali Deore (pdeore) * Heat : Takashi Kajinami (tkajinam) * Horizon : Vishal Manchanda (vishalmanchanda) * Ironic : Jay Faulkner (JayF) * Keystone : Dave Wilde (d34dh0r53) * Kolla : Michal Nasiadka (mnasiadka) * Kuryr : Roman Dobosz (gryf) * Magnum : Jake Yip (jakeyip) * Manila : Carlos Silva (carloss) * Masakari : sam sue () * Murano : Rong Zhu (zhurong) * Neutron : Rodolfo Alonso Hernandez (ralonsoh) * Nova : Sylvain Bauza (bauzas) * Octavia : Gregory Thiemonge (gthiemonge) * Openstack Chef : Lance Albertson (Ramereth) * OpenStack Helm : Vladimir Kozhukalov () * OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK : Artem Goncharov (gtema) * Puppet OpenStack : Takashi Kajinami (tkajinam) * Quality Assurance : Martin Kopec (kopecmartin) * Skyline : Wenxiang Wu (wu_wenxiang) * Solum : Rong Zhu (zhurong) * Storlets : Takashi Kajinami (tkajinam) * Tacker : Yasufumi Ogawa (yasufum) * Telemetry : Matthias Runge (mrunge) * Trove : wu chunyang (wuchunyang) * Venus : Eric Zhang () * Watcher : chen ke () * Zaqar : Hao Wang (wanghao) * Zun : Hongbin Lu () PTL Election: no election required. For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Ian Y. Choi, on behalf of the OpenStack Technical Election Officials

1 0

[OSSA-2023-002] Cinder, Glance, Nova: Arbitrary file access through custom VMDK flat descriptor (CVE-2022-47951)
by Jeremy Stanley 24 Jan '23

24 Jan '23

======================================================================== OSSA-2023-002: Arbitrary file access through custom VMDK flat descriptor ======================================================================== :Date: January 24, 2023 :CVE: CVE-2022-47951 Affects ~~~~~~~ - Cinder, glance, nova: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0; Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0; Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0 Description ~~~~~~~~~~~ Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou (OVH) reported a vulnerability in VMDK image processing for Cinder, Glance and Nova. By supplying a specially created VMDK flat image which references a specific backing file path, an authenticated user may convince systems to return a copy of that file's contents from the server resulting in unauthorized access to potentially sensitive data. All Cinder deployments are affected; only Glance deployments with image conversion enabled are affected; all Nova deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/871631 (Train(cinder)) - https://review.opendev.org/871630 (Train(glance)) - https://review.opendev.org/871629 (Ussuri(cinder)) - https://review.opendev.org/871626 (Ussuri(glance)) - https://review.opendev.org/871628 (Victoria(cinder)) - https://review.opendev.org/871623 (Victoria(glance)) - https://review.opendev.org/871627 (Wallaby(cinder)) - https://review.opendev.org/871621 (Wallaby(glance)) - https://review.opendev.org/871625 (Xena(cinder)) - https://review.opendev.org/871619 (Xena(glance)) - https://review.opendev.org/871622 (Xena(nova)) - https://review.opendev.org/871620 (Yoga(cinder)) - https://review.opendev.org/871617 (Yoga(glance)) - https://review.opendev.org/871624 (Yoga(nova)) - https://review.opendev.org/871618 (Zed(cinder)) - https://review.opendev.org/871614 (Zed(glance)) - https://review.opendev.org/871616 (Zed(nova)) - https://review.opendev.org/871615 (2023.1/antelope(cinder)) - https://review.opendev.org/871613 (2023.1/antelope(glance)) - https://review.opendev.org/871612 (2023.1/antelope(nova)) Credits ~~~~~~~ - Guillaume Espanel from OVH (CVE-2022-47951) - Pierre Libeau from OVH (CVE-2022-47951) - Arnaud Morin from OVH (CVE-2022-47951) - Damien Rannou from OVH (CVE-2022-47951) References ~~~~~~~~~~ - https://launchpad.net/bugs/1996188 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47951 Notes ~~~~~ - The stable/wallaby, stable/victoria, stable/ussuri, and stable/train branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy where possible. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

[OSSA-2023-001] Swift: Arbitrary file access through custom S3 XML entities (CVE-2022-47950)
by Jeremy Stanley 17 Jan '23

17 Jan '23

=================================================================== OSSA-2023-001: Arbitrary file access through custom S3 XML entities =================================================================== :Date: January 17, 2023 :CVE: CVE-2022-47950 Affects ~~~~~~~ - Swift: <2.28.1, >=2.29.0 <2.29.2, ==2.30.0 Description ~~~~~~~~~~~ Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML parser. By supplying specially crafted XML files an authenticated user may coerce the S3 API into returning arbitrary file contents from the host server resulting in unauthorized read access to potentially sensitive data; this impacts both s3api deployments (Rocky or later), and swift3 deployments (Queens and earlier, no longer actively developed). Only deployments with S3 compatibility enabled are affected. Patches ~~~~~~~ - https://review.opendev.org/870823 (2023.1/antelope) - https://review.opendev.org/870828 (Wallaby) - https://review.opendev.org/870827 (Xena) - https://review.opendev.org/870826 (Yoga) - https://review.opendev.org/870825 (Zed) Credits ~~~~~~~ - Sébastien Meriot from OVH (CVE-2022-47950) References ~~~~~~~~~~ - https://launchpad.net/bugs/1998625 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47950 Notes ~~~~~ - The stable/wallaby branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

[OSSN-0091] BMC emulators developed in OpenStack community do not preserve passwords on VMs
by Jay Faulkner 31 Oct '22

31 Oct '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ## Summary ## When deploying VirtualBMC or Sushy-Tools in an unsupported, production-like configuration, it can remove secret data, including VNC passwords, from a libvirt domain permanently. Operators impacted by this vulnerability must reconfigure any secret data, including VNC passwords, for the libvirt domain. These virtual machine emulators are tools to help emulate a physical machine's Baseboard Management Controller (BMC) to aid in development and testing of software that would otherwise require physical machines to perform integration testing activities. They are not intended or supported for production or long-term use of any kind. ## Affected Services / Software ## * Sushy-Tools, <=0.21.0 * VirtualBMC, <=2.2.2 There is no impact to any OpenStack software or services intended for production use. ## Patches ## * VirtualBMC: https://review.opendev.org/c/openstack/virtualbmc/+/862620 * Sushy-Tools: https://review.opendev.org/c/openstack/sushy-tools/+/862625 ## Discussion ## To perform some advanced operations on Libvirt virtual machines, the underlying XML document describing the virtual machine's domain must be extracted, modified, and then updated. These specific actions are for aspects such as "setting a boot device" (VirtualBMC, Sushy-Tools), Setting a boot mode (Sushy-Tools), and setting a virtual media device (Sushy-Tools). This issue is triggered when a VM has any kind of "secure" information defined in the XML domain definition. If an operator deploys VirtualBMC or Sushy-Tools to manage one of these libvirt VMs, the first time any action is performed that requires rewriting of the XML domain definition, all secure information -- including a VNC console password, if set -- is lost and removed from the domain definition, leaving the libvirt VM's exposed to a malicious console user. ## Recommended Actions ## Operators who may have been impacted by this vulnerability should immediately remove use of VirtualBMC and/or Sushy-Tools from their production environment. Then, validate and if necessary, reconfigure passwords for VNC access or any other impacted secrets. ## Notes ## The OpenStack team will ensure documentation is updated to clearly state these software packages are intended for development/CI use only, and are not safe to run in production. ## Credits ## Julia Kreger from Red Hat ## References ## Author: Jay Faulkner, G-Research Open Source Software This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0091 Original Storyboard bug: https://storyboard.openstack.org/#!/story/2010382 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2022-44020 -----BEGIN PGP SIGNATURE----- Version: FlowCrypt Email Encryption 8.3.8 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJjYDqWACEJEGt12Tm0JMbUFiEEvF1YmsGLSYuWqE+ta3XZ ObQkxtSjBhAAgkeFOi39SEuatIMBLA+EEXyTzEyINJQnFmUqJlDLLckQv646 sotFsmYizNWn3GEVEYNjPWjMdQz11NTA4Ox8CijoPGHPNCoaHc461Vm3VH1Y 4rv4nzDI+JsU/r4HRNT6N5BveqiCpvpIvUmsxbdzAciBqqjSjpAk/wuY3v3p QRyqktMW3ep8evGw0xAaj3UWElLM+ooJM/Z4CayKQXeNTFDXdlQsIxGQAmrM s9U9sxf1I839oj5AbBQZ2mYV/oV6DdrTEvrDnGtwrowlugCdBXKVLETbylAn tvlPz+I6DrNWndCucZthwDesccpMvVqxCUup+lYs9o0RcfT8sK5PxNEzpi5U zR07iC9hJz3Pa9I7VWOQMtWIDD1XYgQZ7iCKu/kd4CXM74O1qpdoQQ0T4dCP J0Scv/L5TVkV3X7d6tyJ6i8bdVEt6XQvXLFIzo9iudheuxF8j4bGpgcMBw/a OUi7AGXE00P1qaCUON8hgu4F3b5iU3guoJD7EmW8CAyDVOqtZdgFQUs0UYnb 443nEe/MHrwed+UBXbrg9xKrXalRvkQP6wG1WvAV6U2yY6cMntYb4YWUl37K ggG+rsYIj/j8o5JncBuxyQyXGbjammZYJHOzDpJO42xwe5B8aXPamx8Z6V6I 6Fb07pYS1vlghBDnvU37KYF6bVpBBZ8QiiQ= =RmVg -----END PGP SIGNATURE-----

1 0