- Zuul-announce - lists.opendev.org

Change to default value for enable_fips parameter in enable-fips playbook in zuul-jobs
by Ade Lee 23 Jan '23

23 Jan '23

Hi all, This is just an announcement that the enable_fips parameter in https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/enable-fips/… is being changed from being True by default to being False by default. Any jobs that use this playbook (and wish to enable fips) will need to explicitly set enable_fips to True. The reason for this change is as follows: Turing FIPS on requires a reboot. For most consistent results, we want this to occur early in the node setup so that subsequent setup is not affected by a reboot. To do this, we need to run the playbook as part of a base job. Defaulting enable_fips to false allows us to add this playbook to most jobs. Descendant jobs can then simply enable FIPS mode by simply setting enable_fips mode to True. More details can be found in the change: https://review.opendev.org/c/zuul/zuul-jobs/+/866881 Thanks, Ade Lee

1 0

Nodepool 8.1.0 released
by James E. Blair 18 Jan '23

18 Jan '23

The Zuul team is pleased to announce the release of Nodepool 8.1.0. Download it from PyPI: https://pypi.org/project/nodepool Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/nodepool/8.1.0/releasenotes.html While not addressed directly by Nodepool, note that container images starting with this release include a version of git patched to address CVE-2022-23521. Upgrade Notes ============= * In the OpenStack driver, when using `min-ram` in combination with a `flavor-name`, the first flavor to be found that satisfied the `min-ram` requirements and contained the substring `flavor-name` would be used. The order of the flavors to be searched was dependent on what the cloud returned. From this release, the available flavors are now alphabetically sorted before matching `flavor-name`.

1 0

Zuul 8.1.0 released [security]
by James E. Blair 18 Jan '23

18 Jan '23

The Zuul team is pleased to announce the release of Zuul 8.1.0. Download it from PyPI: https://pypi.org/project/zuul Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/zuul/8.1.0/releasenotes.html Benjamin Schanzel discovered that pipeline requirements were not checked for dependent changes in a post-review independent pipeline. If an independent pipeline was configured so that it only runs jobs for reviewed code, dependent changes could be used to bypass that requirement and cause unreviewed code to be included in jobs. This vulnerability has been present since Zuul version 3.0.0. Zuul will now check pipeline requirements for all changes (including dependent changes that are only enqueued for the purpose of providing speculative git repo states). While not addressed directly by Zuul, note that container images starting with this release include a version of git patched to address CVE-2022-23521. Security Issues =============== * Non-live items are now subject to pipeline requirements for independent pipelines. Previously, an optimization for independent pipelines skipped checking that a change met the pipeline requirements. If an independent pipeline is intended only to run reviewed code, this could allow running unreviewed code by updating dependent changes. Now both non-live and live items are subject to pipeline requirements in all pipeline managers. The new allow-other-connections pipeline configuration option may now be used to ensure that only changes from connections which are mentioned in the pipeline configuration (such as triggers, reporters, or pipeline requirements) are enqueued. This allows the construction of a pipeline where, for example, code review requirements are strictly enforced, even for dependencies which are not normally directly enqueued. New Features ============ * A new pipeline attribute, pipeline.allow-other-connections, has been added to ensure that only changes from connections which are mentioned in the pipeline configuration (such as triggers, reporters, or pipeline requirements) are enqueued. * Zuul now stores the pause and resume events for a build together with their timestamp and reports them to the SQL database and via MQTT. * Individual playbooks may now be wrapped by a semaphore. Zuul will start the job and proceed up to the point of a playbook which requires a semaphore and then wait until it is able to aquire the semaphore before proceeding. It releases the semaphore after the end of that individual playbook. The same semaphore may be used for both jobs and playbooks, but an individual job may not use the same semaphore for both purposes. Upgrade Notes ============= * Additional syntax checking is performed on job configuration changes so that Zuul will report an error if a job inherits from a non-permitted parent (such as a final job, intermediate job when the child is not abstract, or a protected job in another project). Previously, these situations might only be discovered when freezing a job graph. If any jobs currently in this situation exist, they will be reported as configuration errors.

1 0

Nodepool 8.0.1 released
by James E. Blair 12 Jan '23

12 Jan '23

The Zuul team is pleased to announce the release of Nodepool 8.0.1. Download it from PyPI: https://pypi.org/project/nodepool Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/nodepool/8.0.1/releasenotes.html New Features ============ * The nodepool command now includes a “hold” subcommand. Bug Fixes ========= * The Kubernetes driver now supports version 1.24+

1 0

ensure-tox and tox v4
by James E. Blair 08 Dec '22

08 Dec '22

The tox project has released a major version upgrade (v4) with some backwards incompatible changes[0]. This has caused some problems for the ensure-tox role (and the many tox-related jobs that use it) in zuul-jobs. Clark Boylan was able to address several of the compatibility issues that affected how tox is used internally in the role[1] (e.g., siblings installation and log copying). But it became apparent that some of the breaking changes are related to the configuration of projects that use tox. For example, the "whitelist_externals" option has been renamed and using the old option produces an error. The ensure-tox role has, to date, not had a method for specifying what version of tox to install, instead, always installing the latest. To enable projects to upgrade their support to tox v4 at their own pace, we are adding a new role variable, "ensure_tox_version" which can be used to specify what tox version the ensure-tox role should install. This variable has been added, and it currently defaults to "<4" so that the latest tox 3.x version is installed. On December 22, we will update the default to be "" (the empty string) which will once again mean that ensure-tox will install the latest version of tox[2]. We recommend that you use this time to update your tox configuration to work with tox v4. If you are unable to do so before December 21, you can set the "ensure_tox_version" variable to "<4" on your jobs. [0] https://discuss.python.org/t/tool-tox-4-on-the-horizon/6537 [1] https://review.opendev.org/866935 [2] https://review.opendev.org/866943

1 0

Potential log upload credential exposure in zuul-jobs
by James E. Blair 16 Nov '22

16 Nov '22

Clark Boylan recently discovered that some of the log upload roles in the zuul-jobs repo were missing `no_log: true` settings and can write credentials to the job-output.json file. These are written to the file after the logs have been uploaded, and so are not included in the uploaded logs. This means that accidental exposure in typical usage is unlikely. A malicious user could write a cleanup-run playbook to read in the contents of the file and send the credentials off-host. The zuul-jobs repo has been updated to correct this problem, so if you include it in your tenant configuration directly, it will automatically be updated. If you use a local mirror of zuul-jobs, you should update it immediately. The update to zuul-jobs is this commit: https://opendev.org/zuul/zuul-jobs/commit/622baa65bfa02a592024a867c5bd94a8a…

1 0

Zuul 8.0.1 released
by James E. Blair 03 Nov '22

03 Nov '22

The Zuul team is pleased to announce the release of Zuul 8.0.1. Download it from PyPI: https://pypi.org/project/zuul Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/zuul/8.0.1/releasenotes.html Bug Fixes ========= * An error which prevented results from appearing in the web UI on the "Buildsets" tab has been corrected.

1 0

Zuul 8.0.0 released
by James E. Blair 01 Nov '22

01 Nov '22

