Currently the only way to provide a token is via the CLI arg --token. This is not ideal because the token will be saved to the shell history, which makes it easier to steal and easier to leak.
Instead this PR provides an implementation where the user can run the command exercism configure without providing a token and then the user will be asked to provide the token via a stdin input.
I would also like to add that if users are expected to know and use these ad hoc methods of securely providing the token, then these methods should be mentioned in the documentation. Otherwise, Exercism would be knowingly instructing users to use an insecure method, which could later expose them (the users) to problems down the road.
I wouldnât call that insecure. Users typically assume data in their home directory is secure. If that assumption doesnât hold, youâre in trouble either way. The exercism tool writes the token in plaintext to a JSON file. If you âsecurelyâ provide the token and avoid writing it to the shell history file, it is still in the Exercism config file. Not to mention all the browser cookies which can be used to access any websites youâre logged into.
You make some good points. My main concern is the possibility of the token being exposed when a user is navigating their shell history (by repeatedly pressing up, for example). The reason I considered implementing this safeguard is that it happened to me while recording a video demonstrating some OCaml problems. Fortunately, since it was a recording, I was able to edit it out, but this could have been a bigger problem if it had been a live stream.
A clarification, the PR doesnât remove the functionality of providing the token via the --token flag. The PR only adds an additional way to provide the token if the user runs the configure command without a token flag.
Iâm tentatively . But I donât like that we lose the information that tells the student where to get the token from up front. So Iâd like to add that back in.
Thatâs a good point. My plan was to ensure that the token doesnât get stored in the shell history since itâs sensitive information. The other configuration options donât appear to be sensitive.
Alternatively, add a new --interactive-token flag? Or a generic --interactive that prompts you for all values (and sets whatever the user enters that is not empty)?
I donât know if this is the right way to go. Using the same flag --token as a value provider and as a conditional value to enable interactivity could complicate the argument parsing logic and it is also a more complicated interface for students.
I think the current implementation of having the bare command (configure with no flags) be a signal to start the interactive input scheme makes more sense.
Ok seems like we all agree on using the --interactive flag. I have pushed a new commit to the PR that implements prompting students for their token only when the --interactive flag is set.
I think the above discussion suggested that --interactive should allow all values to be set? (obviously we should keep existing settings if the user just presses enter)
What are the other values a student might want to change, maybe the config directory?
I donât know what this is in reference to. Is it about the latest commit.
Also, itâs kind of hard to tell what i should change about the current implementation from reading the comments in this discussion, would you mind leaving reviews on the PR so that i know what i should change
@frectonz To me these comments read as: Ongoing discussion. No need to immediately change your code.
I prefer explicitly invoking interactive modes. And printing the help text when no arguments are given. So --interactive would be my choice.
For interactive modes I find preseting the current value of a setting (âif you enter nothing, this value will be takenâ) is most useful. This allows skipping values I donât want to change and interactively enter new values.
. But I donât like that we lose the information that tells the student where to get the token from up front. So Iâd like to add that back in.