Eliminate nix store paths from the configuration

[ymatsiuk]

Is your feature request related to a problem? Please describe.

Nix is famous for having a hash prefix for all the paths, that is generated based on the inputs during the build. Which means that every time we rebuild the tool with new input (version bump of a dependency or the tool itself) we get a new hash.

This breaks aws-sso since the previously recorded absolute bin path in the ~/.aws/config might refer to the older version or not valid anymore (after the GC run for example, that cleans the store and removes software that's not linked to user or system bin paths).

Another problem that is linked to this: heavy use of wrappers in nix for dependency management. So instead of relying on users to install dependencies it's very simple to add a dependency as part of the wrapper script that looks similar to this:

#! /nix/store/lj2bdg618093ny9505d0nzzjdq0fwp8a-bash-5.1-p16/bin/bash -e
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/bmczxdg90m56x5nj2nn94495b8iv70yl-xdg-utils-unstable-2020-10-21/bin'':'/':'}
PATH='/nix/store/bmczxdg90m56x5nj2nn94495b8iv70yl-xdg-utils-unstable-2020-10-21/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
exec -a "$0" "/nix/store/9x7cjw31mrqaz03zkc275l3ndilzbdmy-aws-sso-cli-1.9.2/bin/.aws-sso-wrapped"  "$@"

this way we kinda make sure that when you install the tool you get everything set for you (the wrapper script sets proper PATH so you get xdg-open whenever you need it even if it's not installed as part of your system). With a slight downside (I think that's clear from the script, that you no longer use the binary, but the script instead, otherwise it will never be able to open a browser to login and the binary's renamed to .aws-sso-wrapped)

With all that said the issue is pretty much that credential_process does not properly work anymore and require aws-sso config-profiles on every upgrade (as I mentioned above the upgrade might be triggered not only by the version bump of the tool, but every one of the dependencies as well since it generates a new hash - store path). Example:

 [profile XXXXXXXXXX:org-root-xxxxx]
-credential_process = /nix/store/9x7cjw31mrqaz03zkc275l3ndilzbdmy-aws-sso-cli-1.9.2/bin/.aws-sso-wrapped -u open -S "XXX" process --arn arn:aws:iam::XXXXXXXXXX:role/org-root-xxxxx
+credential_process = /nix/store/3d1cwj13m3e9kjdo3275l3ndildlkfndf-aws-sso-cli-1.9.2/bin/.aws-sso-wrapped -u open -S "XXX" process --arn arn:aws:iam::XXXXXXXXXX:role/org-root-xxxxx

Describe the solution you'd like

Ideally I'd like to have simple aws-sso in my ~/.aws/config and let my system resolve the path to the binary. This is the simplest solution I could've thought of, so if you have a better idea let's do it!

Some more details on how nix works (in case you're interested 😉):

• How Nix works

PS: thanks for your effort and for aws-sso-cli 🚀

[ymatsiuk]

alternative option might be --disable-absolute-path argument that changes behavior of the template

[synfinatic]

Thanks for the feedback @ymatsiuk . I definitely see how this could be annoying. I'm not familiar with Nix so will have to dig into this a bit more before I decide how to manage this in the most graceful way.

[ymatsiuk]

Another way (might be more efficient one) that came to my mind recently is to extend getExecutable function to handle nix store paths, so we can leave the rest of the code untouched 🙂

[synfinatic]

There are a few things I'm trying to balance:

1. Try to avoid adding more flags/config options to aws-sso as much as possible. It's a bit over-complicated as it is.
2. For security purposes, we should use the static path to the binary whenever possible. This reduces the risk of a malicious binary to be placed earlier in your $PATH and intercepting keystrokes which can be used to unlock the secure store and compromise all the secrets.
3. Follow the 80/20 rule.

One idea which comes to mind that I think meets all these is to auto-detect the path of the current binary and record that in the cache. If the path changes, that triggers re-writing the ~/.aws/config with the new path. This auto-updating of the ~/.aws/config already happens if the list of available roles available changes for the user.

I believe this should be fast (don't have to read the entire contents of ~/.aws/config on every invocation) and work for users of Nix as well as more traditional installations. What do you think?

[synfinatic]

@ymatsiuk : LMK if this PR works for you. If you'd like a binary to test, let me know your OS/platform.

[ymatsiuk]

@synfinatic thanks a lot, this is exactly what I was asking for!

[ymatsiuk]

Is that ok that the issue is closed before the change is merged?

[synfinatic]

@ymatsiuk Yeah, I was a little quick on the trigger, but it's merged and released. Enjoy. :)