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

We're thrilled to introduce support for protected npm packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.

From GitLab 17.5, you can protect npm packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.

The Credentials Inventory is now available for top-level group Owners on GitLab.com. In the Credentials Inventory, you can view your enterprise user's personal access tokens and SSH keys across your group. You can also revoke, delete, and view additional information about the credentials. Previously, this was only available for administrators on GitLab self-managed.

Group Owners can use the Credentials Inventory to understand the credentials that exist in their purview, and provide increased visibility and control.

Enterprise users can authenticate using a local account with username and password. Now, group Owners can disable password authentication for the group's enterprise users. If password authentication is disabled, enterprise users can use either the group's SAML identity provider to authenticate with GitLab web UI, or a personal access token to authenticate with GitLab API and Git using HTTP Basic Authentication.

You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for Code Suggestions. This feature is in beta and available with an Ultimate and Duo Enterprise subscription on self-managed GitLab environments.

With self-hosted models, you can use models hosted either on-premise or in a private cloud to enable GitLab Duo Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.

Please leave feedback in the feedback issue.

In response to your feedback, GitLab Duo Chat is now aware of merge requests. Whether you are a reviewer or an author, you can now converse with Chat about a merge request to quickly dig into it, or learn what to do next. Simply open your merge request and open Duo Chat, then start the conversation.

This new feature complements our existing feature, where you can quickly populate the description of a merge request by asking GitLab Duo to summarize code changes, so that reviewers can get a general understanding of what the merge request is about.

Switchboard's new Tenant Overview now provides a single place to quickly access essential information about your GitLab Dedicated instance.

With this first release, you can now view your current GitLab version, instance URL, and the date and time of your upcoming and past maintenance windows all on the Tenant Overview page.

Until now, the agent for Kubernetes could be used only if the Kubernetes cluster could connect to the GitLab instance. This issue meant that some customers couldn't use the agent if, for example, they ran GitLab on a private network or behind a firewall. From GitLab 17.5, you can initiate the cluster-GitLab connection from GitLab, assuming that a properly configured agentk instance is already waiting for a connection initialization.

Once the initial connection is established, all the features of the agent are available. Initializing from a cluster is not changed with this development.

Previously, AI impact analytics were available only on GitLab.com to GitLab Duo Enterprise customers, and on GitLab self-managed with a ClickHouse integration. Additionally, the default metrics were aggregated.

Now, you can export raw code suggestion events from the GraphQL API. This way you can import the data into your data analysis tool to get deeper insights into acceptance rates across more dimensions, such as suggestion size, language, and user. The raw events are not stored in ClickHouse, so some AI Impact Analytics metrics become available to all GitLab deployments, including GitLab Dedicated and self-managed.

We're excited to announce that Secret Push Protection is now generally available for all GitLab Ultimate customers.

If a secret, like a key or an API token, is accidentally committed to a Git repository, anyone with access to the repository can impersonate the user of the secret for malicious purposes. A leaked secret costs time and money, and potentially damages a company's reputation. Secret push protection helps reduce the remediation time and reduce risk by protecting secrets from being pushed in the first place.

Secret push protection has been improved since the beta release. When commits are pushed by using the Git CLI, now only the changes (diff) are scanned for secrets. We've also added experimental support for excluding paths, rules, or specific values to avoid false positives.

To learn more, see the blog.

We've added Ruby support to GitLab Advanced SAST. To use this new cross-file, cross-function scanning support, enable Advanced SAST. If you've already enabled Advanced SAST, Ruby support is automatically activated.

In the last month, we've also released updates to improve the detection rules for the other languages Advanced SAST supports by:

• Detecting additional Java path traversal, Java command injection, and JavaScript path traversal vulnerabilities.
• Updating CWE mappings to more specifically and consistently identify vulnerability types.
• Increasing the severity of path traversal vulnerabilities.

To see which types of vulnerabilities Advanced SAST detects in each language, see the new Advanced SAST coverage page.

To learn more about Advanced SAST, see last month's announcement blog.

Now, in GitLab, you can filter for specific dependency components quickly to identify whether or not they are used in your group or project. It is time consuming and inconvenient to manually go through the entire list just to verify whether or not a particular package and version is present. With the new filter by component on the dependency list, you isolate vulnerable dependencies so that you can assess open risks in your application.

You can now target groups/subgroups in security policy scopes. This extends the existing options allowing you to target all projects in a group/subgroup, projects based on a defined project list, and projects matching a list of compliance framework labels.

This gives you further flexibility in enabling policies across your groups, while also being able to apply exceptions to scope projects out of enforcement where necessary.

This improvement also precedes a number of enhancements that will simplify the process of linking security policy projects and granularly scoping enforcement of policies.

In GitLab 17.3, we announced the deprecation of compliance pipelines and its eventual removal by the 18.0 release. Instead of compliance pipelines, you should use the pipeline execution policy type instead, which was released in GitLab 17.2.

To help you migrate your existing compliance pipelines over to the pipeline execution policy type, this release includes a warning banner that:

• Notifies users about the deprecation of compliance pipelines.
• Provides a prompted and guided workflow to migrate existing compliance pipelines to the pipeline execution policy type.

Introducing Duo Quick Chat, an AI-powered chat designed to work exactly where you are in your code. Duo Quick Chat operates directly on the lines you're editing, offering real-time assistance without ever moving you away from your code. Whether you're refactoring, fixing bugs, or writing tests, Duo Quick Chat provides suggestions and explanations on the spot, ensuring that you stay fully focused without switching context.

