heaths / azcrypto Goto Github PK

Consider adding a method to azcrypto.Client to fetch the public key deterministically e.g., Client.Initialize or something. What is idiomatic here?

Within the packages that need them, consider moving test functionality to _test.go files so they are only available to tests.

When -live is specified, any assertions that the local client is nil fail because passthrough mode doesn't invoke the hooks to override the response. At the very least, the assertion needs to be conditioned, but having to use the testTransport adapter provides an opportunity to use it as a proxy and move the response-changing code there...probably.

The env, live, and remote flags are showing up in any consumer using the flag package. Perhaps these can be moved to *_test.go files and accomplish the same? But they'd likely have to be duplicated in all packages then.

FWIW, these are only in every package because otherwise an error occurs when you pass them to go test and they aren't declared. I only need them for client testing, though.

          > That said, if you remove outputs I could probably use that i.e., os.Getenv("AZURE_KEYVAULT_URL") would return "" so I could assume the system isn't currently provisioned.

Yeah - this is what I had in mind. If there was not already a value in the .env that you could have used for this purpose, I would have said you could add an output like "output WAS_PROVISIONED boolean = true` and then do an os.Getenv on that.

Originally posted by @ellismg in #16 (comment)

See if caching and interaction with golangci-lint has improved. If so, this should probably help improve build performance on windows-latestl

• Add EncryptAES, DecryptAES, etc. methods using a separate AESEncryptionAlgorithm so we can have different parameters in lieu of the EncryptParameters type and overloads in some other languages.
• Add optional Managed HSM resource and keys to resources.bicep.

Writing mocks for remote calls is time-intensive, so consider using https://github.com/dnaeon/go-vcr instead. We'd still need the net/http adapter since azcore creates its own http.Transport instead of using the http.DefaultTransport.

• Use idiomatic approach to live testing using test categories.
• Figure out how to set env vars from azd output; could potentially use godotenv to scan for an read in generated .env files. @ellismg is that was is intended, or some other way of setting env vars e.g., hypothetical eval(azd env show) or whatever is appropriate for your current shell where the CLI, like some others, automatically detects the parent shell or it can be specified to override / if not detected?

To make it easy to develop in a devcontainer, install azd in the image.