No project description provided
Project description
pubpaste - publish files and clipboard online easily
This tool makes it easy to publish files, clipboards, screenshots, and photo galleries online with a single command. It's somewhat messy but it does its job well.
pubpaste
is not for novice users: it assumes you have access to an
SSH server and know how to configure a YAML file. It has been written
by and for its author in a fit of egoistical mania (unfortunately
typical for hackers), apologies normal humans out there reading this.
Tutorial
To publish a file:
pubpaste foo.jpg
The file is then uploaded, with rsync, in a directory with a secret name, which will generate a URL like this:
https://example.com/2020-04-20-oMz_C_6Njja_3VbW-f17LFiTAgNsnp22fqTwjQOgmF4/foo.jpg
The published URL is available in the clipboard, control-v in another window to share the results. That URL should be safe from guessing as long as the server is properly configured.
If a filename is not provided, text is read from standard input and
uploaded as a stdin.txt
file. That name can be changed with the
--stdin-name
flag.
You can also upload the current selection with:
pubpaste --xselection
You MUST configure pubpaste
before the above works, however. See
Configuration below.
pubpaste
supports many more ways of sharing content, see the
detailed how-to below for more information on screenshots, photo
galleries and more...
How-to
Configuration
pubpaste
requires manual configuration before it
works. Specifically, the output
and url_prefix
should be set in
the configuration. For example, this will tell pubpaste
to rsync
files to shell.example.com
, in the ~/public_html
directory, and
that this directory is exposed as https://example.com/~user:
output: "shell.example.com:public_html/"
url_prefix: "https://example.com/~user"
This configuration must be stored in ~/.config/pubpaste.yml
. Other
configuration file paths can be provided with the --config
command-line argument or pubpaste.yml
in the $XDG_CONFIG_HOME
directory (which defaults to ~/.config
).
Any parameter (like follow_symlinks
) can be specified in the
configuration file as well. The rule is that dashes (-
) MUST be
converted to underscores (_
).
Note that the output
directory should not have directory listings
enabled, see the Secret tokens section for more
information.
Some settings are not visible in the usage because they are better suited to be used in the configuration file. Here's a sample configuration file with all the settings not mentioned in the usage:
output: "shell.example.com:public_html/"
url_prefix: "https://example.com/~user"
base_dir: /home/user/public_html/
save_screenshots: ~/snaps/
They can still be used on the command-line, of course.
Screenshots
To publish a screenshot with maim, use:
pubpaste --screenshot
This will:
- start a terminal to show the maim timer
- start maim to select a window, it will wait 3 seconds before taking the screenshot
- preview the screenshot using your favorite image view (with xdg-open(1))
- ask for confirmation before uploading (with xmessage(1))
- then upload the file
Screenshots therefore require a bit more configuration than other mechanisms. First install the dependencies:
apt install maim
Install some image viewer, for example this is the default image viewer that comes with GNOME:
apt install eog
xdg-open(1)
and xmessage(1)
are very likely already installed on
your computer but if they aren't:
apt install x11-utils xdg-utils
You might not like the default xdg-open(1)
picks when opening an
image. To change that, use:
xdg-mime default application mimetype(s)
For example, this will pick the Eye Of GNOME image viewer:
xdg-mime default eog.desktop image/png
To see which application is currently in use, see:
xdg-mime query default image/png
By default, screenshots are not kept locally. But they can be retained
by setting the save_screenshots
configuration to a directory, for
example this will keep all screenshots in $HOME/snaps
:
save_screenshots: ~/snaps/
Image galleries
Build an image gallery with Sigal:
pubpaste --sigal *.JPG
This will generate an image gallery in a temporary directory and upload it to the server as a whole. The gallery configuration is currently hard-coded, but could eventually be added to the configuration file.
Clipboard support
When doing any upload, the remote URL will be copied to the X clipboard (the "CLIPBOARD" selection) that you paste with control-v, or control-shift-v in a terminal. That is different from the X selection, which you paste with the middle mouse button.
Note that pubpaste
reads from the X "PRIMARY" selection (the
highlighted text), when you use:
pubpaste --xselection
The idea behind this asymmetry is that we do not want the URL to override the current selection. By copying the URL in to the clipboard instead of the selection, we keep the current selection active. The clipboard is also more "durable" as it doesn't get change whenever you select some text.
You can use the --xclipboard
(-C
) argument to upload the
"CLIPBOARD" selection instead:
pubpaste --xclipboard
Do note that this works with "Copy image" links. For example, say you
have an image in your web browser, you can right-click on it and pick
the "Copy image" link, then call pubpaste
with -x
and it will
upload the image without having to first download the image as a file.
This is also useful to upload screenshots done within Firefox (in the "..." menu of the URL bar, "Take screenshot").
Image support only works if GTK and its Python bindings are installed.
Secret tokens
pubpaste
publishes files under a specified root directory but with a
unique token made of the current date (YYYY-MM-DD
) and a random,
presumably hard to guess, string. That token can be overridden with the
--token
(-T
) flag. For example, if you do not worry about
confidentiality and actually want a meaningful name, you can upload
a file publicly with:
pubpaste --token my-new-bike bike.jpg
Otherwise a properly secure token is generated. Note that directory
listings must be disabled for the secrecy to work: if you point
pubpaste
at a directory with directory listing enabled, all the
secrets will be public and the entire security of the system will
fail.
This can be fixed simply by adding an empty index.html
file into the
output
directory (if the web server is configured to serve those) or
by disabling directory listing (Options -Indexes
in Apache, for
example).
History
pubpaste
keeps an history of the things it has uploaded, in
~/.publish.history
. This allows you to cancel the last upload, for
example:
pubpaste --undo
... or arbitrary uploads:
pubpaste -T TOKEN --undo
Similarly, you can republish over the previous upload with:
pubpaste --republish ...
History can be displayed with the show-history
command. The last
token used is also accessible with the last-token
command.
Expiry
By default, uploads never expire. You can add a "TTL" (Time To Live)
file with the --ttl
argument which marks (in days) the time a paste
should be kept.
Old entries can be purged by deploying pubpaste
on the server side
and running:
pubpaste --purge --base-dir=/home/user/public_html
... where /home/user/public_html
is the path provided in output
on
the clients. That configuration will usually be store in the configuration
file, as such:
base_dir: "/home/user/public_html"
Shortcuts
The usage has all the details but if you use pubpaste
from the
command-line, you might like to use shortcuts for the commands. For
example, a screenshot is pubpaste -S
. See --help
for details.
Installation
This package is available on PyPI. It can be installed with pip
:
pip install pubpaste
Its requirements are minimal so you shouldn't need a virtual environment.
pubpaste
can also be ran directly from the source directory:
./pubpaste.py
or symlinked in your $PATH
:
ln -s $PWD/pubpaste.py /usr/local/bin/pubpaste
Known issues and limitations
Has no unit tests, but has been refactored to make that possible lately.
The photo gallery and screenshot code is messy.
Was written over a weekend and might be buggy.
Restricted to elite hackers that have SSH or rsync access and their own web server. Could be improved by supporting things like S3, "paste bins" or other file sharing systems.
In particular, mis-configuration of the web server can easily be
catastrophic: if Indexes
is enabled in the web server and the
parent directory doesn't have an index.html
to protect from leaks,
the secret tokens will be revealed and the secrecy of the system
compromised.
Similarly, secret tokens can easily leak if any peer that received it share it by mistake or maliciously. Access revocation is impossible without renaming the token, which must be done by hand.
Credits
This project was inspired by the publish
program originally written
by Florian Reitmeir and Peter Palfrader. It was re-written in Python
to make it easier to document, extend, and maintain.
It was renamed because we did not want to take over the publish
namespace out of respect for the existing one. It's also a little too
generic for a project name.
pubpaste
seemed like a nice alternative and didn't seem in use
according to search engines (checked DuckDuckGo, Google, GitHub, and
GitLab).
pub
refers to the inspiration for this project, the publish
shell
script that influence the command-line design and implementation.
paste
refers to the clipboard support. therefore pubpaste means
publish this paste, but it can of course do more than just publish
the clipboard.
pub
is also a reference to the real-world place that I dearly miss
since the start of the global pandemic that has everyone isolated and
bars closed. pub paste therefore obliquely refers to the stickiness
and smell of old pubs and bars, that strange smell of old yeast and
alcohol mixed with bleach or strong cleaning product that lingers
until you walk into a sound check the next day.
This is a message of hope: this will not go on forever and the messiness of humanity will return humbled yet improved.
Changes from publish
While pubpaste
generally tries to be backwards-compatible with
publish
in terms of command-line interface, it has the following
changes:
-
usage is clearer. different actions are "commands" that are clearly outlined in the usage and correctly "conflict" with each other
-
long options:
publish
only has one-letter options,pubpaste
supports longer form options as well -
--undo
defaults to the last token, ie.--republish
is implicit -
--undo
removes the token from history, allowing the user to "pop" backwards in the history, canceling multiple entries -
--purge
is builtin instead of being a separate script -
the
-L | --follow-symlinks
option is new -
photo gallery: the
--sigal
option is new
The following are general behavior changes:
-
builtin graphical notifications: while
publish
can be modified (through hooks) to notify the user on upload,pubpaste
does this outside the box. -
We use
xclip -selection clipboard
by default instead ofxclip
, because the latter conflicts with the-x
option. If available, we use GTK to handle clipboard events, which gives us image support. -
configuration file path and format:
publish
's configuration is a shell script in~/.publish.cfg
,pubpaste
's configuration is a YAML file in~/.config/pubpaste.yml
. this breaks backwards compatibility. -
extensibility:
pubpaste
is less extensible thanpublish
. the latter has "hooks", shell functions that run before and after various points in the program, and that the configuration can totally override. this is very powerful, but also not well documented and possibly dangerous. we took a more traditional approach inpubpaste
: modifications should be done in the source code and proposed as patches
The following functionality is missing:
-q
: encodes the URL in a QR code and uploads that- maximum history size
Those options were discarded and will not be implemented:
-8
: web server should be properly configured-r
obscure rsync function i never useis_text
detection: we will just assume stdin is text
Prior art
Similar projects include, apart from the above publish, ordered alphabetically:
- 0bin.net: client-side encrypted, Javascript
- 0x0.st: AKA "the null pointer", minimalistic paste bin
- Stikked: PHP, "advanced and beautiful"
- dpaste: novel idea: paste over the DHT
- hardbin: IPFS-based
- ix.io: possibly the OG minimal paste bin (2009)
- microbin: expiry, raw files, rust, qrcodes, expiry
- pastebinit: supports publishing text to multiple paste sites, Python
- pasthis: PHP-based, also command-line tool
- plowshare: (collection of) shell scripts to do somewhat the same, delegates site-specific features to unbundled scripts, removed from Debian because security liability
- privatebin: minimal, client-side encrypted, PHP
- termbin/fiche: minimalist; not even curl, just nc, C
- transfer.sh: minimalist, Golang
- up1: client-side encrypted, Javascript
I am not including here the list of actual sites deploying some of those tools or other proprietary ones.
This list is likely incomplete. Note, that said, that none of the above implementation have the feature set of pubpaste (not even publish). pubpaste and publish both lack the ability to do client-side (i.e. browser-based) encryption (no, OpenPGP, Age, or OpenSSL do not count).
Contributing
See the contribution guide for more information. In short: this is a free software project and you are welcome to join us in improving it, both by fixing things, reporting issues or documentation.
This project adheres to the Covenant code of conduct.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.