Sitelet https://web.archive.org/web/20220107091156im_/https://github.com/antoniomika/sish/issues/168
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable authentication by default/automatically #168

Closed
bibo38 opened this issue May 14, 2021 · 1 comment · Fixed by #204
Closed

Enable authentication by default/automatically #168

bibo38 opened this issue May 14, 2021 · 1 comment · Fixed by #204

Comments

@bibo38
Copy link
Contributor

@bibo38 bibo38 commented May 14, 2021

While looking at the readme again, i've realized that my current setup just doesn't need any kind of authentication. Looking again at the readme I think, that the provided docker command also has authentication disabled (it uses --authentication-keys-directory but not --authentication=true - i've copied the relevant args from the docker command and felt safe due to the --authentication-keys-directory).

Ways to fix it:

  1. Leave authentication disabled by default but enable it when --authentication-keys-directory or --authentication-password is used
  • doesn't break anything
  • may create problems, when users rely on default pubkey directory
  1. Remove the --authentication flag and don't use default values for pubkey directory or password. If the user want's authentication he has to explicitly specify the directory or the password.
  • only breaks slightly (as the --authentication flag is now unknown and will throw an error)
  • One flag less to worry about
  • Users using the default pubkey directory are still insecure after upgrading (if they assumed that authentication was enabled by default or when they place keys in the directory)
  1. Enable authentication by default and (maybe) replace the --authentication flag by --disable-authentication to be more explicit.
  • breaks all unauthenticated setups (and all others when also changing the flag)
  • User has to explicitly make it insecure/public

Option 3 is the safest option, but I wouldn't mind using option 2 to keep some backwards compability

@antoniomika
Copy link
Owner

@antoniomika antoniomika commented Jun 26, 2021

I agree option 3 is likely best but I don't want to make an issue for users that are already using a 1.x release. We could propose a breaking change as part of 2.x, but I don't have many other features planned that would warrant a 2.x release. I think option 2 should work, but I'll give this a bit more thought before making a decision on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants