Endpoint auth. parameter that is not confidential getting masked in agent logs #1207
Comments
|
Are you sure this is an agent issue (and not lib/service)? |
|
@bryanmacfarlane - I was referring to this piece of code in agent that needs a fix: |
|
Fix for this issue is blocked due to a service-side bug in Build. Waiting for the service-side bug to be fixed before we can take up this fix. @ericsciple - pl. assign this back to us once the service-side bug is fixed. |
GitHubSriramB
assigned bryanmacfarlane and unassigned omeshp, GitHubSriramB and ericsciple
|
This feedback ticket has been raised recently by a user. Character 1 gets masked in the user's logs because of masking all endpoint authorization parameters. |
|
Is there any update to this issue? I am also having the problem where all '1' characters are being masked. |
|
@ericsciple should be able to provide update on build side issue. |
|
@peterox I believe this was fixed. Are you using the service "Azure Devops" and the latest agent? Or are you using on-premises TFS? Note you can right click on the pool to update all agents in a pool to the latest version. |
|
@ericsciple I've just updated all the agents and I'm still getting all '1''s masked in the logs. I disabled a Docker task that had an Azure subscription configured and ran the build and the issue was not there. Re-enabling the task and running the job again caused the issue to re-appear. |
|
@TingluoHuang do you remember context on this? it looks like this code is still in master. I thought this was removed months ago? |
|
Is there a work around available to prevent masking? |
|
Bump |
|
Just confirming that the latest Github released version (2.144.2) does not fix this issue after redeployment of my agents. The HTTP link in the Web UI is also pointing to version 2.144.0 (instead of 2.144.2). Current version of @ericsciple Would you be able to (un)confirm if the bug is still on master or a fixed on another branch? |
|
We are using hosted Azure DevOps in the cloud with on-prem agents running version |
|
Are we able to get an update on this? It seems there is a fix but it just hasn't been released? This problem effectively makes the logs in our pipelines useless. |
|
As spotted by @peterox, removing our Azure DevOps Docker tasks from pipelines seems to solve the problem. Specific tasks types that require access to secrets may interfere and cause this issue. |
It also happens for custom extensions. |
|
@StingyJack we issue we observed happens with tasks which use specific service connection - Azure Key Vault uses Azure service connection which already has internal fields with values like '1' (if the task is disabled in pipeline - connection won't be used, hence this value won't be masked). We have confirmation that this issue was fixed by PR (we excluded some known non-secret parameters available) - this fix has been rolled out with v2.198.0 agent release. |
|
@anatolybolshakov - We only have a few builds that require us to host an agent. The rest are all AzDo hosted agents which are running the pipelines that have the inappropriate masking, so I'm only looking into these hosted agents. From a recent log... I ran a pipeline with debug = true and System Diagnostics enabled and attached the logs to the support case we have open. I believe the support engineer has forwarded them to you at this point.
The logs attached appear to have values like "1", "2", "Dev", etc. being masked. Its masking them in places like the task version header, or in the timestamps, etc. See one of the examples I have already shared for a better idea. |
|
Hey everyone! example: variables:
AGENT_MIN_SECRET_LENGTH: 1also it's available as environment variable. This feature will be available in the next agent release, we will notify you once it will be rolled out. UPD: The new knob name is |
|
@KonstantinTyukalov is it going to stop the changing of dates and times on the logs or the header information for tasks? The request was for you to not mask trivial (single character) or values that are well known to not be secret, like "Dev" or "32" or "Q". A length setting is not useful if the agent is still possibly going to mask easily discernable values like those. Is this an opt-in setting? I think you guys missed the point still. It's not about not masking small values, the problem is you're masking values that are not secrets that help me reliably guess the secrets. Also the name of the variable |
|
@StingyJack I have tested that timestamps remain and are not affected by secret masking:
Also, please notice that the name of the variable is |
@DenisRumyantsev - Yes and I notice the log is now totally useless as well.
That makes more sense but its not what @KonstantinTyukalov said it was called.
That name still doesnt refer to the masking which its affecting. Which is not as important as that you are still missing the point. We dont want you to avoid masking secrets. This solution makes the problem worse as it allows me to expose secrets directly instead of just inferring them indirectly. The current design may be simple but it is far too aggressive, We want you to avoid masking data that is not a secret. Consider the following... |
|
@DenisRumyantsev @KonstantinTyukalov @anatolybolshakov @alexander-smolyakov - I pointed out that your proposed solution creates an even larger problem than was being reported, and you have nothing to say in the last month? I really hope that you are not still considering this AGENT_SECRET_MIN_LENGTH as viable, because nobody asked for you for a knob that let us expose any secrets. We asked you to stop making the secret values easy to guess. |
The knob is not working for the bug where that '1' is masked, we also checked our secrets and there is none of them having a 1. Also interesting fact is that it appears to happen only on the first stage, if the pipeline does have more stages the 1's are not masked except the first stage. The pipelines use the same agent for these stages, and the agent version is 2.217.2, which is the newest as by the time writing this. So result is neither is the bug with suddenly masking 1 solved nor is there any workaround or solution to not have guessable logs where secrets are masked out of text which shouldn't be masked. |
This also happens with the new Azure Agent with Version 3.217.1 as we just tried the pre-release version. |
|
@at-besa Do you have this or other extension in your pipeline? #1207 (comment) Also, have you tried
What tasks do you have in this first stage? |
@KonstantinTyukalov - this knob does not fix the problem that was reported. It actually makes the situation worse, thus invalidating it's intended purpose. Several users have told you this now. Please revert the knob and come up with a proper fix. |
Yes i have tried the knob, the 1's are not masked anymore when i turn the knob value of AZP_IGNORE_SECRETS_SHORTER_THAN to 1, although this does not make any sense, as mentioned there is no secret which does even have this value. I agree with @StingyJack that this is just an workaround and not the solution to the actual problem. regarding the tasks used in the first stage: The whole pipeline is running on an azure hosted vm with rocky as operating system. as there is no secret stuff in this section i can share the yaml of this whole stage: |
|
any news on that ? |
|
This issue has had no activity in 180 days. Please comment if it is not actually stale |
|
180 days and still no comment of devs |
|
This issue has had no activity in 180 days. Please comment if it is not actually stale |
|
Turn off this bot. It just makes the maintainers come across as "rude" instead of just "busy" |
and others
2.122.0
Windows
VSTS
Attaching details about the custom endpoint type & logs that has this issue.
Endpoint details logged in agent:
{ "data": {}, "id": "cfa7e53f-5778-423c-af65-507a80224c79", "name": "cfa7e53f-5778-423c-af65-507a80224c79", "type": "habitatoriginendpoint", "url": "https://bldr.habitat.sh", "authorization": { "parameters": { "username": "********", "revision": "********", "publickey": "********", "password": "********", "githubauthtoken": "********", "useSudo": "********" }, "scheme": "UsernamePassword" }, "isReady": false }Endpoint contribution type:
{ "id": "habitat-origin", "description": "Habitat Origin", "type": "ms.vss-endpoint.service-endpoint-type", "targets": ["ms.vss-endpoint.endpoint-types"], "properties": { "name": "habitatoriginendpoint", "displayName": "Habitat Origin", "url": { "displayName": "Habitat Depot URL", "helpText": "URL to the Habitat depot that will be used to deploy to" }, "inputDescriptors": [], "authenticationSchemes": [ { "type": "ms.vss-endpoint.endpoint-auth-scheme-basic", "inputDescriptors": [ { "id": "username", "name": "Origin Name", "description": "Name of the Habitat origin", "inputMode": "textbox", "isConfidential": false, "validation": { "isRequired": true, "dataType": "string" } }, { "id": "revision", "name": "Revision", "description": "Revision of the origin to use", "inputMode": "textbox", "isConfidential": false, "validation": { "isRequired": true, "dataType": "string" } }, { "id": "publickey", "name": "Public Key", "description": "Public item of the origin key pair", "inputMode": "textarea", "isConfidential": false, "validation": { "isRequired": true, "dataType": "string" } }, { "id": "password", "name": "Signing Key", "description": "Signing item of the origin key pair", "inputMode": "textarea", "isConfidential": true, "validation": { "isRequired": true, "dataType": "string" } }, { "id": "githubauthtoken", "name": "GitHub Auth Token", "description": "Authentication token for GitHub for publishing Habitat packages.", "inputMode": "textbox", "isConfidential": "true", "validation": { "isRequired": true, "dataType": "string" } }, { "id": "useSudo", "name": "Use Sudo", "description": "Use sudo on habitat commands", "inputMode": "combo", "isConfidential": false, "validation": { "isRequired": false, "dataType": "string" }, "values": { "inputId": "useSudoValues", "defaultValue": "1", "possibleValues": [ { "value": "1", "displayValue": "True" }, { "value": "0", "displayValue": "False" } ] } } ] } ], "helpMarkDown": "Please provide the requested information so that Habitat packages can be built and deployed. The GitHub authentication token requires `user:email` and `read:org` scopes" } }The text was updated successfully, but these errors were encountered: