Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122826 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 212DC1A009C for ; Sat, 30 Mar 2024 14:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711809658; bh=rG6ojpk5yyXBxj27mupLOAOEfPGA09b1bk/xyDNIZjs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NtcZ6CkpdIfcGS7fC96EIyuiizugWQg1NPfyfpSQ87Tq6ueiwbyvRId7Fe792TbxU iYxRbRSbzhhXoq0VQmUDKUJZxV/0U03xAmvzEUdEzH3eqYTTa8DPIF3tczqYveBh0y ZFhMDMQHjbSdLOXhCmANzL1LPyEyL/9z2Ckq3oVe/fOfucNyl0YcYItRex9TK1Ciol Wz2PQkvxwLqv1pd4zDBZqye0GRwPewLJtS/oMheo522ZK9A0srtj1+tFWT3RowJ6u3 Y60+EbH7DkJbPNGhL6lluRVmQZDhOKB2ptXrbsnR3x5nl/9vdTV/f5UdYqw6ou0QIm l2Zsgzpz3fMAw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7247E180071 for ; Sat, 30 Mar 2024 14:40:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_50,DMARC_MISSING, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 30 Mar 2024 14:40:57 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-56dc70d96a9so264282a12.0 for ; Sat, 30 Mar 2024 07:40:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711809629; x=1712414429; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TunFNwhw1ImOcAdOndD5BEnFK8iBVoW7iS21XccMXI8=; b=IN3t3LZeeNpP/JtZ42tFLgGzU72TqAtKaZ0gSpZF9PWDeCPcN61q2FuPQIrrc/GH0H PhZ+Afq1fQCzHmeiHIfIuRn2hdosK5b8GdA1x+C4iRkSuFjLv52n1RPd/60GQCaaBGrO W0taZsBOgGDwGanZHFVef87G+0MJtLMSUPzEV/xpySl2f8YLeBk+P1Otg3vslDqq5chP WnXD5GxUQOnfzAdgGfuFgqcBacL1QVoB5u82+RqttpWz+cy3pXcRQf0LOTI5N9vJZ1Fn 3wTW3lnf6xtDUk22/LvyvW4UeV/LJKlAbQFeDTG+TuNPKjTWR/bQqIosrUx85/Xcg0EE YSjA== X-Forwarded-Encrypted: i=1; AJvYcCUjKpl1CLVyds8q9ae69X9OllLGSlIWJiI8dFpc4TH9ZMC5ZNHSOUacgusR9ZhGMwqounVxr2ybxMYB6cgUAQoxM35xfwn6sQ== X-Gm-Message-State: AOJu0YyprvzmOyk1JOOmKBMy5Md9YJDm5t+BfW0iSkvQzJmAatm6iJM5 ewumGGUPH9jWCCxCKUv8pWPcdzexbK20W5zHUm9aeD4ZY/3RTFMJUJeSfw2q5bZZWXLqhZIerUV Dx/8o1GFJWXPY6a6qD4DR9DxV0y0= X-Google-Smtp-Source: AGHT+IEsNza3bgrSIJbNCkwvx4hAdCIIa35+0xtWxlgYQOJnFiFn5PPJyKAsXKrTfdPP4Aq5X6Ei0d0fu0Kv6Ig2WtI= X-Received: by 2002:a50:d687:0:b0:56b:9025:44a5 with SMTP id r7-20020a50d687000000b0056b902544a5mr4106931edi.11.1711809629209; Sat, 30 Mar 2024 07:40:29 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com> In-Reply-To: Date: Sat, 30 Mar 2024 14:40:18 +0000 Message-ID: Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs To: Marco Pivetta Cc: Ben Ramsey , Bob Weinand , Daniil Gentili , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000df4bfe0614e1bce4" From: bukka@php.net (Jakub Zelenka) --000000000000df4bfe0614e1bce4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 30, 2024 at 12:03=E2=80=AFPM Jakub Zelenka wrot= e: > Hi, > > On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta wrote: > >> >> >> On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote: >> >>> On Mar 29, 2024, at 20:20, Bob Weinand wrote: >>> >>> =EF=BB=BF >>> On 29.3.2024 23:31:26, Daniil Gentili wrote: >>> >>> In light of the recent supply chain attack in xz/lzma, leading to a >>> backdoor in openSSH ( >>> https://www.openwall.com/lists/oss-security/2024/03/29/4), I believe >>> that it would be a good idea to remove the huge attack surface offered = by >>> the pre-generated autoconf build scripts and lexers, offered in the rel= ease >>> tarballs. >>> >>> In particular, the xz supply chain attack injected the exploit with a >>> few obfuscated lines, manually added to the end of the pre-generated >>> configure script, that was only bundled in the tarballs. >>> >>> Even if the exploits themselves were committed to the repo in the form >>> of test files, the code that actually injected the exploit in the libra= ry >>> was not committed to the repo, and was only present in the pre-generate= d >>> configure script in the tarball: this injection mode makes sense, as ex= tra >>> files in the tarball not present in the git repo would raise suspicions= , >>> but machine-generated configure scripts containing hundreds of thousand= s of >>> lines of code not present in the upstream VCS are the norm, and are usu= ally >>> not checked before execution. >>> >>> Specifically in the case of PHP, along from the configure script, the >>> tarball also bundles generated lexer files which contain actual C code, >>> which is an additional attack vector, i.e. here's the diff between the >>> tarball of the 8.3.4 release, and the PHP-8.3.4 tag on the git repo: >>> >>> ``` >>> ~ $ diff -r php-8.3.4 php-src -q >>> Only in php-src: >>> .git Files >>> php-8.3.4/NEWS and php-src/NEWS differ Fi= les >>> php-8.3.4/Zend/zend.h and php-src/Zend/zend.h differ On= ly >>> in php-8.3.4/Zend: zend_ini_parser.c >>> Only in php-8.3.4/Zend: zend_ini_parser.h >>> Only in php-8.3.4/Zend: >>> zend_ini_parser.output Only in php-8.3.4/Ze= nd: >>> zend_ini_scanner.c >>> Only in php-8.3.4/Zend: zend_ini_scanner_defs.h >>> Only in php-8.3.4/Zend: >>> zend_language_parser.c Only in php-8.3.4/Ze= nd: >>> zend_language_parser.h Only in php-8.3.4/Ze= nd: >>> zend_language_parser.output >>> Only in php-8.3.4/Zend: zend_language_scanner.c >>> Only in php-8.3.4/Zend: >>> zend_language_scanner_defs.h Only in php-8.3.4: >>> configure Files php-8.3.4= / >>> configure.ac and php-src/configure.ac differ Only in >>> php-8.3.4/ext/json: json_parser.tab.c Only= in >>> php-8.3.4/ext/json: json_parser.tab.h >>> Only in php-8.3.4/ext/json: json_scanner.c >>> Only in php-8.3.4/ext/json: >>> php_json_scanner_defs.h Only in php-8.3.4/ext/pd= o: >>> pdo_sql_parser.c >>> Only in php-8.3.4/ext/phar: >>> phar_path_check.c Only in >>> php-8.3.4/ext/standard: url_scanner_ex.c >>> Only in php-8.3.4/ext/standard: var_unserializer.c >>> Only in php-8.3.4/main: php_config.h.in >>> Files php-8.3.4/main/php_version.h and php-src/main/php_version.h >>> differ Only in php-8.3.4/pear: >>> install-pear-nozlib.phar Only in >>> php-8.3.4/sapi/phpdbg: phpdbg_lexer.c Only= in >>> php-8.3.4/sapi/phpdbg: phpdbg_parser.c Only= in >>> php-8.3.4/sapi/phpdbg: phpdbg_parser.h >>> Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.output >>> ``` >>> >>> To prevent attacks from malevolent/compromised RMs, I propose completel= y >>> removing all autogenerated files from the release tarballs, and ensurin= g >>> their content exactly matches the content of the associated git tag (th= is >>> means also removing the -dev prefix from the version number in >>> main/php_version.h, Zend/zend.h, configure.ac and NEWS in the git tag). >>> >>> Of course this means that users will have to generate the build scripts >>> when compiling PHP, as when installing PHP from the VCS repo. >>> >>> I'm sending a copy of this email to security@php.net as well. >>> >>> Hey Daniil, >>> >>> You can also have a public CI (i.e. a github action) generate the >>> artifacts, along with hash computation. >>> It should be a github action which runs on tags. This makes it fully >>> verifiable; i.e. the code for the generation of action, including the h= ash. >>> Anyone who wants can trivially trace this back. >>> >>> There's nothing in the tarballs which cannot be trivially automated and >>> made verifiable. >>> >>> I don't think providing pre-generated files is fundamentally flawed, th= e >>> primary lacking thing is verifiability. Which is also what enabled the = xz >>> backdoor. >>> >>> Bob >>> >>> >>> This is also why our release managers sign the tarballs with their own >>> GPG keys, after generating the artifacts. This verifies the release man= ager >>> was the one who generated the files. >>> >>> Cheers, >>> Ben >>> >> >> Hey Ben, >> >> I understand that the XZ project had signed releases too: that still >> means that downstream consumers would need to trust the release managers >> anyway, and reproduce the whole chain themselves. >> >> I suppose that's part of OP's concern. >> >> > I agree that compromised RM is a problem that we should look into. > > We have been actually already discussing something similar. I have been > thinking about it and it could be potentially used for all builds. The id= ea > is that we would setup worklfow on CI that would run on tag push and it > would call (authenticated https request) downloads.php.net server that > could do the actual build, sign them and return the hashes to the CI job > which would display them and do extra verification (probably its own buil= d > to verify that download server work as expected). Then the builds would b= e > made available for download. The RM job would be just to check that > everything worked as expected, potentially verify that the builds for > download and do all the announcements. This is a bit of work to do but I > think it should then completely remove the possibility of compromised RM = to > compromise the builds which is currently possible. It would probably make= s > sense to let RM to sign the builds as well which should then reduce chanc= e > of downloads server being compromised. > > It needs more thinking to iron out all details and make sure it is a > secure but I think it would be something worth to look at. > We could possibly do all builds in CI and also connect this with Windows build which could also happen in CI and the resulted builds would be just downloaded by download server. There are various ways how to do this and it needs careful consideration. My main point is that we should try to move things away of building stuff on RM's machines which has got various other issues as well. Regards Jakub --000000000000df4bfe0614e1bce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 30, 2024 at 12:03=E2=80= =AFPM Jakub Zelenka <bukka@php.net&= gt; wrote:
Hi,

On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta &= lt;ocramius@gmail.c= om> wrote:


On Sat, 30 Mar 2024, 05:19 Ben Ramsey, <ben@benramsey.com> w= rote:
On Mar 29, 2024, at 20= :20, Bob Weinand <bobwei9@hotmail.com> wrote:

=EF=BB=BF =20 =20
On 29.3.2024 23:31:26, Daniil Gentili wrote:
=20 =20 In light= of the recent supply chain attack in xz/lzma, leading to a backdoor in openSSH (https://www.openwall.com/lists/oss-= security/2024/03/29/4), I believe that it would be a good idea to remove the huge attack surface offered by the pre-generated autoconf build scripts and lexers, offered in the release tarballs.

In particular, the xz supply chain attack injected the exploit with a few obfuscated lines, manually added to the end of the pre-generated configure script, that was only bundled in the tarballs.

Even if = the exploits themselves were committed to the repo in the form of test files, the code that actually injected the exploit in the library was not committed to the repo, and was only present in the pre-generated configure script in the tarball: this injection mode makes sense, as extra files in the tarball not present in the git repo would raise suspicions, but machine-generated configure scripts containing hundreds of thousands of lines of code not present in the upstream VCS are the norm, and are usually not checked before execution.

Specific= ally in the case of PHP, along from the configure script, the tarball also bundles generated lexer files which contain actual C code, which is an additional attack vector, i.e. here's the diff between the tarball of the 8.3.4 release, and the PHP-8.3.4 tag on the git repo:

```
~ $ diff= -r php-8.3.4 php-src -q
Only in php-src: .git=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Files php-8.3.4/NEWS and php-src/NEWS differ=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Files php-8.3.4/Zend/zend.h and php-src/Zend/zend.h differ=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/Zend: zend_ini_parser.c
Only in php-8.3.4/Zend: zend_ini_parser.h
Only in php-8.3.4/Zend: zend_ini_parser.output=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/Zend: zend_ini_scanner.c
Only in php-8.3.4/Zend: zend_ini_scanner_defs.h
Only in php-8.3.4/Zend: zend_language_parser.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/Zend: zend_language_parser.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/Zend: zend_language_parser.output
Only in php-8.3.4/Zend: zend_language_scanner.c
Only in php-8.3.4/Zend: zend_language_scanner_defs.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Only in php-8.3.4: configure=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Files php-8.3.4/configure.ac and php-src/configure.ac differ=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/ext/json: json_parser.tab.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/ext/json: json_parser.tab.h
Only in php-8.3.4/ext/json: json_scanner.c
Only in php-8.3.4/ext/json: php_json_scanner_defs.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/ext/pdo: pdo_sql_parser.c
Only in php-8.3.4/ext/phar: phar_path_check.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/ext/standard: url_scanner_ex.c
Only in php-8.3.4/ext/standard: var_unserializer.c
Only in php-8.3.4/main: php_config.h.in
Files php-8.3.4/main/php_version.h and php-src/main/php_version.h differ=C2=A0=C2=A0 Only in php-8.3.4/pear: install-pear-nozlib.phar=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/sapi/phpdbg: phpdbg_lexer.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.h
Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.output
```

To preve= nt attacks from malevolent/compromised RMs, I propose completely removing all autogenerated files from the release tarballs, and ensuring their content exactly matches the content of the associated git tag (this means also removing the -dev prefix from the version number in main/php_version.h, Zend/zend.h, configure.ac and NEWS in the git tag).

Of cours= e this means that users will have to generate the build scripts when compiling PHP, as when installing PHP from the VCS repo.

I'm = sending a copy of this email to security@php.net as well.

Hey Daniil,

You can also have a public CI (i.e. a github action) generate the artifacts, along with hash computation.
It should be a github action which runs on tags. This makes it fully verifiable; i.e. the code for the generation of action, including the hash. Anyone who wants can trivially trace this back.

There's nothing in the tarballs which cannot be trivially automated and made verifiable.

I don't think providing pre-generated files is fundamentally flawed, the primary lacking thing is verifiability. Which is also what enabled the xz backdoor.

Bob

=20

This is also why our release managers sign the = tarballs with their own GPG keys, after generating the artifacts. This veri= fies the release manager was the one who generated the files.
Cheers,
Ben

Hey Ben,
I understand that the XZ project had signed relea= ses too: that still means that downstream consumers would need to trust the= release managers anyway, and reproduce the whole chain themselves.

I suppose that's part of OP= 's concern.

I agree that compromised RM is a problem that we should look i= nto.

We have been actually already discussing some= thing similar. I have been thinking about it and it could be potentially us= ed for all builds. The idea is that we would setup worklfow on CI that woul= d run on tag push and it would call (authenticated https request) downloads.php.net serve= r that could do the actual build, sign them and return the hashes to the CI= job which would display them and do extra verification (probably its own b= uild to verify that download server work as expected). Then the builds woul= d be made available for download. The RM job would be just to check that ev= erything worked as expected, potentially verify that the builds for downloa= d and do all the announcements. This is a bit of work to do but I think it = should then completely remove the possibility of compromised RM to compromi= se the builds which is currently possible. It would probably makes sense to= let RM to sign the builds as well which should then reduce chance of downl= oads server being compromised.

It needs more think= ing to iron out all details and make sure it is a secure but I think it wou= ld be something worth to look at.

We could possibly do all builds in CI and also connect this with W= indows build which could also happen in CI and the resulted builds would be= just downloaded by download server. There are various ways how to do this = and it needs careful consideration. My main point is that we should try to = move things away of building stuff on RM's machines which has got vario= us other issues as well.

Regards

Jakub
--000000000000df4bfe0614e1bce4--