The Zuul team is pleased to announce the release of Zuul 8.0.0. Download it from PyPI: https://pypi.org/project/zuul Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/zuul/8.0.0/releasenotes.html New Features ============ * Read-level access to tenants or the tenant list may now be restricted to authorized users using the tenant.access-rules and api-root.access-rules attributes. * The rebase merge-mode is now supported for GitHub. Upgrade Notes ============= * Support for Ansible version 5 has been removed. Migrate any existing jobs which rely on this version to Ansible version 6 before upgrading. * In preparation for expanded access control features in the web interface, and REST API, the admin-rule tenant configuration object has been renamed to authorization-rule. When applied to a tenant, the tenant attribute is still admin-rules since it determines admin access to that tenant. This change will allow similar rules to be applied to non-admin level access in the future. Tenant configs should now follow this example: - authorization-rule: name: example-rule - tenant: name: example-tenant admin-rules: - example-rule The old form is still permitted for backwards compatability, but will be removed in a later version of Zuul. * The default merge mode used by Zuul for preparing git repos was previously merge-resolve in all cases, but is now merge for all drivers except Gerrit, where merge-resolve is still the default. This makes the merge operations performed by Zuul more closely match the operations that will be performed by the code review systems. Bug Fixes ========= * The use of implied branch matchers in jobs where override-checkout was specified could cause some jobs to include unintended variants. Specifically: job variants with implied branch matchers on branches which are substring matches of a branch specified in the override-checkout job attribute may have been used when not intended. * This has been corrected so that the same job variant matching process happens whether the change’s branch or the branch specified by override-checkout is used.

1 0

Nodepool 8.0.0 released
by James E. Blair 01 Nov '22

01 Nov '22

The Zuul team is pleased to announce the release of Nodepool 8.0.0. Download it from PyPI: https://pypi.org/project/nodepool Find container images at: https://hub.docker.com/u/zuul The release notes, included below, are also available in the documentation with hyperlink references: https://zuul-ci.org/docs/nodepool/8.0.0/releasenotes.html New Features ============ * The AWS driver now support specifying volume IOPS and throughput; see: providers.[aws].pools.labels.iops, providers.[aws].pools.labels.throughput, providers.[aws].diskimages.iops, and providers.[aws].diskimages.throughput. * The OpenStack, AWS, and Azure drivers now support adding tags (AKA metadata, AKA properties) to instances with dynamic data about the corresponding node request using string formatting. See providers.[openstack].pools.labels.instance-properties, providers.[aws].pools.labels.dynamic-tags, and providers.[azure].pools.labels.dynamic-tags for details. * The AWS and Azure drivers now support adding tags to images via the providers.[aws].diskimages.tags, and providers.[azure].diskimages.tags attributes. The OpenStack driver already supported similar behavior with its meta attribute. The diskimages.metadata attribute has been added and will supply default values to the provider image tag attributes mentioned above. * A new configuration option for K8s Pod type labels was added to limit the amount of ephemeral storage allocatable in a container (cf. K8s Local ephemeral storage resource documentation <https://kubernetes.io/docs/concepts/configuration/manage-resources-containe…>) This limit can be set via the integer value of providers.[kubernetes].pools.labels.storage and is treated as Megabytes. Also, a pool-scoped default value can be specified via providers.[kubernetes].pools.default-label-storage

1 0

Zuul and OpenSSL 3.x Security Vulnerabilities
by Clark Boylan 01 Nov '22

01 Nov '22

OpenSSL disclosed two security vulnerabilities [0] affecting OpenSSL 3.0 and newer. Prior to disclosure these issues were rated critical but on further analysis were degraded to high. We believe the impact to Zuul is minimal, but are sending this email as this situation has received a lot of attention. Zuul users should be informed about the inner workings of the software they run. Zuul does use OpenSSL for a number of functions. In particular, cert based client auth is performed on the Zookeeper connection (and potentially with OpenTelemetry if enabled). This means that Zuul installations connecting to a malicious Zookeeper server (or OpenTelemetry endpoint) could potentially be exploited. The official Zuul Docker images are based on Debian Bullseye which does not include OpenSSL 3.x and should not be affected. Users who have installed on Ubuntu Jammy or RHEL 9 (or any of its derivatives) should update their OpenSSL packages to avoid any problems. The Ubuntu page for this CVE [1] notes that stack protections should limit the impact of this bug on Ubuntu to denials of service further reducing the potential impact to Zuul. [0] https://www.openssl.org/news/secadv/20221101.txt [1] https://ubuntu.com/security/CVE-2022-3602

1 0