Scope wildcards in user environment variables not working

[szab100]

Bug description

It seems that using wildcards (*) in the scopes of user env variables are not working, env vars are only visible in workspaces if the scope is either / or fully qualified (entirely matching the workspace context's owner/repository).

Steps to reproduce

(Self-Hosted: 2022.08.0)

1. Create an environment variable using * in the repository name, eg "myproject*", which should match "myproject-X", "myprojectXY", etc.
2. Verify that the newly added env var is NOT accessible from workspaces where the context repo url does match the given pattern.
3. Verify that the newly added env var is accessible, if you change the scope to the fully qualified owner/repository scope, without wildcards in the repository name (wildcards in the git-org / owner part seems to be working fine).

Workspace affected

No response

Expected behavior

1. The wildcard matching in repository names should be fixed.

Example repository

No response

Anything else?

1. The current scope pattern does not seem to take the git provider into account, so the scope of git-org-name/repo-name is matching both the repository github.mycompany.com/git-org-name/repo-name and github.com/git-org-name/repo-name. This is a potentially exploitable security vulnerability, so supporting an optional (backward compatible) additional provider prefix would be preferred, eg all of the following should be valid scopes:

   github.mycompany.com/git-org-name/repo-name ==> should match only github.mycompany.com provider
   git-org-name/repo-name ==> should match any provider
   github.com/git-org-name/repo-name ==> should match only github.com provider

2. Env variables do not seem to readable by IDE processes. There are several IDE extensions that support taking secrets & other values from OS environment variables, so Gitpod should set the project- and user-specific env variables before spawning the IDE processes.

[axonasif]

Related #12877

[axonasif]

Env variables do not seem to readable by IDE processes. There are several IDE extensions that support taking secrets & other values from OS environment variables, so Gitpod should set the project- and user-specific env variables before spawning the IDE processes.

Hi @szab100, do you mean the variables from https://gitpod.io/variables? if so, how and where are you trying to use them or pass them to an extension if you are? Also, could you share the extension that you tested with? AFAIK, it should work.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[szab100]

Env variables do not seem to readable by IDE processes. There are several IDE extensions that support taking secrets & other values from OS environment variables, so Gitpod should set the project- and user-specific env variables before spawning the IDE processes.

Hi @szab100, do you mean the variables from https://gitpod.io/variables? if so, how and where are you trying to use them or pass them to an extension if you are? Also, could you share the extension that you tested with? AFAIK, it should work.

Hey @axonasif, this was reported quite a while ago, but I just tried to recollect my thoughts. And yes, this is about the user-configured env variables. The original issue was that if the scope was set to git-org/* and opened a git-org/projectA git repo, I could not actually see the env var set in the workspace, only when the scope was either */* (global) OR when a fully matching git-org/projectA scope was set, at least on self-hosted. This may be fixed since then.

And yes, the additional note on the IDE extensions was that even when I set env vars to either global or fully matching repo scope, the env vars were visible in SSH and terminals started from the IDEs, but a VSCode extension that was expecting those env vars could not see the env vars I configured (don't remember which extension). I thought this was because the IDE process may not have been spawned from a context where the user env vars were already set.