V2: Failed to initialize Credential manager

[zFernand0]

User may be forced to use plain text credentials.

---

Whenever there is a populated secure: [ ... ] array in a zowe.config.json file, the CICS extension fails to load V2 profiles.

Example `zowe.config.json` with secure properties

// zowe.config.json
{
    "$schema": "./zowe.schema.json",
    "profiles": {
        "zosmf": {
            "type": "zosmf",
            "properties": {
                "port": 443
            }
        },
        "cics": {
            "type": "cics",
            "properties": {
                "port": 5555,
                "protocol": "https",
                "regionName": "REGION"
            }
        },
        "base": {
            "type": "base",
            "properties": {
                "host": "my.host.net",
                "rejectUnauthorized": false,
                "port": 1234
            },
            "secure": [
                "user",
                "password"
            ]
        },
    },
    "defaults": {
        "zosmf": "zosmf",
        "cics": "cics",
        "base": "base"
    },
    "autoStore": true
}

//~/.zowe/settings/imperative.json
{
  "overrides": {
    "CredentialManager": "@zowe/cli"
  }
}

Equivalent `zowe.config.json` without secure properties

// zowe.config.json
{
    "$schema": "./zowe.schema.json",
    "profiles": {
        "zosmf": {
            "type": "zosmf",
            "properties": {
                "port": 443
            }
        },
        "cics": {
            "type": "cics",
            "properties": {
                "port": 5555,
                "protocol": "https",
                "regionName": "REGION"
            }
        },
        "base": {
            "type": "base",
            "properties": {
                "host": "my.host.net",
                "rejectUnauthorized": false,
                "port": 1234,
                "user": "my-user",
                "password": "my-password"
            }
        },
    },
    "defaults": {
        "zosmf": "zosmf",
        "cics": "cics",
        "base": "base"
    },
    "autoStore": true
}

//~/.zowe/settings/imperative.json
{
  "overrides": {
    "CredentialManager": false
  }
}

---

The following PR hides the error on refresh:

• fix(import, logging): Add logger util; remove keytar initialization #326

However, the problem still persist since no V2 profiles get loaded, and you can get the error to show again after doing a + (Create a CICS profile) operation

[JillieBeanSim]

@zFernand0 is there any more info that can be included? version of ZE, version of CICS ext. Is this with all v2 releases or just recently an issue possibly from a change in ZE or the Zowe CLI dependency?

[awharn]

I took a look at this, and it appears to be an error in trying to access the OS keyring - I was only able to replicate this in a 'headless' Linux environment with a locked keyring.

To get around the actual issue, the user will need to unlock their keyring - either via a script, starting a UI, or enabling PAM login via SSH. There is also the issue with messaging - this may need to be implemented as a change in Imperative, and suggest the user check that they are on a supported system and their OS keyring is unlocked.

[JillieBeanSim]

@awharn maybe we should include a section in our docs for prereq like the CLI team does with the Secure Credential Store section.

[awharn]

This is a bit weird. It appears that, when a user is using Remote SSH, Zowe Explorer is storing credentials on the VSCode Client machine's keyring, but the Zowe Explorer CICS Extension is storing credentials in the VSCode Server machine's keyring. I am going to look into this a bit more - I do not believe this is the behavior that we expect to encounter.

[jt-nti]

@awharn @JTonda has this issue been fixed? I was seeing it in a vscode devcontainer with the keyring unlocked and working for other extensions.

[awharn]

@jt-nti It does not appear to be fixed quite yet, though we do have a fix available in the Zowe Explorer API that should resolve this issue. However, we became aware that VSCode is planning to remove support for keytar, the mechanism we use for storing the user's credentials. We are currently discussing how to approach this issue, because we can fix it now, but it will very likely break again in under a month when we are forced to migrate to a different credential storage mechanism.

[jt-nti]

That makes sense, thanks for the update @awharn