Empower your development workflow with Duo Chat, now seamlessly integrated into Visual Studio for Windows. Duo Chat enhances your coding experience by providing AI-powered capabilities to explain, refine, debug code, or write tests all in real-time. This integration allows you to leverage Duo Chat's advanced AI tools directly within your familiar development environment, improving productivity and enabling faster, more efficient problem-solving.

Previously, the compliance center was available only for top-level groups and subgroups.

With this release, we've added the compliance center to projects. At this level, compliance center provides view-only capabilities for checks and violations that pertain to a particular project.

To add or edit a framework, you should access the compliance center on top-level groups instead.

GitLab 17.5 includes an update to our version of the NGINX Ingress Controller. The nginx-controller container image is now version 1.11.2. Please note this includes new RBAC requirements because the new controller now uses endpointslices and requires an RBAC rule to access them.

GitLab 17.5 includes support for upgrading PostgreSQL from version 14.x to 16.x for single node installations. Automatic upgrades are not enabled and so PostgreSQL upgrades must be triggered manually.

You can check the status of your pods and Flux reconciliation from the GitLab environments UI. However, this approach is hard to scale because the required settings are exposed only through GraphQL or the UI. Now, GitLab ships with REST API support for configuring an agent for Kubernetes, as well as setting the namespace and Flux resource per environment. To further improve support for dynamic environments, issue 467912 proposes adding support for configuring these settings in CI/CD pipelines.

GitLab offers flexible, reliable, and secure GitOps support with the agent for Kubernetes and its Flux integration. Still, bootstrapping Flux with GitLab and setting up the agent for Kubernetes used to require a lot of documentation reading and switching between the GitLab UI and the terminal. The GitLab CLI now offers the glab cluster agent bootstrap command to simplify installing the agent on top of an existing Flux installation. Now, you can configure Flux and the agent with just two simple commands.

GitLab provides a real-time view of your pods, as well as pod log streaming, all through the dashboard for Kubernetes. In GitLab 17.4, we offered a static listing of resource-specific event information from the UI. This release further improves the dashboard for Kubernetes by letting you stream incoming events as they emerge in the cluster.

As a Flux user, have you ever needed to quickly stop an automatic reconciliation or drift remediation? Have you wanted to trigger a HelmRelease to synchronize manually removed resources? These actions are best achieved with the Flux suspend and resume functions. Until now, your best option was to use the Flux CLI, which required a context switch and several commands to ensure the right resource was affected. In GitLab 17.5, you can suspend or resume a reconciliation from the built-in dashboard for Kubernetes.

In GitLab 15.10, we introduced a consolidated view for branch-related settings and rules. This view provided you with an easy way to understand the configuration of your project across multiple settings.

Building on this feature, you can now directly modify specific branch rules in this view, including branch protections, approval rules, and external status check configurations. These new capabilities lay the foundation for continued improvements in branch configuration that will allow for greater flexibility in the future.

We encourage you to explore these new capabilities and to provide feedback. You can do this by contributing to our dedicated feedback issue.

We’re also releasing GitLab Runner 17.5 today! GitLab Runner is the highly-scalable build 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:

• Support AWS S3 multipart uploads with scoped temporary credentials

Bug Fixes:

• Jobs with extra services don't complete if one of the service container is not running
• The gitlab-runner-fips-17.4.0-1 package fails to run on Amazon Linux 2 and returns a glibc error
• Cache doesn't work with Amazon S3 when using S3 Express One Zone endpoints
• Jobs are unable to pull base images if the DOCKER_AUTH_CONFIG variable has multiple registries

We're excited to announce a significant improvement to our Container Registry API for self-managed GitLab instances. With the release of GitLab 17.5, we've implemented keyset pagination for the :id/registry/repositories/:repository_id/tags endpoint, bringing it in line with the functionality already available on GitLab.com. This enhancement is part of our ongoing efforts to improve API performance and provide a consistent experience across all GitLab deployments.

Keyset pagination offers a more efficient method for handling large datasets, resulting in improved performance and a better user experience. This update is particularly useful when managing large container registries, as it allows for smoother navigation through repository tags. In order to use this feature, self-managed instances must upgrade to the next-generation container registry.

Administrators now have an enhanced, summarized view of the following critical pieces of information about the users on their instance:

• Pending approval.
• Without two-factor authentication.
• Administrators.

This increases user management efficiency, because administrators can quickly see how many users are in these states from the summary view, and filter on them.

You can now view which groups, subgroups, and projects a token is associated with. This makes it easier to determine the impact of token expirations or revocations, and to understand where a token is able to be used.

Previously, when SAML SSO was enabled, groups could choose to enforce SSO, which required all members to use SSO authentication to access the group. However, some groups want the security of SSO enforcement for employees or group members, while still allowing outside collaborators or contractors to access their groups without SSO.

Now, groups with SAML SSO enabled have SSO automatically enforced for all members who have a SAML identity. Group members without SAML identities are not required to use SSO unless SSO enforcement is explicitly enabled.

A member has a SAML identity if one or both of the following are true:

• They signed in to GitLab using their GitLab group's single sign-on URL.
• They were provisioned by SCIM.

To ensure smooth operation of the selective SSO enforcement feature, ensure your SAML configuration is working properly before selecting the Enable SAML authentication for this group checkbox.