From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 99870136EB; Tue, 18 Nov 2025 01:37:55 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 08E9E13721; Tue, 18 Nov 2025 01:37:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by atuin.qyliss.net (Postfix) with ESMTPS id 9661D136CB for ; Tue, 18 Nov 2025 01:37:51 +0000 (UTC) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-78665368a5cso48229707b3.3 for ; Mon, 17 Nov 2025 17:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763429869; x=1764034669; darn=spectrum-os.org; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=56GpZLXvnAUeT4jqpikcDo0f3baHAgwMalqUbEmmIXI=; b=AcUA86baGoGsRjsrtu5VBRaSpL2dVsrlT9PAy3SDZldG3+wIUK/sjHrSkoTgD2sBOx ydbqqNDv+p9G0oxKfdHc9ZN91vVW91kzPc63IPJLggBFggkmTMPxJdA0+uVuk/HJyRbB 6eK5e5RGIwaGYDUyCVNEzu1YCx+5l7e/5PZX5aJA3qr3PV+qjNqbvSBfyqAR5pR6xrLn Su9VV+v3rLlxHOtuK2A9xytN35RJqahzJjjAv9CeGBpj/qFUMHlceDrf14usdE9TN1uj m0hPo1i4ctLGAd44yZXEUgwAJlCb6w0J4hmSB7GUv97LbYNeoyU+LcIvQTL/RjVqbzyc DyRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763429869; x=1764034669; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=56GpZLXvnAUeT4jqpikcDo0f3baHAgwMalqUbEmmIXI=; b=fnF3nTbi8fl4dtx6bTHRnow3r1ID0GCyw243dagopi7tWTeypr/k0gUz0cpKmqmcLX XwoOieBHtdm395STDOR4qLhTiNyAkcWesoqJ4UkdNfBK6072DDhFR7xxYG9tVOhoLsuL TGK1NwhcLBq3/24b7/zIvUJ2nEG0lq3OjcYTxFlGwz4Hw8h9r/62vfPW96CozvzhX4hg 3mbI3+qSpzBsEOGJjGFC7GEg+aqhNa7X8hDKFx8Ehi5+c5279KGMioXWdZC8HuPz0Gvo bfCXg5Fz0iWmgXTusOBiVTVQ22QZ2p4y3QGGn68Zt7yckLOfFYmhGtoX/hZFgSLprA/Y t+7A== X-Gm-Message-State: AOJu0Yw7i8xwXgriTgSl5RlRx3eYeHr1hOsX/1yDDuTF7tuGnt66/Ot8 GOBToWpLEfe1dNSyU6Zb4zFm26KyJ74I1PEcxXywQdTtNNYcLAqKzuRkm3JssjCJ X-Gm-Gg: ASbGncsU/0aUwctWkdwUJ7VQ9pob/8BBamubxuFNpWSUWHzZ529uD4OFbXuqMNm9WA5 X9SxpLcH4cr8Xph6lauP7l17DoHbva8//2tUf1NwX54Z6tWeK6uTpwhLgGFuYJXvJI7kfz827Hj WVxLSpcUI/hGHY3aqwPMnZTHRU8RETUjyitUJ2/JFSHys8KQUvgAi8u7FKfSp3lwUh0LFFLZB1t zkjDvKZs4xr5sa8cdkmAFBkl9GAMCnCLY53BPiP2iR2eFTHuh32cIL6WlQETd5fS6RgahY9pC9e uPfYZcfran3q5+7vGU0uT86XXsaCqjIutU7NWXvyW6smyVFFGHgFEfekaDGPM5pZuNXsDvYOnkJ Afc/Pnwid9u0roEio3tmwPVWWIo8m2A3GQhaTGVGGoAKSQyZ2WInGCxAf2x1TUaDtXtkI5SxeDm pomMP8nVQLyRHQe2cShW84UCMZ9+3lwEYYKNZI6OGAkZ/m26FZkfN+suirfbJq5XyFNRDGhZzRj Y9zaWq41D0Gj+tDLppikTlSkmfNRWlQqG8F2A== X-Google-Smtp-Source: AGHT+IH9DXDLVZYry3JC6QHn1sd6L/fEW0LJ/EWVRYAVDa6Ybbydx65ZfhlPpVv3Uoa9KB/i+IiRkw== X-Received: by 2002:a05:690e:2591:b0:640:e3c6:c419 with SMTP id 956f58d0204a3-641e75370femr8339297d50.18.1763429868634; Mon, 17 Nov 2025 17:37:48 -0800 (PST) Received: from [10.138.34.110] (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6410eaf0138sm5286186d50.25.2025.11.17.17.37.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Nov 2025 17:37:47 -0800 (PST) Message-ID: <4e220976-e533-41d1-8c4a-df264c007215@gmail.com> Date: Mon, 17 Nov 2025 20:37:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] tools/mount-flatpak: init To: Alyssa Ross References: <20251113120452.65711-1-hi@alyssa.is> <87ldk8lvfi.fsf@alyssa.is> <87ikfb4iat.fsf@alyssa.is> Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT In-Reply-To: <87ikfb4iat.fsf@alyssa.is> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3syro54E4Vev4UkKBkvS0n1o" Message-ID-Hash: 6SQNPXXP6GIJEDSSB24PEBZPRS6SDYR6 X-Message-ID-Hash: 6SQNPXXP6GIJEDSSB24PEBZPRS6SDYR6 X-MailFrom: demiobenour@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3syro54E4Vev4UkKBkvS0n1o Content-Type: multipart/mixed; boundary="------------7mwfvFdiaylyaOEu0N0gII5P"; protected-headers="v1" From: Demi Marie Obenour To: Alyssa Ross Cc: devel@spectrum-os.org Message-ID: <4e220976-e533-41d1-8c4a-df264c007215@gmail.com> Subject: Re: [PATCH 1/3] tools/mount-flatpak: init References: <20251113120452.65711-1-hi@alyssa.is> <87ldk8lvfi.fsf@alyssa.is> <87ikfb4iat.fsf@alyssa.is> In-Reply-To: <87ikfb4iat.fsf@alyssa.is> Autocrypt-Gossip: addr=hi@alyssa.is; keydata= xsFNBFpSgoYBEAC4xkCYidG2JlRWulUkTWcx0pHFDf3oSbb6Q872Kb3iDChWgluNVz43hva1 3xfDo9foV0GoyfGl/ycSCkXX5hlQr7ir/5FN38E7H/yY6tH8+l68iDgIOcb1qY0OYaxyg+Lz WesfFQedrmwNTbF4L1BtWzrTR5PflDdhDo5VWSguHGJFSclchcr/6UmMb/gOUN+2ElBC2TE2 EKY099phZ6DJZ2aZCsclwKIdCpZzXlEmXPAeaH5om6xo90JYv5+sFji40R0Plqec3WC+jTxy lGca6IbPdOminuUF+GvsR86eVsgh/0XNK7/zus7gyc4PuMUA1rCoeHcWOBDPgmelgCQyJGXd /bXeKuUsGoge58uc7/YNvOh1vfpD3AaEMqAyXfmmUwBnIicml74+2eOpH3Oljfs01g+DhkOB MtpVSZSgaIDvP0WG6cbAxImoUasnmNxEDNskfVmI8bsajPW9bt4z5hiP5Q9G3vE0D5HcIFdM adOz81PpOwNiUXcjtYV1PWZQ56jbSTOf8EBvsB71WwB+XgVWcPzIlY8hAykiHIO87oV3o71U JTAn1Foj7mjSADnY0deleOmar/K5jrK3wvKKM1XlB7PXcGBdkorJC+cbxVsw0ADzMw0c7bVc wEE7OFvHjQiIK1lO+lb1cvGBBY3IZxjsjZdA/VsFHFdAeYlzNQARAQABzRpBbHlzc2EgUm9z cyA8aGlAYWx5c3NhLmlzPsLBlwQTAQgAQQIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAIZ ARYhBHVzVtd5u7iIdz5BXnNszfnvUb2XBQJpALHXBQkPJNZRAAoJEHNszfnvUb2X2jEP/AqQ aafKiC7ormevgoCH4QinAKJoXAqiwOIdRK55HOvyhGWjnlzqoK4JTUFVRMR4Vat/APlkjOUk LPXKk+DCn4loFyl7BCLvsk4Xwy7WmXyfSPqjdik8/cjTv/Q4AHTYTpnx7GMC5eTS7ULmUvcf mD/JRr7NM2273Z7dkL3gOeZdnXYOQaGAIIox91qCtmnQhn+V7s3uxvcRl8I2/Qnn3S2veV03 LXSugAXSTdKRa7LBrcSm9TtC/D3qY9kStHiaiB/eAJsOQ0l5yRfax5INorE2DQgBKjbiBcnQ mTX7Rl9LW+U0ibHmKOFG8Zs+zKlmItek49cmqoGOv66RAY6dGUOHoEQgP0EUDJ8xGwActToC lOGZrzcXfrfx0CYlgqYE1VEWgSmtbTW1DBXiZIPKUMLJGhgaIHSKEjYujHd+vGytAMGKQsVQ OwgOMHYWyzAIB/Y6hZGNK8y5fxr468zX876mDdXhYo4dKA7UEOeQOlAIGobTXDRFEC7B/UAj qYbP+qmnyUohCy/Pf04cF0ucpWW2Z00sBL83lauhyQHiLze5OznvOeEkEeXQ6DsJOY0dmrsi 0NJZ1QoyYewXOPmPBNc7IesY1MjrpAnHgeAt1rgEPwTkt4NrRASsPe5JowJcc7CpIdR8eOrG hrw+bEMyoyjk7fN6Hs6MK+hVihMNhUwMzjgEZyd/yxIKKwYBBAGXVQEFAQEHQCVxoiHOlsEo NDKGCbxg4nL3E1CV0MRQCU1hPowd77h3AwEIB8LBfAQYAQoAJgIbDBYhBHVzVtd5u7iIdz5B XnNszfnvUb2XBQJpALHQBQkCT9j5AAoJEHNszfnvUb2XhSMP/0gStw42LjpjVLh+0HKWafs3 T9NJxtefYRbyu4wkkO0dss2pkl9gekZnvgktD0SzIe8AiMszs1rUWMG8zPXVWdMi7tSNm/IR WPa0XZDIoDwJY4T342nCvHeDsfoJnGg8o0nreI2djwO8sc9aeSevm60MQ9AouFBpS6Qw7f/Z LalXH4aWCCtvAO1o95lQXEoH4Lg4qnS6GxYMYi1u3IzrYdUu0By/Ccc5+AOOICgbJnpOoYQI bVDbdjMkj18JxxmpN5amOkPdiDndpzWkWm+oNhGUITYp6EuP1esRb35MgOmFGouvt5UdKpEl Egs2y5h9oR+kiiu9DhrC0UFL2CQ/HdiukCAxADKX3RE9m+mprSbvw7CsYmXUTH6WzPpvxpGx wQq7m2O7uy85u0HyVYkiWQiAfwCbEr1vrFU7gscBW+FcrLIODauovA9eZgA4d+cHRXfzsdKW u/QuVHsABh78LLIq008GcqJChSe4KHrJ5PUjkLnyp/Sshrmuyoy+DwqYky0KK4NtkaWa2o0B TFp+Kk2VCxWA8i/azPvTMzXOWNwqogISp5SwljiEx0hkyf0HvSb3gHfuGbZ+eGfWB+qy2pTD x/YriV5EfqkP+4+1cqXjasrQxyZUW0ULRke0j92Cgt+J722PIcOAb8vdSGF4AXczO+KMtNn9 wGxvGU7TX5ou --------------7mwfvFdiaylyaOEu0N0gII5P Content-Type: multipart/mixed; boundary="------------9od0J6ExnzvNyJNlObnPNxNn" --------------9od0J6ExnzvNyJNlObnPNxNn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/15/25 07:00, Alyssa Ross wrote: > Demi Marie Obenour writes: >=20 >> On 11/14/25 06:12, Alyssa Ross wrote: >>> Demi Marie Obenour writes: >>> >>>> On 11/13/25 07:04, Alyssa Ross wrote: >>>>> diff --git a/tools/mount-flatpak/mount-flatpak.c b/tools/mount-flat= pak/mount-flatpak.c >>>>> new file mode 100644 >>>>> index 0000000..8e09d1d >>>>> --- /dev/null >>>>> +++ b/tools/mount-flatpak/mount-flatpak.c >>>>> @@ -0,0 +1,294 @@ >>>>> +// SPDX-License-Identifier: EUPL-1.2+ >>>>> +// SPDX-FileCopyrightText: 2025 Alyssa Ross >>>>> + >>>>> +#include "config.h" >>>>> +#include "metadata.h" >>>>> + >>>>> +#include >>>>> +#include >>>>> +#include >>>>> +#include >>>>> +#include >>>>> +#include >>>>> + >>>>> +#include >>>>> +#include >>>>> + >>>>> +#include >>>>> +#include >>>>> + >>>>> +static void bind_mount(int source_fd, const char *source, >>>>> + int target_fd, const char *target) >>>>> +{ >>>>> + int source_tree =3D syscall(SYS_open_tree, source_fd, source, >>>>> + AT_EMPTY_PATH | OPEN_TREE_CLOEXEC | >>>>> + OPEN_TREE_CLONE | AT_RECURSIVE); >>>>> + if (source_tree =3D=3D -1) >>>>> + err(EXIT_FAILURE, "open_tree %s", source); >>>>> + if (syscall(SYS_move_mount, source_tree, "", target_fd, target, >>>>> + MOVE_MOUNT_F_EMPTY_PATH | MOVE_MOUNT_T_EMPTY_PATH) =3D= =3D -1) >>>>> + err(EXIT_FAILURE, "move_mount"); >>>> >>>> Missing checks that target does not contain "/" and is not "." or ".= =2E". >>> >>> Right, yes, move_mount doesn't have RESOLVE_BENEATH semantics. Ideal= ly >>> I suppose we can leave target empty and only use an fd, but I don't >>> think that works in all circumstances. >> >> Which ones does it fail in? Also, should this set the mount read-only= ? >=20 > I had it that way originally, but I decided to replace it with one > read-only self-bind-mount at the end because making just these read-onl= y > and not the parent directories felt a bit ad-hoc. You could do both! Also, you could create an anonymous tmpfs mount and bind-mount it at the end. That way it is not even visible until it is fully constructed. >>>>> +} >>>>> + >>>>> +static int mkdir_openat(int dirfd, const char *path, mode_t mode) >>>>> +{ >>>>> + int fd; >>>>> + if (mkdirat(dirfd, path, mode) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "mkdirat %s", path); >>>>> + if ((fd =3D openat(dirfd, path, O_PATH | O_DIRECTORY | O_CLOEXEC)= ) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "openat %s", path); >>>>> + return fd; >>>>> +} >>>>> + >>>>> +// By failing on EEXIST when creating each directory, >>>>> +// we can be sure we don't end up following .. components. >>>>> +static int mkdirs_beneath(int root, const char *target) >>>>> +{ >>>>> + int last, fd =3D root; >>>> >>>> Missing check for target being absolute. >>>> >>>> if (*target =3D=3D '/') >>>> errx(EXIT_FAILURE, "Path is absolute"); >>>> >>>> if (*target =3D=3D '\0') >>>> errx(EXIT_FAILURE, "Path is empty"); >>>> >>> >>> Ugh, yes. I have RESOLVE_BENEATH on the brain. Sad that it's not >>> supported for more operations. Empty path shouldn't be a problem tho= ugh >>> I think? It'd just mean 0 iterations of the loop run. >> >> POSIX requires that an empty pathname is not successfully resolved, >> and I'm pretty sure that for all of the callers an empty pathname >> should be treated as an error. >=20 > Okay. >=20 >>>>> + size_t len =3D strlen(target); >>>>> + char *end, *path =3D malloc(len + 1), *dir =3D path; >>>>> + if (!dir) >>>>> + err(EXIT_FAILURE, "malloc %zu", len + 1); >>>>> + memcpy(dir, target, len + 1); >>>>> + >>>>> + do { >>>>> + // Find next non-empty directory component >>>>> + end =3D strchrnul(dir, '/'); >>>>> + while (*(end + 1) =3D=3D '/') >>>>> + end++; >>>> >>>> Off-by-1 overread: should check *end and not *(end + 1). >>>> Also, this skips past the NUL terminator. >>>> >>>> This fixes the bug and adds the missing "." and ".." checks: >>>> >>>> end =3D strchrnul(dir, '/'); >>>> >>>> if (end - dir =3D=3D 1 && dir[0] =3D=3D '.') >>>> errx(EXIT_FAILURE, "path component is '.'"); >>>> >>>> if (end - dir =3D=3D 2 && dir[0] =3D=3D '.' && dir[1] =3D=3D '.') >>>> errx(EXIT_FAILURE, "path component is '..'"); >>>> >>>> if (*end !=3D '\0') { >>>> while (end[1] =3D=3D '/') >>>> end++; >>>> } else { >>>> end--; >>>> } >>>> >>>> However, the `dir =3D end + 1` at the end of the loop can be removed= >>>> while making the code simpler. I would write: >>>> >>>> end =3D strchrnul(dir, '/'); >>>> >>>> if (end - dir =3D=3D 1 && dir[0] =3D=3D '.') >>>> errx(EXIT_FAILURE, "path component is '.'"); >>>> >>>> if (end - dir =3D=3D 2 && dir[0] =3D=3D '.' && dir[1] =3D=3D '.') >>>> errx(EXIT_FAILURE, "path component is '..'"); >>>> >>>> if (*end !=3D '\0') { >>>> // Replace path separator with string terminator. >>>> *end =3D '\0'; >>>> >>>> // Advance until end does not point to a '/'. >>>> while (*++end =3D=3D '/') {} >>>> } >>>> >>>> This means that *end now points to the start of the next component o= r the >>>> NUL terminator, so the following changes are needed. >>>> >>>> - Removing `*end =3D 0`. >>>> - Replacing `dir =3D end + 1` with `dir =3D end`. >>>> >>>> Feel free to write the while loop in a different way if it is too >>>> code-golfed :) >>> >>> Not sure what I was thinking there, but I suppose that's what code >>> review is for. >>> >>>>> + // Replace path separator with string terminator. >>>>> + *end =3D 0; >>>> >>>> Missing check for a path component being "." or "..". >>> >>> As I wrote in the comment, these should just fail with EEXIST, no? >> >> They indeed should and do. I was thinking of openat(), which does >> not have this guarantee. >> I do recommend having mkdir_openat() assert that the directory does no= t >> contain '/', which would bypass the protections it is meant to provide= =2E >=20 > mkdir_openat() isn't meant to provide any particular protections, just > to be more concise than having to keep calling both separately. I can > even imagine using it on paths containing a separatory if I wanted to > create a known sequence of directories (like repo/tmp/cache) as > successive mkdir calls, but then get a file descriptor for the last one= =2E > It's only in mkdirs_beneath() where it's important that no segment > contains a separator, so that's where that should be ensured. None of mkdir_openat()'s call sites should be passing strings containing a path separator, so it's safe for mkdir_openat() to include this check. Even if it is not *intended* to provide protection, it's a good place to add it. My recommendation would be to add wrappers around the various syscalls that do the checks needed to prevent TOCTOU and path traversal. Then #pragma GCC poison the original libc functions so you can't use them by mistake. >>>>> +static void set_up_app_dir(int source_commit_dir, int installation= _dir, >>>>> + const char *id, const char *arch, >>>>> + const char *branch, const char *commit)= >>>>> +{ >>>>> + int app_dir, id_dir, arch_dir, branch_dir; >>>>> + >>>>> + app_dir =3D mkdir_openat(installation_dir, "app", 0755); >>>>> + >>>>> + id_dir =3D mkdir_openat(app_dir, id, 0755); >>>>> + close(app_dir); >>>>> + >>>>> + arch_dir =3D mkdir_openat(id_dir, arch, 0755); >>>>> + close(id_dir); >>>>> + >>>>> + branch_dir =3D mkdir_openat(arch_dir, branch, 0755); >>>>> + close(arch_dir); >>>>> + >>>>> + if (mkdirat(branch_dir, commit, 0755) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "mkdirat %s", commit); >>>> >>>> Should there be a check that `commit` does not have control characte= rs? >>> >>> If anything is interpreting control characters in these paths, that's= >>> their bug. We can avoid printing them though. >> >> I'm mostly thinking of ls and friends. I believe `commit` is actually= >> a hex-encoded or base64-encoded hash, so it's safe to be strict here. >> >> What *is* critical is ensuring that id, arch, branch, and commit >> do not have any '/' characters. This is currently not checked. >> except for `arch`. >> >> Stronger validation would be a good idea, and I recommend using the >> same code that updates-dir-check uses. The reason this is okay is >> that most of these are not arbitrary strings: >> >> - `arch` is an architecture, of which there are only a few. >> - `commit` is a SHA256 hash, and I believe it is always hex-encoded. >> - `id` is a D-Bus name, which is a subset of what updates-dir-check >> allows. >> >> The only exception is `branch`, but that can be checked to at least >> not have ASCII control characters or '/'. >=20 > Trying to validate that these names don't contain control characters or= > anything else here would do absolutely nothing to protect against > somebody running some command on the host and getting their terminal > emulator compromised. The VM can write whatever bytes it wants into > path names, and those can be viewed on the host, regardless of what > mount-flatpak thinks about it, because mount-flatpak runs only on > Flatpak directories, only when it's time to start a Flatpak VM long > after those files have been written and potentially viewed. If you wan= t > to protect against that, the only way you are going to be able to do it= > is by preventing those bytes from being used in the first place, in > virtiofsd, or the underlying filesystem. All trying to validate these > names would do here would be to make the program less robust against > future Flatpak changes. >=20 > You are right that we should check for path separators, though. Acknowledged. >>>>> + extract_runtime(metadata, runtime); >>>>> + >>>>> + runtime_dir =3D openat_beneath(source_installation_dir, "runtime"= , >>>>> + O_PATH | O_CLOEXEC | O_DIRECTORY); >>>>> + >>>>> + branch_dir =3D openat_beneath(runtime_dir, runtime, >>>>> + O_PATH | O_CLOEXEC | O_DIRECTORY); >>>>> + close(runtime_dir); >>>>> + >>>>> + commit_dir =3D resolve_link(branch_dir, "active", &commit); >>>>> + close(branch_dir); >>>>> + >>>>> + set_up_runtime_dir(commit_dir, target_installation_dir, >>>>> + runtime, commit); >>>>> + write_to(params_dir, "runtime-commit", commit); >>>>> + >>>>> + free(commit); >>>>> + close(commit_dir); >>>>> +} >>>>> + >>>>> +static void set_up_repo(int target_installation_dir) >>>>> +{ >>>>> + int config; >>>>> + >>>>> + if (mkdirat(target_installation_dir, "repo", 0755) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "mkdir repo"); >>>>> + if (mkdirat(target_installation_dir, "repo/objects", 0755) =3D=3D= -1) >>>>> + err(EXIT_FAILURE, "mkdir repo/objects"); >>>>> + if (mkdirat(target_installation_dir, "repo/tmp", 0775) =3D=3D -1)= >>>>> + err(EXIT_FAILURE, "mkdir repo/tmp"); >>>>> + if (mkdirat(target_installation_dir, "repo/tmp/cache", 0775) =3D=3D= -1) >>>>> + err(EXIT_FAILURE, "mkdir repo/tmp/cache"); >>>> >>>> Should this use mkdir_openat()? Alternative, you can use openat() >>>> on the just-created subdirectory and use that FD for subsequent oper= ations, >>>> including using mkdir_openat() for tmp/cache. >>> >>> I don't think there's any race to worry about the way it is, so using= >>> mkdir_openat() would just result in lots of unnecessary syscalls and >>> extra code to close all the extra file descriptors. >> >> Okay, now I see what is going on: >> >> - The "app" subdirectory is writable by whoever provided the flatpak. >> It is read-only to the guest running the flatpak. The latter is >> enforced by the recursive mount_setattr in main(). >> >> - The other subdirectories are read-only to the guest running the >> flatpak. This is enforced by virtiofsd running in a mount namespace= >> where the root of its shared directory is a read-only bind mount. >> This is documented as "The VM should not be able to write directly >> into a tmpfs", but it's actually a critical security invariant that >> at least my update code is entirely dependent on. >> >>>>> + if ((config =3D openat(target_installation_dir, "repo/config", >>>>> + O_WRONLY | O_CLOEXEC | O_NOFOLLOW | O_CREAT,= >>>>> + 0644)) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "openat repo/config"); >>>> >>>> Should this use O_EXCL? >>> >>> Can't hurt. >>> >>>>> + bind_mount(AT_FDCWD, CONFIG_PATH, config, ""); >>>>> + >>>>> + close(config); >>>>> +} >>>>> + >>>>> +int main(int, char **argv) >>>>> +{ >>>>> + char *installation_path, *id; >>>>> + int params_dir, source_installation_dir, target_installation_dir,= >>>>> + app_commit_dir; >>>>> + struct mount_attr attr =3D { >>>>> + .attr_clr =3D MOUNT_ATTR_NOSYMFOLLOW, >>>>> + .attr_set =3D MOUNT_ATTR_RDONLY | MOUNT_ATTR_NODEV, >>>>> + }; >>>>> + >>>>> + if (!(installation_path =3D *++argv)) >>>>> + errx(EXIT_FAILURE, "missing installation path"); >>>>> + if (!(id =3D *++argv)) >>>>> + errx(EXIT_FAILURE, "missing app ID"); >>>>> + >>>>> + if ((source_installation_dir =3D open(installation_path, >>>>> + O_PATH | O_CLOEXEC | O_DIRECT= ORY)) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "open %s", installation_path); >>>>> + >>>>> + params_dir =3D mkdir_openat(AT_FDCWD, "params", 0755); >>>>> + write_to(params_dir, "id", id); >>>>> + >>>>> + if (mkdir("flatpak", 0755) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "mkdir flatpak"); >>>>> + if ((target_installation_dir =3D syscall(SYS_open_tree, AT_FDCWD,= >>>>> + "flatpak", >>>>> + AT_EMPTY_PATH | OPEN_TREE_= CLONE | >>>>> + OPEN_TREE_CLOEXEC | >>>>> + AT_RECURSIVE)) =3D=3D -1) >>>>> + err(EXIT_FAILURE, "open_tree flatpak"); >>>> >>>> I don't know if the "flatpak" directory is visible in the filesystem= >>>> at this point. However, it is at least not visible to untrusted cod= e. >>>> Therefore, I recommend performing all the calls to mkdir() and write= _to() >>>> before anything is bind-mounted into this tree. >>> >>> It is visible in the filesystem. If the stuff we're bind mounting is= >>> able to mess with the files and directories we're creating though, is= n't >>> it game over regardless? It's very much not supposed to be able to d= o >>> that since it's mounted in a subdirectory. >> I forgot that this operates on a part of the filesystem the guest >> doesn't have write access to. >> >> This code is very subtle and could use a lot of comments. >> In particular, it should be very clear at each point which file >> descriptors are to secure directories (not writable by guests) >> and which ones are to insecure directories (writable by guest). >> One could use the C type system to help with this by using different >> wrapper structs for each of them. >=20 > Is the confusion here perhaps the undocumented expectation that > mount-flatpak is run before the guest is started? It's possible that > other guests could modify the underlying Flatpak repository while > mount-flatpak is running, so it's important to be defensive against > TOCTOU issues there, but we don't have to worry about any of the > structure we're creating being modified as we're setting it up. Indeed so. Even if it is running after the guest is started, the guest running the flatpak still wouldn't be able to write to it, and VM IDs aren't reused so even that isn't a problem. --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------9od0J6ExnzvNyJNlObnPNxNn Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------9od0J6ExnzvNyJNlObnPNxNn-- --------------7mwfvFdiaylyaOEu0N0gII5P-- --------------3syro54E4Vev4UkKBkvS0n1o Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmkbzegACgkQszaHOrMp 8lOtxw/8CRzvDJNVhZ9LdIX0h50WQwuC6vRUwZc3ZwLvLzrDzI3tCiVNeKkCsgLO XQWuRHwwY5HE1WzqSRX+phfvsoW6rjDEbJelcWsktgf9UGnSziDprtGfyMPPkn2v RHUflHfiNmIVal+TyH58rUSnihd6ixb+fjJttLBHHo+ehN1iuZZZo7vhx0JnlO0v N894IAuX7h9vXdeQxxjMFLC9Y9lb1O0pzYHrg4pNix/fcXD2GwHgu3iX2Oecb5JX SrgjV7R7LKrVf1keT25XooDHZfTNx+5fAYUBpHG8YKFSx+sWUWol2GSfPRrUE1dx er4UEDab+sLLVjnjiJ6Aawarr0mzlQVDgzC6lDrVMPHtPjcEOpzc/zSF+qXhgY8C ZiBm+XwbGs6N62WiG8mL7rdrcofCO61wDhQbpRpQjBVjD6O9gOa5rFVGIt665Cjk p0/cdqgB7gHnPs74CwTeIp0bVtx6qUp5W6Jka80M8jJhTNVnXbD/+Lq6vea9fz7Q mfQYQoG6d6bbAAqwhWPClpAQsmsnNaoJaq4FGUIxOwpi0Z1ZjWm+ruqVwMmPDiVO VD/zNGU3boNYcU2uTWESPzWzxcV82WwEReq8uqQLSDefWIhDtyqprlDybV9mZ/fu KIcMht22gLUeYo6KKmTuyjy/B8gRrz9AS5/puQxHMSWN+paXYKw= =2Tf8 -----END PGP SIGNATURE----- --------------3syro54E4Vev4UkKBkvS0n1o--