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

Showterm must ask for confirmation before uploading #12

Closed
samuell opened this issue Aug 10, 2013 · 11 comments
Closed

Showterm must ask for confirmation before uploading #12

samuell opened this issue Aug 10, 2013 · 11 comments

Comments

@samuell
Copy link

samuell commented Aug 10, 2013

It is critical and unacceptable that showterm does not ask for permission before uploading the session!

it so easily happens that you will reveal some "secrets" on your shell by mistake, and then when Ctrl + D:ing out of showterm, it will immediately upload the session ...

(Otherwise a really awesome thing, thanks for sharing!)

@telemachus
Copy link

I don't know that I would go so far as "unacceptable", but I agree that this would be a very useful feature.

However, I can also imagine that some users would feel the other way and resent being asked to confirm what they know they will want to confirm.

So a compromise might be that showterm defaults to asking for confirmation, but also offers a command-line switch (say -a|--auto) that changes the default to upload automatically.

@samuell
Copy link
Author

samuell commented Aug 10, 2013

@telemachus Absolutely, +1 for such a switch! Then people could just

alias showterm='showterm --auto'

@telemachus
Copy link

@samuell Just in case you haven't noticed, there is already an indirect way to control uploading. I mention this only because I just noticed it myself while browsing the source code.

  1. Start showterm as showterm -e. This will drop you into your editor to edit the showterm timings before uploading. (The intended use is to trim long dead times in the terminal. For example when you looked something up.)
  2. Cause your editor to exit with a non-zero status. For example, exit {g,mac}vim with :cq. The upload will abort, though a copy of the recording is kept in a /tmp folder.

@samuell
Copy link
Author

samuell commented Aug 10, 2013

@telemachus Ok, great! ... that solves my immediate problem at least! :)

... but still I feel I would need tell this instruction every time I recommend it to someone else, so I really liked your suggestion for the flag to enable sharing, and no sharing by default.

@telemachus
Copy link

Agreed. I don't think it should be too hard to add the flag, but I want to see what @ConradIrwin thinks before going any further.

@ConradIrwin
Copy link
Owner

Hi guys. I appreciate the secrecy concern, however I'm convinced that the default behavior should be to upload with no confirmation.

I would love for the showterm client to be able to delete showterms, which would require setting up a shared secret on first use, and should mostly solve the concern.

I'd also be happy adding a flag that enables confirmation mode for people dealing with secrets so secure that a few seconds in heroku Postgres is still unacceptable (or who don't trust me to implement deletion properly :p)

@telemachus
Copy link

@ConradIrwin Sounds good to me. Then people who wanted to default to confirming can simply alias sts='showterm -c' (or whatever flag makes sense). (sts for showterm safe, of course. :) )

You've kept showterm very simple. So I'm guessing that you would prefer to just add another branch somewhere if -c or --confirm (say) was passed as the first argument? If so, I'm happy to try to get a version of this done this weekend. (That is not add any library for argument handling.)

@ConradIrwin
Copy link
Owner

That sounds awesome! I'd rather keep it dependency free to ease OSX install for non-rubyists, but it's not a hard requirement.

@pdkl95
Copy link

pdkl95 commented Aug 10, 2013

lol... this thread didn't exist when I started my implemented #15 of this feature (and a --save option and some cleanup).

It seem I took the same approach, more or less - no change in default behavior, ask only on "-a/--ask" , and no new dependencies for compatability. I switched to OptionParser for clarity given the rising number of options; hopefully that's not a compatability issue.

@telemachus
Copy link

@pdkl95 Cool. I'll stop working then and see how your pull request plays out. Thanks!

@ConradIrwin
Copy link
Owner

I've implemented deletion instead; so if you make a mistake you can always undo. I don't think we need both

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

No branches or pull requests

4 participants