cli: add config option to disable automatic uploading of asciicasts

[cbarcenas]

Currently, it's too easy for users to accidentally publish sensitive screencasts to asciinema.org: all you need to do is accidentally omit a filename argument and then press at the upload confirmation prompt.

At many security-minded organizations, particularly those that regularly deal with sensitive information, the automatic upload feature of asciinema rec would turn asciinema into a data leakage risk. This may in turn prevent its use at such organizations.

I propose that a configuration option, upload, be added to the [record] section of the config file. This option, which would default to yes, could be used to control the automatic upload functionality of asciinema rec. If set to no, automatic upload functionality would be disabled and the filename argument to asciinema rec would become mandatory.

I have implemented this proposal and will submit a PR for review.

[ku1ik]

As this is linked to asciinema/asciinema#178 I'm closing it too.

[saxophonicle]

this issue was never fixed it needs to be reopened. The PR it was linked to was closed without merging and so this issue is lost to the void.

[AkihiroSuda]

@sickill Could you reopen this issue as @saxophonicle said?

[ku1ik]

My comments in the referenced PR were never addressed, and I never heard back from cbarcenas. Thus both PR and issue were closed.

[ku1ik]

If you'd like to completely prevent uploads today you can put this in the config file, as a temporary workaround:

[api]
url = http://nope

[ku1ik]

Or set ASCIINEMA_API_URL=http://nope variable (e.g. in your shell config).

[ghost]

We're having the same issue as @cbarcenas: We deal with sensitive data on a daily basis and the risk of automatically uploading screen casts is so significant that we are currently refraining from using asciinema, even though it's a really useful tool.

Therefore I'd offer to implement a solution. I would suggest re-implementing asciinema/asciinema#178 (re)based on the current state of the repository, i.e. a configuration option that can be used to disable uploading. Additionally, I would also have asciinema look for the configuration at /etc/asciinema/config such that out administrators can roll out a centralized solution.

@sickill Does that sound okay to you?

[IAXES]

this issue was never fixed it needs to be reopened. The PR it was linked to was closed without merging and so this issue is lost to the void.

I frequently use this tool for tutorials, examples, etc.; and it's pretty awesome. That being said, I too was very concerned about accidental data leakage (i.e. there are use cases where this tool couldn't be used for legal reasons, solely due to the potential for accidental data leakage by inexperienced users) or a simple mis-configuration problem resulting in sensitive data being leaked (i.e. default behaviour is to allow uploads, so mis-configuration results in potential for uploads in the worst case, or the app just not launching in the best case scenario).

In my own use case, the solution was to put all of the tooling needed for asciinema (plus the app itself) into a Docker container, and providing a launcher script (i.e. shell script and/or docker-compose.yaml) for the container so that it was always run with no internet access (there's a couple ways to do this; I just took the heavy-handed approach and disabled networking entirely; the container also has some "sanitized" launcher scripts inside so as to limit the number of ways in which asciinema can be launched, plus the script used in the Dockerfile ENTRYPOINT does a quick check via iproute2/ip for network interfaces, and "deliberately dies early" if anything other than loopback is detected, as a safety feature in case someone launches the container directly rather than via the launcher scripts I provided). This was enough for my own requirements.

This might help others aiming to lock down output options for the tool without going so far as to patch + repackage/re-deploy it.

Cheers!

[bkil]

Duplicated by:

• asciinema/asciinema#263
• asciinema/asciinema#316

[LudwikJaniuk]

If you'd like to completely prevent uploads today you can put this in the config file, as a temporary workaround:

[api]
url = http://nope

This totally works for me :) Perhaps this could just be added to the docs, to make it easier to find for people?

[ku1ik]

Proper fix, asciinema/asciinema#576, is coming in v2.4.0, which is around the corner.

[ku1ik]

Just released 2.4.0 with improved prompt which requires explicit choice: https://github.com/asciinema/asciinema/releases/tag/v2.4.0

[ku1ik]

I have reworked the upload related behavior for the upcoming asciinema 3.0:

1. asciinema rec now always requires a filename and never does any uploading - to upload you will use explicit asciinema upload <filename>
2. There's no implicit asciinema server URL configured - on first use (first upload or auth command) you will see a prompt asking for a server URL, with asciinema.org being suggested. Once confirmed the server URL will be saved and reused for future uploads.

I hope this addresses most of the concerns. You won't be able to accidentally upload anything anywhere, because it will require intent (asciinema upload), and a configuration step (server URL prompt).

When presented with a prompt you would confirm the use of asciinema.org or you would enter the URL of your self-hosted asciinema server instance. You will still be able to pre-configure the server URL in the config file via server.url = "..." to avoid the prompt.

3.0 hasn't been released yet, but it's close. If you'd like to test it then here's a release candidate (also providing binary downloads for Linux and macOS): https://github.com/asciinema/asciinema/releases/tag/v3.0.0-rc.1

Let me know if this looks like a good solution. Thanks!

[LudwikJaniuk]

@ku1ik That sounds good to me!

[LudwikJaniuk]

And thanks for doing this.