issue_comments

Should be consistent with the create-table command as much as possible: $ sqlite-utils create-table mydb.db mytable \ id integer \ name text \ age integer \ is_good integer \ --not-null name \ --not-null age \ --default is_good 1 \ --pk=id

Here's the issue that explains that warning: https://github.com/pypa/pip/issues/5599

This should fix it (risky):

from pip._internal.cli.main import main

Quick prototype of datasette install: ```diff diff --git a/datasette/cli.py b/datasette/cli.py index 287195a..95b6eb7 100644 --- a/datasette/cli.py +++ b/datasette/cli.py @@ -231,6 +231,18 @@ def package( call(args)

+@cli.command() +@click.argument("packages", nargs=-1, required=True) +def install(packages): + "Install Python packages - e.g. Datasette plugins - into the same environment as Datasett" + import pip + + try: + pip.main(["install"] + list(packages)) + except SystemExit as e: + pass + + @cli.command() @click.argument("files", type=click.Path(exists=True), nargs=-1) @click.option( ```

``` $ datasette install Usage: datasette install [OPTIONS] PACKAGES... Try 'datasette install --help' for help.

Error: Missing argument 'PACKAGES...'. $ datasette install datasette-vega WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip. Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue. To avoid this problem you can invoke Python with '-m pip' instead of running pip directly. Collecting datasette-vega Using cached datasette_vega-0.6.2-py3-none-any.whl (1.8 MB) ... ```

Telling people how to figure out that pip location is going to be pretty unpleasant.

How about instead providing a datasette plugins --install=datasette-graphql command?

Or datasette install datasette-vega

It would run pip install in the same virtualenv as Datasette itself.

http://jelly.codes/articles/python-pip-module/ shows how to do this:

```python

import pip

try: pip.main(["install", "plumbum"]) except SystemExit as e: pass ```

GitHub security advisory: https://github.com/simonw/datasette/security/advisories/GHSA-q6j3-c4wc-63vw

datasette-graphql uses the logic from TableView right now. It wasn't too unpleasant, but I do worry about the two of them being coupled together in this way.

https://github.com/simonw/datasette-graphql/blob/cc65ec294b0bf8e26213fc68bb5487066de9caab/datasette_graphql/utils.py#L412-L417

```python request = Request.fake(path_with_query_string)

    view = TableView(DatasetteSpecialConfig(datasette))
    data, _, _ = await view.data(
        request, database=database_name, hash=None, table=table_name, _next=after
    )

```

Should be released in a couple of minutes: https://travis-ci.org/github/simonw/datasette/builds/716328883

Submitting the form on https://latest.datasette.io/fixtures/neighborhood_search demonstrates that this is fixed.

That appears to have worked.

It's worth noting that in order to exploit this issue the following would all need to be true:

• A user is running a copy of Datasette protected by a cookie-based authentication plugin AND configured with at least one writable canned query
• An attacker is in control of a URL that could concievably be returned on a page that is displayed as the result of submitting a read-only canned query
• An authenticated user of that Datasette instance, who is running a browser that doesn't support the SameSite=lax cookie parameter (which is widely supported by modern browsers), submits the read-only canned query form and then clicks a link to the attacker's off-site page, exposing their CSRFToken in the attacker's HTTP referer logs
• The attacker then tricks that user into visiting their own malicious web page which includes a POST form that auto-submits against the writable canned query that the attacker wishes to exploit, including the CSRF token as a hidden field

The attacker would need full knowledge of the URL and form layout of the Datasette instance that they are exploiting.

Fix has been released in Datasette 0.46: https://datasette.readthedocs.io/en/latest/changelog.html#v0-46

Here's what happened when I installed homebrew-vd: https://gist.github.com/simonw/7bfd971a62743d7ca248e6b5e696c240

It worked! And from digging around, it has a virtual environment at /usr/local/Cellar/visidata/1.5.2/libexec/

Which means /usr/local/Cellar/visidata/1.5.2/libexec/bin/pip is a working pip

And I tried running these commands and confirmed that I get a datasette with an additional plugin:

/usr/local/Cellar/visidata/1.5.2/libexec/bin/pip install datasette /usr/local/Cellar/visidata/1.5.2/libexec/bin/pip install datasette-graphql /usr/local/Cellar/visidata/1.5.2/libexec/bin/datasette plugins [ { "name": "datasette-graphql", "static": false, "templates": true, "version": "0.11", "hooks": [ "register_routes", "startup" ] } ] So I can package Datasette as a homebrew package AND I can give people instructions for installing plugins.

How would plugin installation work if Datasette was installed via homebrew?

Another useful example: https://github.com/Homebrew/homebrew-core/blob/master/Formula/trailscraper.rb