match? method of the ::Gitlab::UntrustedRegexp class preventing the validation of empty strings as the default value

Summary

There is a potential bug in the match? method of the ::Gitlab::UntrustedRegexp class that is preventing the validation of empty strings as the default value for a component's input, even when the regular expression allows for empty strings. This issue can cause false negatives across GitLab, as many components use this function.

Steps to reproduce

  1. Create a component in GitLab that takes an optional string input.
  2. Use a regex for validation that allows for empty strings (e.g., ^(\/[\w-]+){0,2}$).
  3. Set the component input to an empty string (default value).
# component.yml
spec:
  inputs:
    registry_subpath:
      default: ""
      regex: ^(\/[\w-]+){0,2}$
---
job:
  script:
    - echo push container to $CI_REGISTRY_IMAGE$[[ inputs.registry_subpath ]]
# gitlab-ci.yml
include:
  - local: component.yml

Example Project

hicksca/testing-gl-bug

What is the current bug behavior?

This bug prevents valid regex checks for optional inputs in GitLab pipelines. For instance, a default empty string value fails validation even when the regex allows for empty strings. Resulting in in an error:

"component.yml: registry_subpath input: default value does not match required RegEx pattern"

What is the expected correct behavior?

The match? method should return true for empty strings if the regex pattern allows for empty values.

Relevant logs and/or screenshots

image

Output of checks

This bug happens on GitLab.com

Possible fixes

The bug is caused by checking text.present? before even calling the regex and by calling .present? on the output of the regex scan. Both of these checks cause all nil or falsey values (including empty and whitespace strings) to result in an immediate match failure. The check should either be removed entirely or replaced with a check that only prevents nil, assuming that was the intended purpose.

Related Code:

References: