GitXplorerGitXplorer
F

quad-image

public
15 stars
6 forks
11 issues

Commits

List of commits on branch stable.
Unverified
9670fdc6753279bc55c0280da53cbb0704f50bef

feat: relock npm

FFauxFaux committed a month ago
Unverified
c249f9153b0844572096972a06e4542b3b58d2c6

chore: bump prettier

FFauxFaux committed a month ago
Unverified
2f06b2c3f011ef7c50d8fcf14ccb5e199c6daff5

feat: bump exif / update

FFauxFaux committed a month ago
Unverified
1b87c25c5540edd1a88a54404237c52cac612566

fix: docker build / tsc

FFauxFaux committed 5 months ago
Unverified
b3e5066e4b534b0bfafa4e636c3462dbc1b839ee

feat: bump web

FFauxFaux committed 5 months ago
Unverified
aeea982202b34a1d1bb38aab7dc542b0dbca91e2

feat: bump rust

FFauxFaux committed 5 months ago

README

The README file for this repository.

quad-image

A very, very simple image hosting API, plus support files.

  • You send it an image.
  • The image is decoded and re-encoded using Piston Image.
  • The image is saved to the local disc.
  • The URL of the image is returned.

Building

quad-image probably only works on libc/Unix operating systems. It requires Rust, stable should be fine.

Build it by running cargo build --release, and grabbing the binary from target/release/quad-image.

Hosting

The expected deployment situation is:

  • quad-image running under a service manager.
  • the web/ subdirectory being served by a webserver
  • the webserver proxying traffic to quad-image.

There are example config files in quad-image.nginx (for nginx) and quad-image.service (for systemd). All the ports/addresses are hardcoded.


A Dockerfile is provided, if you prefer that kind of thing. It performs an isolated build and provides a minimal alpine-based container. It is not CI'd or published.

You could run it like this, if you trusted Docker's to manage your data storage, which I wouldn't recommend:

docker run --name quad-image -p 6600:80 -it $(docker build -q .)

Safety

HTTP is handled by Rouille, a simple Rust HTTP library. It's expected that you will run the API server behind nginx, so it doesn't even have to cope with TLS or any HTTP weirdness.

Users have no control over the target filename. They cannot plausibly overwrite files on the server, or generate URLs of their choosing.

Images are decoded and re-encoded using Piston Image before writing to the filesystem, there should be no way to get non-image data served. That is, all files that make it to the filesystem are valid, minimal images with no extra information in, either in metadata or elsewhere in the file.

This protects against:

  • users uploading images with their GPS location in metadata
  • serving exploits for other image libraries
  • distributing payloads that aren't part of the image
  • misconfigured webservers attempting to execute uploaded files as PHP

Piston Image is a Rusty library which probably doesn't have all the memory corruption bugs that libpng, libjpeg, etc. have, and almost certainly doesn't have all the insane failure modes that imagemagick's convert has.