Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118902 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26619 invoked from network); 28 Oct 2022 17:12:16 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Oct 2022 17:12:16 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EC330180054 for ; Fri, 28 Oct 2022 10:12:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 28 Oct 2022 10:12:14 -0700 (PDT) Received: by mail-qv1-f51.google.com with SMTP id j6so4453267qvn.12 for ; Fri, 28 Oct 2022 10:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SXI3CE1OOdiYyDbCZTlibouJK7ukPe79Qtc6DuasaRE=; b=bfu8CIEREwR/5UChKltCv2qHXplXKVOsdGBx6dcfylkQhIUAxJwd78P0zyfhKBCfxl i3q5LVJyvCfY7jfMbAvIjq+9DYKWda3KvmfDy6Mlle+aLGIUCfGA5o1opzhunyDlr7Rw sIcaVvRS/gN6ExJvws4+Jdoist0/lG4+xXahWK+02hl9hHb2DIPDBmpcTDyQGBbv2noQ KaeRBVEf8VQte3VGtpgdJezOswYJ11U5PPfrSq9FHmSwTBEDMs4L6kp2OFnizUxfs8/1 QFJgbAgecQhzsM8OetJsvBRUN72jfdk0aALJhbvH+YlQwwmcmvjJZFvlJsnbfegkKYJP GhkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=SXI3CE1OOdiYyDbCZTlibouJK7ukPe79Qtc6DuasaRE=; b=XxBAxcI091PTOGtVue1LWnsGM4WUxTbCl39jTfwIzL4ni42fQ6zXiy8ytgxWP+IpmA o8pZsaF3jIVjuxTa5iC76San8JMELSNmYc0kkG9rEgILEWqXPytoEgiUffsRPXwtP05a wVJiw1PHjeXt7xCLOsyqkznG1UsBfZhLVkrBwqx5j3y3KelUY5Ex4csxo9XNEQLlPITD xaLVMTTaXXqh53dk8uHwYOOnIJfIsS3D9ZDi42Xw1D3CBup3qk19OLn2cOUI5GyW6J72 acUlc3qWiFgvMh2kIiffyEOBvDVyZ2j8kQtXSvVdk7C1J6Q+x2susCTbpoU4OQcSoxbv sQMA== X-Gm-Message-State: ACrzQf03P3gBLq1lrrcDo2tPSJ+AL62LiYWy3JqYDw4Cc5W10kj9jp6s gNhPqQX9EIclcw4idzOAjHkDH2DrQwHO3RqbLuY5PL6NVNE= X-Google-Smtp-Source: AMsMyM6qj4Hra3B788X3yrshH2f2+iBzjftiztJK75pLMnwJriQljJs5/ayeUNyhu1ZL+fIjwsDDrGjFS0jfS1sPLaQ= X-Received: by 2002:ad4:4d11:0:b0:4bb:5ad6:a9d9 with SMTP id l17-20020ad44d11000000b004bb5ad6a9d9mr342652qvl.67.1666977133643; Fri, 28 Oct 2022 10:12:13 -0700 (PDT) MIME-Version: 1.0 References: <19932b6e-efe8-d24a-0e1e-e8960fb1566b@bastelstu.be> In-Reply-To: <19932b6e-efe8-d24a-0e1e-e8960fb1566b@bastelstu.be> Reply-To: Pedro Nacht Date: Fri, 28 Oct 2022 14:11:57 -0300 Message-ID: To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: Jordan LeDoux , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000e686ea05ec1b5b08" Subject: Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action From: internals@lists.php.net ("Pedro Nacht via internals") --000000000000e686ea05ec1b5b08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim, Thank you for the feedback, I'll be sure to pass it on to the Scorecards team. And if there's interest, I'll happily fix that small inconsistency in the labeler.yml permissions. And with this I believe I'll go ahead and close the GH issue and PR. I'll stay in the mailing list for a few more days if anyone has any further questions or comments. Truly thank you everyone for your time, Pedro On Thu, Oct 27, 2022 at 7:32 PM Tim D=C3=BCsterhus wrote= : > Hi > > I'm also highly sceptical of wasting CPU time on such an automated scan. > > Once the few universally useful low-hanging fruits are picked, only the > non-low-hanging fruits remain by definition. If they are not implemented > reasonably timely then there is likely a reason for that, be that > technical or processual. Then there is also no need for the reports to > sit within the Security tab forever and also no need for them to be > rechecked by maintainers regularly. Then there's also the issue of > what's effectively false-positives (see below) which further distract > from whatever benefit to the automated scan there might be in the first > place. > > On 10/24/22 19:05, Pedro Nacht via internals wrote: > > - set GitHub workflow dependencies to adopt hash-pinning instead of > > major-version pinning. This is to eliminate the risk of tag-hijacki= ng > > attacks where a malicious commit is published to an Action you rely > on and > > the tag is then recreated to point to that malicious commit. > Dependabot or > > Renovatebot (which the tool also recommends adding to the project) > can then > > be used to keep your dependencies up-to-date. > > Is there any practical benefit to this when all the workflows are > read-only with regard to the repository contents? > > On the contrary I believe that hashes make it much harder to verify > which major version of an action is used, e.g. to check the changelog > for any relevant breaking changes before upgrading the action. > > > - set all GitHub workflows with top-level read-only permissions. It > > recognizes that almost all PHP's workflows have top-level read-only > > permissions, but points out that github/workflows/labeler.yml doesn'= t > > (though it does have job-level contents read-only permissions). > > I consider that a false-positive then, because the workflows *is* secure > in practice. No need to waste maintainers time with the busy-work of > moving the 'permissions' section around. > > I can see the small benefit of consistency across workflows, though and > will likely send a PR to unify this if no one beats me to it. > > > - and yes, enforce Code-Review and maximal Branch-Protection. I > > understand this would be quite impactful on the project's current > workflow, > > but it's the sort of thing that would mitigate the sort of > > attack @ricardoboss mentioned in the linked GH issue. Whether the > costs are > > worth the benefit is a question you are all certainly better equippe= d > to > > determine than me. > > I would hope none of the core contributers disputes the benefit of code > review, so =E2=80=A6 there is no need for a tool to tell them what they a= lready > know. > > > However, others offer more continuous monitoring in case there's an > > accidental slip-up: if any new workflows are added to the project in th= e > > future without minimal permissions or without pinning dependencies, for > > example, the Action will update the Security Dashboard with an alert. > > The repository is already configured to only grant "read" permissions to > the workflow by default using this setting: > > > https://docs.github.com/en/repositories/managing-your-repositorys-setting= s-and-features/enabling-features-for-your-repository/managing-github-action= s-settings-for-a-repository#configuring-the-default-github_token-permission= s > > I believe this is a much more reliable solution than expecting the > maintainers to regularly check the Security Tab and noticing that a new > warning popped up. > > The proposed automated scanner does not appear to detect that this > setting is enabled, thus effectively making the labeler.yml report a > double false-positive. > > Best regards > Tim D=C3=BCsterhus > --000000000000e686ea05ec1b5b08--