azuredevops_serviceendpoint_npm not triggering a change in plan when a new access_token is provided (if the first 71 characters are the same)

[liyaoz]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and Azure DevOps Provider) Version

Latest as of 18/01/2023: Terraform v1.3.7, AzDO provider v0.3

Affected Resource(s)

• azuredevops_serviceendpoint_npm
• potentially other azuredevops_serviceendpoint as well.

Terraform Configuration Files

resource "azuredevops_serviceendpoint_npm" "artifactory_npm" { 
  project_id            = "xxxxxx"
  service_endpoint_name = "Artifactory-NPM"
  description           = "NPM service endpoint to artifactory"
  url                   = "https://does.not.matter/"
  access_token          = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXXXXXXX" 
  # -> replace 'X' with anything, remove or add more does not trigger a change in plan
}

Debug Output

Expected Behavior

Terraform plan changes the service connection when a new 'access_token' is supplied

Actual Behavior

> terraform plan
azuredevops_serviceendpoint_npm.artifactory_npm: Refreshing state...

No changes. Your infrastructure matches the configuration.

The Jfrog Artifactory produces an 809 characters access token, and the first 71 characters, unfortunately, does not change for a same user. This causes the service connection to stop working.

Steps to Reproduce

1. terraform apply

Important Factoids

References

• #0000

[davidcorrigan714]

Just hit this too interestingly enough. Trying to figure out where that 71 character limit is coming from. I'm working on adding the JFrog v2 connections and really thought I had messed something up when testing our rotation logic.

[davidcorrigan714]

Here's the culprit: golang/go#36546

[davidcorrigan714]

I'm switching to Argon2 on our fork. We'll be using Artifatory JWTs with a bunch of service connection types so really they all need to switch. Only downside should be that anyone updating the provider will see all their secrets detect a change and update on the first run. Looks like bcrypt has some constant prefixes to its hashes so I suppose with a bit more work the transition could be improved. I'm planning to submit a PR for the Artifactory v2 connections next week, not sure if the hashing stuff should be in that or Microsoft wants to take on updating that.

[xuzhang3]

This is a bug cause by the hash function used to encrypt the access_token

[davidcorrigan714]

The length limitation is going to affect a number of other service connections for us. Namely all generic, Artifactory and Docker Registry connections since we use them with Artifactory that has long JWTs as passwords.