GitLab.org/GitLab: Release v17.2.0-ee

Google Cloud CLI commands are now natively available when setting up workload identity federation for the Google Cloud IAM integration. Previously, the guided setup used a script downloaded through cURL commands. Also, help text has been added to better describe the setup process. These improvements help group owners set up the Google Cloud IAM integration more quickly.

Crafting commit messages is an important part of ensuring that future users understand what and why changes were made to the codebase. It's challenging to come up with a message that communicates your changes effectively and takes into account everything you might have changed.

Generation of merge commits with GitLab Duo is now Generally Available to help ensure every merge request has quality commit messages. Before you merge, select Edit commit message in the merge widget, then use the Generate commit message option to have a commit message drafted.

This new GitLab Duo capability is a great way to make sure your project's commit history is a valuable resource for future developers.

GitLab Duo for the CLI is now generally available for all users. You can now ask GitLab Duo to help you with finding the right git command for your need.

Use glab duo ask <git question> to have GitLab Duo provide you with formatted git commands to achieve your goals. The GitLab CLI then provides additional details on the commands and what they will do, including information on any flags being passed. You're then able to run the commands and get their output directly in your workflow.

The ask command for the GitLab CLI is a great way to speed up your workflow with git commands you need a little extra help remembering.

We have expanded support of custom rulesets in pipeline secret detection.

You can use two new types of passthroughs, git and url, to configure remote rulesets. This makes it easier to manage workflows such as sharing ruleset configurations across multiple projects.

You can also extend the default configuration with a remote ruleset by using one of those new types of passthroughs.

The analyzer also now supports:

• Chaining up to 20 passthroughs into a single configuration to replace predefined rules.
• Including environment variables in passthroughs.
• Setting a timeout when loading a passthrough.
• Validating TOML syntax in ruleset configuration.

GitLab Advanced SAST is now available as a Beta feature for Ultimate customers. Advanced SAST uses cross-file, cross-function analysis to deliver higher-quality results. It now supports Go, Java, and Python.

During the Beta phase, we recommend running Advanced SAST in test projects, not replacing existing SAST analyzers. To enable Advanced SAST, see the instructions. Starting in GitLab 17.2, Advanced SAST is included in the SAST.latest CI/CD template.

This is part of our iterative integration of Oxeye technology. In upcoming releases, we plan to move Advanced SAST to General Availability, add support for other languages, and introduce new UI elements to trace how vulnerabilities flow. We welcome any testing feedback in issue 466322.

API Security already has support for "overrides" which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a "per-request script" (APISEC_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for "signing" the request with a secret as a form of authentication.

As a follow up to the Continuous Vulnerability Scanning for Container scanning MVC, during 17.2 we added support for APK and RPM operating system package versions.

This enhancement allows our analyzer to fully support Continuous Vulnerability Scans for Container Scanning advisories by comparing the package versions for APK and RPM operating system purl types.

As a note, RPM versions containing a caret (^) are not supported. Work to support these versions is being tracked in this issue.

During the 17.2 release milestone, we published the following updates.

1. We added three new checks:

• Check 506.1 is a passive check that identifies request URLs that are likely compromised by the Polyfill.io CDN takeover.
• Check 384.1 is a passive check that identifies session fixation weaknesses, which could allow a valid session identifier to be reused by malicious actors.
• Check 16.11 is an active check that identifies when the TRACE HTTP debugging method is enabled on a production server, which could inadvertently expose sensitive information.

2. We addressed the following bugs to reduce false positives:

• DAST checks 614.1 (Sensitive cookie without Secure attribute) and 1004.1 (Sensitive cookie without HttpOnly attribute) no longer create findings when a site has cleared a cookie by setting an expiry date in the past.
• DAST check 1336.1 (Server-Side Template Injection) no longer relies on a 500 HTTP response status code to determine attack success.

3. We added the following enhancements:

• All response headers are now presented as evidence in a DAST vulnerability finding. This additional context reduces time spent on triaging findings.
• Sitemap.xml files are now crawled for additional URLs, leading to better coverage of target websites.

API Fuzzing already has support for "overrides" which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a "per-request script" (FUZZAPI_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for "signing" the request with a secret as a form of authentication.

During the 17.2 release milestone, we published the following updates:

• Secret Push Protection beta is now available for self-managed customers. After an administrator enables the feature instance-wide, follow our documentation to enable push protection on your projects.
• Warnings for potential leaks in text content have been enriched with more detail, making it easier to understand which type of secret is about to be leaked in a description or comment in either an issue, epic, or MR.

Vulnerability Explanation is now a part of GitLab Duo Chat and is generally available. With Vulnerability Explanation, you can open chat from any SAST vulnerability to better understand the vulnerability, see how it could be exploited, and review a potential fix.

The pipeline execution policy type is a new type of security policy that allows users to support enforcement of generic CI jobs, scripts, and instructions.

The pipeline execution policy type enables security and compliance teams to enforce customized GitLab security scanning templates, GitLab or partner-supported CI templates, 3rd party security scanning templates, custom reporting rules through CI jobs, or custom scripts/rules through GitLab CI.

The pipeline execution policy has two modes: inject and override. The inject mode injects jobs into the project's CI/CD pipeline. The override mode replaces the project's CI/CD pipeline configuration.

As with all GitLab policies, enforcement can be managed centrally by designated security and compliance team members who create and manage the policies. Learn how to get started by creating your first pipeline execution policy!

Scan execution policies have been expanded to allow you to choose between default and latest GitLab templates when defining the policy rules. While default reflects the current behavior, you may update your policy to latest to use features available only in the latest template of the given security analyzer.

By utilizing the latest template, you may now ensure scans are enforced on merge request pipelines, along with any other rules enabled in the latest template. Previously this was limited to branch pipelines or a specified schedule.

Note: Be sure to review all changes between default and latest templates before modifying the policy to ensure this suits your needs!

GitLab is now disabling AI input and output logging for GitLab Duo by default.

At GitLab, we aim to ensure that customers have sovereignty over their data. We've now disabled input and output logging by default and will only log inputs and outputs with customers' explicit consent via a GitLab Support ticket.

An accessible record of deployment events, like deployment approvals, is essential for compliance management. Until now, GitLab did not provide deployment-related audit events, so compliance managers had to use custom tooling or search for this data in GitLab directly. GitLab now provides three audit events:

• deployment_started records who started a deployment job, and when it was started.
• deployment_approved records who approved a deployment job, and when it was approved.
• deployment_rejected records who rejected a deployment job, and when it was rejected.

When you perform a review, you can complete it by choosing whether to approve, comment, or request changes (released in GitLab 16.9). While reviewing, you might find changes that should prevent a merge request from merging until they're resolved, and so you complete your review with request changes.

When requesting changes, GitLab now adds a merge check that prevents merging until the request for changes has been resolved. The request for changes can be resolved when the original user who requested changes re-reviews the merge request and subsequently approves the merge request. If the user who originally requested changes is unable to approve, the request for changes can be Bypassed by anyone with merge permissions, so development can continue.

Leave us feedback about this new feature in issue 455339.

GitLab Duo Chat and Code Suggestions are now available in workspaces! Whether you're seeking quick answers or efficient code improvements, Duo Chat and Code Suggestions are designed to boost productivity and streamline your workflow, making remote development in workspaces more efficient and effective than ever.

With this release, we've implemented a new authorization strategy for workspaces to address the limitations of the legacy strategy while providing group owners and administrators more control and flexibility. With the new authorization strategy, group owners and administrators can control which cluster agents to use for hosting workspaces.

To ensure a smooth transition, users on the legacy authorization strategy are migrated automatically to the new strategy. Existing agents that support workspaces are allowed automatically in the root group where these agents are located. This migration also occurs even if these agents have been allowed in different groups in a root group.

The compliance center is the central location for compliance teams to manage their compliance standards adherence reporting, violations reporting, and compliance frameworks for their group.

Previously, all of the associated features of the compliance center were only available for top-level groups. This meant that for subgroups, owners didn't have access to any of the functionality provided by the compliance center on the top-level group.

To help address these key pain points, we've added the ability to assign and unassign compliance frameworks for subgroups. Now, group owners can visualize their compliance posture at the subgroup level in addition to the full top-group-level compliance centre dashboard that was already available.

We have updated the sorting and filtering functionality of the group overview page. The search element now stretches across the whole page, allowing you to see your search strings better. We have standardized the sorting options to Name, Created date, Updated date, and Stars.

We welcome feedback about these changes in issue 438322.

We added a new endpoint to the Groups API to list the groups a group has been invited to. This functionality complements the endpoint to list the projects that a group has been invited to, so you can now get a complete overview of all the groups and projects that your group has been added to. The endpoint is rate-limited to 60 requests per minute per user.

Thank you @imskr for this community contribution!

Discussions on GitLab issues can get busy. GitLab helps you manage these conversations by raising a to-do item for comments that are relevant to you, and automatically resolves the item when you take an action on the issue.

Previously, when you took action on a thread in the issue, all to-do items were resolved, even if you were mentioned in several different threads. Now, GitLab resolves only the to-do item for the thread you interacted with.

You can import projects to GitLab from other SCM solutions. However, it was difficult to know if project items were imported or created on the GitLab instance.

With this release, we've added visual indicators to items imported from GitHub, Gitea, Bitbucket Server, and Bitbucket Cloud where the creator is identified as a specific user. For example, merge requests, issues, and notes.

Previously, when using GitLab for Jira Cloud app, if you deleted a branch in GitLab, that branch still appeared in Jira development panel. Selecting that branch caused a 404 error on GitLab.

From this release, branches deleted in GitLab are removed from the Jira development panel.

GitLab offers many settings across projects, groups, the instance, and for yourself personally. To find the setting you're looking for, you often have to spend time clicking through many different areas of the UI.

With this release, you can now search for project settings from the command palette. Try it out by visiting a project, selecting Search or go to..., entering command mode with >, and typing the name of a settings section, like Protected tags. Select a result to jump right to the setting itself.

In GitLab 16.1, we introduced the Kubernetes pod list and detail views. However, you still had to use third-party tools for an in-depth analysis of your workloads. GitLab now ships with a log streaming view for pods and containers, so you can quickly check and troubleshoot issues across your environments without leaving your application delivery tool.

In GitLab 17.2, wiki page titles are separate from their paths. In previous releases, if a page title changed, the path would also change, which could cause links to the page to break. Now, if a wiki page's title changes, the path remains unchanged. Even if a wiki page path changes, an automatic redirect is set up to prevent broken links.

GitLab 17.2 adds several enhancements to how wikis display the sidebar. Now, a wiki displays all pages in the sidebar (up to 5000 pages), displays a table of contents (TOC), and provides a search bar to quickly find pages.

Previously, the sidebar lacked a TOC, making it challenging to navigate to sections of a page. The new TOC feature helps to see the page structure clearly, as well as navigate quickly to different sections, greatly improving usability.

The addition of a search bar makes discovering content easier. And because the sidebar now displays all pages, you can seamlessly browse an entire wiki.

Issues, tasks, incidents, requirements, objectives, and key results all trigger payloads under the Issues Events webhook category. Until now, there has been no way to quickly determine the type of object that triggered the webhook within the event payload. This release introduces an object_attributes.type attribute available on payloads within the Issues events, Comments, Confidential issues events, and Emoji events triggers.

Back in September 2021, git-lfs 3.0.0 released support for using SSH as the transfer protocol instead of HTTP. Prior to git-lfs 3.0.0, HTTP was the only supported transfer protocol which meant using git-lfs at GitLab was not possible for some users. With this release, we're very excited to offer the ability to enable support for SSH over HTTP as the transfer protocol for git-lfs.

Thank you to Kyle Edwards and Joe Snyder for this contribution!

You can now sort the pipeline schedules list by description, ref, next run, created date, and updated date.

We're releasing GitLab Runner 17.2 today! GitLab Runner is the lightweight, highly scalable agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What's new:

• GitLab Runner fleeting plugin for AWS EC2 instances (GA)
• Permit configuration of Runner livenessProbe and readinessProbe
• Ability to enable and disable the umask 0000 command for the Kubernetes executor
• Support for Red Hat OpenShift 4.16 for the GitLab Runner Operator

Bug Fixes:

• Gitlab Runner upgrade removes all cache volumes

For a list of all changes, see the GitLab Runner CHANGELOG.

The Terraform module registry now displays Readme files! With this highly requested feature, you can transparently document the purpose, configuration, and requirements of each module.

Previously, you had to search other sources for this critical information, which made it difficult to properly evaluate and use modules. Now, with the module documentation readily available, you can quickly understand a module's capabilities before you use it. This accessibility empowers you to confidently share and reuse Terraform code across your organization.

GitLab now supports the OAuth 2.0 device authorization grant flow. This flow makes it possible to securely authenticate your GitLab identity from input constrained devices where browser interactions are not an option. This makes the device authorization grant flow ideal for users attempting to use GitLab services from headless servers or other devices with no, or limited, UI. Thank you John Parent for your contribution!

Administrators can now run a script that identifies dates when multiple access tokens expire. You can use this script in combination with other scripts on the token troubleshooting page to identify and extend large batches of tokens that might be approaching their expiration date, if token rotation has not yet been implemented.

The OAuth authorization screen now more clearly describes the authorization you are granting. It also includes a "verified by GitLab" section for applications that are provided by GitLab. Previously, the user experience was the same, regardless of whether an application was provided by GitLab or not. This new functionality provides an extra layer of trust.

The administrator setup experience for a new install of GitLab has been streamlined and made more secure. The initial administrator root email address is now randomzied, and administrators are forced to change this email address to an account that they can access. Previously, this step could have been delayed, and an administrator might forget to change the email address.

In GitLab 17.2, we've added support for the Users API to the GitLab Data Connector, which is available in the Snowflake Marketplace app. You can now stream user data from self-managed GitLab instances to Snowflake using the Users API.

In GitLab 15.3 we introduced the compare_to keyword for rules:change. This made it possible to define the exact ref to compare against. Beginning in GitLab 17.2, you can now use CI/CD variables with this keyword, making it easier to define and reuse compare_to values in multiple jobs.