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

4.9.x pophelp edits #55

Open
9 tasks
Bloke opened this issue Jul 28, 2020 · 4 comments
Open
9 tasks

4.9.x pophelp edits #55

Bloke opened this issue Jul 28, 2020 · 4 comments
Milestone

Comments

@Bloke
Copy link
Member

Bloke commented Jul 28, 2020

The following pophelps will need revising or tweaking:

  • status: Should probably mention in the 'not viewable outside of the admin area' that they are previewable to logged-in users.
  • article_image: Possibly add the fact that a comma-separated list of image IDs may be used and displayed using the <txp:images> tag to make galleries.
  • keywords: When they are rebranded as tags, and expanded, this text will need to be changed.
  • use_plugins: and you want to make check if one or more plugins are involved
  • comments_on_default: Comments can be enabled/disabled Note that allowing comments can be turned on or off at any time
  • use_textile: Phase this pref out. Create a default_textfilter pref instead, and rewrite the text to reflect its nature as a pluggable filter for any markup system.
  • image_category: Fix the text to remove the links to the deprecated tags and link to <txp:images /> instead.
  • upload_plugin: From 4.9.0, this text will need to be revamped to include the fact that .txt files can be dragged/browsed and that all plugins go through the verify step.
  • install_plugin: From 4.9.0, this text will need to be revamped to include the fact that URLs may be pasted here to load plugins from remote repositories as long as the host permits it. Also mention that all plugins will be passed through the verify step.
@Bloke Bloke added this to the 4.9 milestone Jul 28, 2020
@colak
Copy link
Member

colak commented Jul 29, 2020

install_plugin: From 4.9.0, this text will need to be revamped to include the fact that URLs may be pasted here to load plugins from remote repositories as long as the host permits it. Also mention that all plugins will be passed through the verify step.

Will that be safe? Are we opening a Pandora's box here?

@Bloke
Copy link
Member Author

Bloke commented Jul 29, 2020

What do you mean by safe? You click Install and it shows you on the verify step what is going to be installed. What the code is, what Textpack strings, the help and any additional files bundled (if it's a zip). If you don't like it, you click Cancel.

If the file isn't of a format we expect, we bail out. If the file contains dodgy content and the admin clicks Install, caveat emptor.

@colak
Copy link
Member

colak commented Jul 29, 2020

Up to now, we have been downloading and installing plugins from trusted sources.
I actually think of this as an excellent idea if the remote depository is https://plugins.textpattern.com/ where the plugins can be curated and tested by the community.

Remote depositories beyond the community's control can be anywhere and the transfer could be intercepted. I realise that this can happen anyway but it's just adding another safety concern.

@Bloke
Copy link
Member Author

Bloke commented Jul 29, 2020

True but even if the endpoint is plugins.textpattern.com/plugins/smd_query.zip then it could still be 'intercepted' via man-in-the-middle or a rogue bit of JS loaded by hacking core files.

But it doesn't matter if it's intercepted and delivers the wrong content, because:

  • When you click the first Upload button, the remote file is downloaded and stored in your temp file location on your server. We need to add a check here that it doesn't exceed the max 'upload file size' (if we can) and abort the download if so.
  • Assuming the download goes well, the content of the file is parsed and extracted (if it's a zip or a plugin template or a .txt file) or just displayed as-is if it's .php, at the verify step. Anything else will be kicked out.
  • A hash is generated and stored in the DB that exactly matches the downloaded file contents. The token reference to that hash is pushed to the Verify step page.
  • If you choose to cancel at the Verify step, the temp file is deleted. Nothing happens.
  • If you read through the code and files that are going to be installed, and decide to go forward, you click Install. The token passed from the Verify step is then fetched from the database and compared to the temp file's recomputed hash. If anything differs, installation is aborted. Otherwise, installation proceeds. This prevents anyone tampering with the file between download and installation.

The additional thing we have as a safety net is that no plugins run on the Plugins panel. So you can't have a rogue plugin running that could intercept a click or tamper with a download. Only physical access to Txp's server filesystem AND regenerating a new token in the database will make untrusted code be installed.

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

No branches or pull requests

3 participants