GitLab 14.5 released with infrastructure as code security scanning and group-level merge request approvals
Today, we are thrilled to announce the release of GitLab 14.5 with infrastructure as code security scanning, group-level merge request approvals settings, Kubernetes Agent available in GitLab Free, project topics, and much more!
These are only a selection of highlights from the 40+ improvements in this release. Read on to check out all of the super updates below.
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 14.6 release kickoff video.
This month's Most Valuable Person (MVP) is Jonas Wälter
Jonas has been a long-time contributor to GitLab, working along GitLab team members at complex changes to group-level authentication apps, and in 14.5, he has made another stellar contribution to improve project topics. He created over 22 merge requests to enable a separation of topics from tags in GitLab.
While implementing project topics, Jonas ran into a blocker. To enable topics, he had to move the topics out of the tags table in the database. Jonas’s Sharding contribution also unblocked the Sharding group’s efforts. Way to go Jonas! 👏
Introducing Infrastructure as Code (IaC) security scanning
With Gitlab 14.5 we’re introducing security scanning for Infrastructure as Code (IaC) configuration files. Like all our SAST scanners, we’ve chosen to make this capability available for all customers for free to encourage secure coding practices with the rise of IaC. The initial version of this IaC security scanner supports configuration files for Terraform, Ansible, AWS CloudFormation, and Kubernetes and is based on the open-source Keeping Infrastructure as Code Secure (KICS) project. This new IaC scanning capability joins our existing Kubernetes manifest SAST scanner.
If you’re familiar with GitLab SAST, GitLab’s IaC scanning works exactly the same and supports the same features including a standalone IaC scanning CI configuration file, UI based enablement tool on the Security Configuration Page and support for all our Ultimate tier Vulnerability Management features including Security Dashboards and Merge Request widget. With this new IaC scanning template, we’ve also made it easy to extend our IaC scanning with additional scanners and welcome community contributions using our secure scanner integration framework.
Fine grained permissions control with the CI/CD tunnel
Keeping your clusters’ access safe is paramount for most companies. The CI/CD Tunnel for the GitLab Kubernetes Agent enables secure access to the cluster from within GitLab CI/CD. Until now, the Tunnel inherited all the permissions of the service account of the installed agent in the cluster. Many users need stricter permission controls, preferably at the user or job level.
In GitLab 14.5, we are pleased to release a generic access impersonation and a CI/CD job impersonation. These impersonations can be specified in the Agent configuration file, and the impersonated account permissions can be managed using Kubernetes RBAC rules.
GitLab Kubernetes Agent available in GitLab Free
Connecting a Kubernetes cluster with the GitLab Kubernetes Agent simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster. Initially, the GitLab Kubernetes Agent was available only for Premium users. In our commitment to the open source ethos, we moved the core features of the GitLab Kubernetes Agent and the CI/CD Tunnel to GitLab Free. We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management. Advanced features remain available as part of the GitLab Premium offering.
Cleaner diffs for Jupyter Notebook files
Jupyter notebooks are key to data scientists’ and machine learning engineers’ workflows, but the file structure makes code review challenging. Often, the files can’t be reviewed properly, and users are forced to accept those changes or treat their repositories as stores of data versus collaborative projects.
Now GitLab automatically strips out the noise and displays a cleaner version of the diff for these files. Human-readable diffs make it easier to review the substance of the change, without worrying about the formatting pieces that Jupyter Notebooks need.
Geo provides a single command to promote a secondary node
When performing a failover, systems administrators use different tools depending on the underlying architecture. On a single-node Geo site, administrators can use the gitlab-ctl promote-to-primary-node command. However, multi-node sites did not support this command and required manual editing of configuration. This was cumbersome for large environments because it required updating dozens of configuration files.
Now, administrators can use gitlab-ctl geo promote on any node of a Geo secondary site to promote it to a primary. In a disaster recovery scenario or planned failover, this saves precious time and reduces potential errors when promoting a secondary site to a primary. This command also makes it easier to script the failover process.
As of GitLab 14.5, the commands gitlab-ctl promote-to-primary-node and gitlab-ctl promote-db are deprecated and will be removed in GitLab 15.0.
Explore project topics tab
In this release, thanks to Jonas Wälter’s contributions, we’ve added a new Explore topics tab in Projects.
- Topics are sorted by popularity (the number of projects with this topic).
- Topics can be searched by name and are then sorted by similarity and by popularity.
When you select a topic, you can view its description and avatar, and all of its corresponding projects.
Topic management in the Admin Area
In this release, thanks to Jonas Wälter’s contributions, we’ve introduced several features for administrators to manage project topics in the Admin Area:
- Add and edit project topics.
- Search topics based on any string.
- Add avatars and descriptions to topics (supports Markdown).
Group-level settings for merge request approvals
You can now define and enforce values for merge request approval settings at the group level. These values cascade and are used by any projects within the group.
Group-level merge request approvals make it easy for organizations to ensure proper separation of duties across all teams. You only have to specify settings in a single location now, rather than needing to update and monitor every project. When set at the group level, you:
- Can be confident that projects will use consistent separation of duties workflows.
- Do not need to manually check that every project has not had its settings modified.
Conditional includes with exists keyword
The include keyword is one of the most popular ones to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.
In this release, we are expanding the power of the keyword so you can use include with exists in the rules condition. Now, you can decide when external CI/CD configuration should or shouldn’t be included based on when certain files exist in the repository.
Add personal README to profile
You can now add a README section to your GitLab profile! This is a great way to tell others about, your interests, how you work, or anything else you want!
To add a README section, create a new public project with the same name as your user account and add a new README file. The contents of that file are automatically shown on your GitLab profile.
Fine-tune vulnerability check rules
When defining vulnerability check rules, users need a high degree of granularity so they can tailor the rules to only trigger MR approval when it is required per their organization’s security policies. GitLab now supports more granular vulnerability check rules. Users can now define which scanners, severity levels, and vulnerability types are considered when triggering a rule. Additionally, users can set a minimum threshold for the number of vulnerabilities that must meet the criteria before the MR requires approval. By only requiring vulnerability check approvals on MRs that truly need it, this increased granularity allows teams to free up developers and security teams. You can configure these granular vulnerability checks by navigating to the Settings > General > Merge request approvals page in your project.
Additional Secret Detection pattern support
We’ve updated the GitLab Secret Detection scanner to detect 47 new ‘well-identifiable’ secret patterns for widely used applications. This brings the GitLab Secret Detection detection up to over 90 detectable patterns.
If you are a SaaS application vendor and your app generates secret tokens with well-identifiable patterns, and you’d like GitLab to be able to detect them, please add your regex pattern and a few invalid sample tokens in a comment on this issue and we’ll get them added to GitLab Secret Detection.
Allow updates to attributes for SAML or SCIM users
In previous versions of GitLab, we supported the project_limit and can_create_groups attributes only on newly SAML provisioned users. If users were created using SCIM or is updated in the SAML provider with these attributes, the project_limit and can_create_groups values would not be updated.
Now, if a user is created using SCIM or has an update to these attributes in the SAML provider, these sync to GitLab. This allows the identity provider to act as the single source of truth for core user attributes.
Automatically unblock LDAP users when signing in with other providers (SAML, OAuth, OmniAuth)
Transient LDAP errors can cause users to be blocked and unable to log in. If the transient error is resolved, GitLab now rechecks LDAP and unblocks them if another authentication method (such as SAML or OAuth) is configured and used as the sign-in method and the user was blocked using LDAP.
Include Minimal Access role in SAML Group Sync
Administrators can now specify SAML Group Links with a minimal access role only for the top-level groups. This allows administrators to enhance security by defaulting to minimal access when the user is provisioned and assign more permissive roles at the sub-group level.
Topics selection in project settings
In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. Previously, to add a topic, you had to manually enter each topic and multiple topics had to be comma-separated. Now you can select multiple topics from a dropdown list, making topic selection efficient and more convenient.
Git fetch resource optimizations
We improved the performance of traffic between Workhorse and Gitaly, resulting in git fetch now using fewer GitLab server resources. This change can cause issues on self-managed GitLab if a gRPC proxy is deployed between Workhorse and Gitaly. If you deployed a gRPC proxy between Workhorse and Gitaly, Workhorse can no longer connect. As a workaround, disable the temporary workhorse_use_sidechannel feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy.
Merge commit message template
Merge commits can provide important context to the commit history of a project about what was merged. However, if you don’t edit the merge commit prior to merging, other users are forced to navigate to a merge request to gain additional context about why the changes were made.
Project maintainers can now configure a default merge commit message template. This allows projects to specify a standard merge commit, and use variables to provide additional details in these messages. This additional context helps the next developer when trying to understand why the change was made, by providing the potential to make all the relevant information available in the merge commit.
Thanks to Piotr for this amazing contribution!
Tables in wikis support block-level elements
GitLab 14.1 introduced WYSIWYG editing for tables in the new wiki editor, but the types of content supported in table cells were limited by the underlying Markdown implementation: you couldn’t add block-level elements like lists, code blocks, or pull quotes inside a table. Now, in GitLab 14.5, these block-level elements are fully supported inside table cells. You can insert lists, code blocks, paragraphs, headings, and even nested tables inside a table cell, giving you more flexibility and freedom to format your content to meet your needs.
Add pipeline mini graph to the pipeline editor
Tracking the status of a running pipeline can involve significant context switching because you sometimes have to stop what you are doing to go check the pipeline page. Previously, the pipeline editor only showed the overall pipeline status and provided a link to the pipeline. In this release, we are adding the pipeline mini graph to the pipeline editor to make it easier for you to see the status of individual jobs without leaving the editor.
Improved UI for runners in the Admin Area
Previously, if you were a GitLab administrator, you could not easily find runners by instance, group, or project. The search and filter limitations made it difficult and inefficient to locate a runner when troubleshooting CI/CD job execution issues.
This release includes an initial update to the Runners page (Admin Area > Runners). The new layout helps you find runners more quickly and enables GitLab to provide future improvements for runner fleet management. The key improvements in this redesign are tabs that filter the list of runners by type, and indicators that show runners that have not recently connected to GitLab.
New GitLab access token prefix and detection
With GitLab 14.5 we have updated the GitLab Personal Access Tokens and Project Access Tokens to include a standard prefix, glpat- by default for both GitLab.com and GitLab self-managed instances. We’ve also updated our Secret Detection scanning to detect this new pattern which will help protect you against accidentally leaked GitLab access tokens in commits.
This improvement helps make it easy to detect GitLab tokens leaked in commits and builds on community contribution improvements added in Gitlab 13.7 that allowed Admins to set Personal Access Token prefixes at the instance level, shoutout to @max-wittig and @dlouzan at Siemens for this contribution! Existing access tokens will not be modified but any new tokens will follow this new pattern or the custom pattern set by your self-hosted GitLab instance.
If you would like to detect GitLab Personal Access Tokens and Project Access Tokens you can use the following regex detection pattern: glpat-[0-9a-zA-Z\-]{20}.
Order deployment by deployed time
Currently, the environment page sorts the list of deployments by the Created date, which is associated with the commit SHA change. To make it easier to view deployments over time, we have changed the default sorting order of this list to be by the finished_at field rather than the date of the commit. You can now see the running and most recently completed deployments at the top of the page and the rest of your deployments in descending order by the deployed time.
Basic authentication for alert HTTP endpoints
In the past, you needed a bearer token to authenticate to an alerts HTTP endpoint. Beginning with this release, you can also authenticate with Basic HTTP authentication, either through the headers or in the URL.
Return alert ID in POST responses for alerts
Currently, when you POST an alert using the generic alert HTTP Endpoint the response is a simple 200 upon a successful POST. If you want to reconcile your current alert workflows, you may need to see additional information returned in the POST response. In this release, we added the alert ID (iid) to the response, enabling you to see your specific alerts by a unique ID.
Omnibus improvements
- With CentOS 8 EOL approaching, we have added support for AlmaLinux as a replacement in GitLab 14.5. AlmaLinux is backed by a company with a long track record of building an enterprise Linux compatible distribution and has the processes in place to sustain it. This aligns to our preference for the boring solution.
- GitLab will now publish an ARM64 version of GitLab Enteprise Edition to the AWS Community AMI catalog. AWS is seeing a rise in adoption of AWS Graviton2 (ARM64), so we want to make sure GitLab EE will be usable for those users accessing the AWS Community AMI catalog. This documentation contains relevant information for using the AWS community AMIs.
- GitLab 14.5 will provide packages for openSUSE Leap 15.3. OpenSUSE Leap 15.2 will reach its end of life on December 31st, 2021, therefore we want to provide OpenSUSE 15.3 in advance so users have a few milestones to make the move to a more recent version of OpenSUSE.
Audit events for group SAML configuration changes
GitLab now records audit events for changes to additional group SAML settings. Events are created when changes are made to:
- Enabled status
- Enforcing SSO-only authentication for web activity
- Enforcing SSO-only authentication for Git and Dependency Proxy activity
- Enforcing users to have dedicated group-managed accounts
- Prohibiting outer forks
- Identity provider SSO URL
- Certificate fingerprint
- Default membership role
- SSO-SAML group sync configuration
These events give you visibility on who configured or changed group SAML settings, and when. They can be used in an audit to show that controls were correctly set and then never changed, or they can identify any changes that were made that need to be further examined.
Contribution calendar aligned to configured timezone
Previously, your contribution calendar was aligned with the server’s timezone instead of your local timezone. Large differences between the two timezones could make it appear that you contributed a day earlier or later than you actually did.
Now, contribution calendars are aligned with your local zone, if set. Others can hover over activity to view your local date and time information, to compare their local timezone with your own.
Thanks to Dave Barr for this contribution!
Manage project topics with the API
In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. In addition to the latest project topic management features in the UI, you can now use the API to retrieve topics by list or ID. We’ve also made it possible for administrators to create or edit topics through the API. This introduces full parity between project topic management in the UI and API.
VSA deep link for URL query parameters
In previous releases we added the ability to filter Value Stream Analytics by attributes such as labels, milestones, and assignees. In this release, we’ve enhanced this by adding deep links for query parameters. This creates a hyperlink from the custom query that you can send as a URL to your peers for collaboration, or save as a bookmark for future use.
GitLab Workflow authentication with environment variables
In automated development environments, like Gitpod, configuration of GitLab Workflow for Visual Studio Code requires loading the editor and then setting the personal access token for GitLab each time. This process is time consuming, error prone, and leads to multiple or duplicate use of access tokens.
With the release of GitLab Workflow v3.36.0 the extension now supports configuration via environment variables. Using environment variables enables you to configure the authentication once. Each VS Code instance is then able to authenticate even when the previous VS Code instance has been deleted.
Sticky toolbar when editing wiki pages
When you edit long wiki pages, the editor grows vertically to fit your content. In previous versions, the editor could become so long that the formatting toolbar icons disappeared. When writing in raw Markdown, this can be frustrating but you can overcome it using keyboard shortcuts. However, the toolbar is a much more critical component of the new rich Markdown editor, so having this UI unavailable on the screen requires you to scroll vertically, away from your content, to access core features.
Now, in GitLab 14.5, the formatting toolbar remains fixed at the top of the input field, allowing you easy and persistent access to these convenient features, even when editing very long documents.
Thank you Mehul Sharma for contributing this helpful improvement!
View file tree when reviewing in Visual Studio Code
When you review a merge request in GitLab Workflow extension for VS Code, it provides a flat file list to navigate the changes. The flat file list lacks context, and can make it hard to understand where the changes are. In large codebases where files might have the same names across different directory paths, this can be even more problematic when reviewing.
With the release of v3.37.0, the GitLab Workflow extension now provides a toggle to switch between a flat list and a file tree view. This file tree view brings additional path information to help you navigate the changes, and get a complete picture of the merge request.
Thanks to Liming Jin for the amazing contribution!
GitLab Runner 14.5
We’re also releasing GitLab Runner 14.5 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build 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:
Bug Fixes:
- Kubernetes executor ignores Docker
ENTRYPOINT - Kubernetes builds on Windows nodes fail without
shell = "pwsh" - GitLab Runner doesn’t clean up git lock files for submodules
The list of all changes is in the GitLab Runner CHANGELOG.
Extract package metadata for npm packages
You can use the GitLab Package Registry to publish and share npm packages alongside your source code and pipelines. Prior to this release, however, GitLab did not extract all of the relevant metadata detailed in your package.json file. This is especially problematic when npm or Yarn relies on one of those fields. For example, the bin field defines executables to insert in $PATH. Without that field, your executables do not work.
As of this release, GitLab now extracts the abbreviated metadata for npm packages, including the bin field and others. If you publish packages that have one or more executable files to install into the $PATH, you can now rely on the GitLab Package Registry to work seamlessly. Please note that this change applies to new packages only. Any packages already published to the registry must be updated for the change to take effect. In addition, GitLab only extracts the abbreviated metadata, which excludes certain fields. GitLab-#344107 proposes extracting the full metadata set.
Static Analysis analyzer updates
GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.5. These updates bring additional coverage, bug fixes, and improvements.
- semgrep updated to version 0.72.0 - MR, Changelog
- various bug fixes for timeouts, crashes, and rule corrections. See changelog link for more details.
- flawfinder internal packages updated to version 2.14.7 - MR, Changelog
- gosec updated to version 2.9.1 - MR, Changelog
- Fix the SBOM generation step in the release action
- Phase out support for go version 1.15 because current ginko is not backward compatible
- sobelow internal packages updated - MR, Changelog
- PMD updated to version 6.40.0 - MR, Changelog
- Apex language support to v54.0
- Various improvements and bugfixes for rulesets.
- spotbugs updated to version 4.5.0 - MR, Changelog
- false negative fixes
If you include the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you need to update your CI configurations. To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.
CI/CD Tunnel support for Omnibus installations
The CI/CD Tunnel support for self-managed instances installed through GitLab Charts was introduced in 14.0 and significantly improved since then. In this release, we are adding support for Omnibus installations.
The CI/CD Tunnel provides a secure connection from within GitLab CI/CD to your Kubernetes clusters using the GitLab Kubernetes Agent. This enables users to continue using their existing tools and processes, and adopt the GitLab Kubernetes Agent for a robust and safe setup.
Restrict incident creation permissions to at least the Reporter role
You may have experienced a time where you created an incident when you actually meant to create an issue. Incidents are a specific issue-type, with a unique user interface and workflow that represent service disruptions or outages. In this release, only users with at least the Reporter role can create incidents. Restricting these permissions will help minimize the number of accidentally-created incidents.
GitLab chart improvements
In GitLab 14.5, we now support the ability to set the Ingress API version via Helm values. This ability supports our work towards Kubernetes 1.22. When Kubernetes 1.22 is fully supported, when a user installs our Chart on a 1.22 cluster, a newer supported version on Ingress is be chosen. Users can manually specify the newer supported version if not installing against a live cluster, like when running a helm template.
Bug fixes
Some of the notable bug fixes in 14.5 are:
- Broken filter dropdown in Merge Request Analytics.
- Filter bar in Merge Request Analytics is case sensitive.
- Remove Dependency Proxy navigation when user can’t access it.
- Properly reply when
go getuser needs 2FA. - Rollbacks on online garbage collection only when errors occur.
- Two-factor authentication registration broken in GitLab 14.3.1.
- Managing two-factor authentication does not work in Safari 15.0.
- Nested folder production environments cannot be attached to merge requests.
- Unable to log in with Okta when GitLab is in maintenance mode with EC2 replacement.
- Geo: secondaries may be orphaning Upload files.
- Git fetch raises the 500 error after GitLab Helm update when in maintenance mode.
- Patroni doesn’t generate
public_attributeswhenpatroni_roleis enabled. - Object deduplication on Geo secondary doesn’t happen if the first sync fails.
- Group-level wikis where repositories do not exist on the Geo primary fail to sync.
- Users cannot update a Scan Execution Policy’s name.
- Unable to install Cilium via GMAv2.
- Statistics page doesn’t load.
- Spam checking: boards don’t handle CAPTCHA display properly.
- Issue creation by email ignores content if all lines are quoted.
- Users without parent group permission can’t assign an epic to an issue.
- When editing an epic boards, wrong text is being shown in edit modal.
- Issue cannot be promoted to epic if moved to promote to different group.
- WebP images don’t embed in Markdown.
- Email on push: multiple recipients break S/MIME signature.
- Global Search: the Reset filters button disappears.
Performance improvements
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!
In GitLab 14.5, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.5 are:
- Dependency Proxy workhorse migration for image manifests.
- Add
read_atdata to the dependency proxy. - Convert Package List page to use GraphQL.
- Cache database repository objects for API requests.
- Significant no-op increments in PK sequences for
top_level_namespacesandrepositoriestables. - The setting Prevent sharing a project within a group with other groups times out for large group hierarchies.
- Allow Kubesec SAST analyzer to Analyze manifests concurrently.
- Fix N+1 query for
VulnerabilityType. - Make the environments picker dropdown not load all environments at once.
- Optimizations for reading Git objects in Gitaly:
ConnectionRedactiontimes out on boards with label lists when grouped by epic.- Negated filtering with non-existing label produces very slow query plans.
Usability improvements
In every release, we make great strides in improving the overall effectiveness and usefulness of our product.
We also have a UI Polish gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.
In GitLab 14.5, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.5:
- Creating an application leaves user in an inescapable screen.
- Improve the appearance of the Confluence integration.
- Jump to next unresolved thread button should track position as user scrolls through the page.
- File mode changes are not always visible in the merge request diff view.
- Use viewed state from file header in merge request file browser.
- Dependency Proxy displays cached container images.
- Show project number, average test coverage, and job number on Group Code Coverage tooltip.
- Improve empty state of dropdown when artifacts fail to load.
- Show jobs in chronological order on CI/CD job page.
- Make trigger variables column from pipeline trigger scrollable.
- Improve merge blocked text for skipped pipelines.
- Better handling when users do not have permissions to create a policy.
- Update the Apply button for Global Search facets to be disabled by default.
Deprecations
New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.
Important notes on upgrading to GitLab 14.5
-
The Task Runner pod is used to execute periodic housekeeping tasks within the GitLab application, and is often confused with the GitLab Runner. To remove confusion, the Task Runner is renamed to Toolbox in GitLab 14.5. This results in the rename of the sub-chart
gitlab/task-runnertogitlab/toolbox. The resulting pods are named according to the pattern-toolbox, which often results in pods namedgitlab-toolbox. You can locate them with the labelapp=toolbox. - Sidekiq deployments were changed from having a
-v1suffix to-v2. Due to the deployment name changing, Sidekiq shutdown of the old pods and start of the new is handled by separate deployments, and as a result there could be a period of time during the upgrade where there are no Sidekiq pods running. Sidekiq works on asynchronous jobs, so impact might be a delay in background job processing like running new CI jobs and updating merge requests diffs. We are implementingpodAntiAffinityin such way that allows to spread out Sidekiq pods across the cluster. - An extra step for finalizing background migration jobs over the
merge_request_diff_commitstable may result in extra time required during an upgrade to 14.5. Large instances with a large number of merge request diff commits, may be interested to perform an optional manual operation to save additional space. For more information, please check the version-specific upgrading instructions for 14.5.
from GitLab https://ift.tt/3BhBMak #GitLab #DevSecOps
Comments
Post a Comment