jriou/julien.riou.xyz
1
0
Fork 0
Code Activity

feat: Add coller la petite post

Browse source 
Signed-off-by: Julien Riou <julien@riou.xyz>
This commit is contained in:
Julien Riou 2025-08-21 20:53:43 +02:00
parent f0cab2f7c3
commit 47ca98cc16
Signed by: jriou
GPG key ID: 9A099EDA51316854
6 changed files with 753 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

207
content/blog/coller-la-petite.md Normal file
View file

@ -0,0 +1,207 @@
+++
title = 'Coller (la petite)'
date = 2025-08-21T20:00:00+02:00
+++
At the beginning of my career, we used e-mails to communicate with co-workers.
We could explain an issue in details with a very long e-mail, but it was hard
to follow live discussions. For synchronous communication, we used phones. We
had to constantly switch between both systems. Have you ever received a call
saying "have you seen my last e-mail?".
Then instant messaging systems came to fill the gap. There was
[MSN](https://en.m.wikipedia.org/wiki/MSN_Messenger) at home to chat with your
friends. Or XMPP at work. I have used this protocol for 10 years. OK there was
no gif, limited support of emojis and you can't call your colleagues but it
could ran everywhere, even on a [solarpunk phone](http://compost.party/).
Nowadays, we have Slack, Webex, Microsoft Teams, Discord. Maybe you have the
chance to use an open source solution like Matrix or Mattermost. The decision
to use one of another has probably been made before you joined the company and
you don't have enough power to introduce a major change because communication
systems are central to companies. So we use Webex at work. We have to deal with
all the limitations. One of them is the ability to paste long text without
polluting the feed.
# Pastebin service
In french, "paste" could be translated to "coller". One day, I decided to start
my own pastebin service based on [sticky
notes](https://github.com/sayakb/sticky-notes). I have ordered a VPS, an
_internal_ top-level domain, restricted network access. The _coller la petite_
service was born (in reference to [this
song](https://genius.com/Franko-coller-la-petite-lyrics)). The name was fun.
The service was useful. I did no marketing campaign around it because I knew it
could be used to store sensible data. I have contacted our security team to
tell them the service existed and told every user that it's an **external**
service with no service level agreement (_best effort_ mode).
This website had little to no maintenance. Upgrade Debian packages, dump and
restore the database on a new major version every year, easy peasy. For fun, I
have created a Perl client to learn this language (because I had to). Then a
more portable Go client was created by one of my team mates. Why do we need
clients when there's already a website? Because sometimes we prefer to use a
CLI and not a browser to share the content of our clipboard or the content of a
file.
The service became so popular that the need was proven. The team responsible
for managing collaboration tools came to me to see how could we move this
external service and make it internal: hosted on private services with the
enterprise security layer on top of it. I have explained the history, how it
works and how I see the future to multiple people of that team. There is a high
turnover rate apparently. Now I'm sick of explaining it over and over again.
# What's the problem?
There are multiple issues with this service today. Sticky notes is not
maintained anymore. It's written in PHP which makes it harder for us to fork,
contribute and deploy. Last but not least, there is no encryption.
# PrivateBin
The most popular and secure pastebin service out there is
[PrivateBin](https://privatebin.info/). They take security very seriously. The
content is encrypted from the browser so the hosting provider never knows
what's inside. While this solution is awesome for the security, it makes it
harder to use on a day to day basis. We can't use [curl](https://curl.se/) to
download the raw content of a note. I get the argument of users always making
the poorest choice but I don't want to set up a second solution to fill the gap
or telling people to deal with it. I want a single solution for doing both. I
want to paste public data. I also want to paste and download snippets securely.
I also don't like long URLs because, unlike Mastodon where size doesn't matter,
they tend to bloat the message on those platforms. The fact that you have to
use an URL shortener in the
[FAQ](https://github.com/PrivateBin/PrivateBin/wiki/FAQ#the-url-is-so-long-cant-i-just-use-an-url-shortener)
says it all.
# Coller
So I created a pastebin server and clients to create and read notes. Yep. Yet
another pastebin solution. Not because we definitely needed one more, but
because I use it daily, I like simplicity, usability, security and I love doing
side projects in Go.
## Features
- Website
- Raw content by default
- Compatible with curl
- Encryption with password
- Compression on the backend
- Automatic retention
- PostgreSQL or sqlite database
- CLI to create notes ("coller") from the clipboard or a file
- CLI to read encrypted notes ("copier")
- Easy to deploy
---
![Screenshot of the landing page](/coller/coller-index.png)
---
![Screenshot of the page saying "Note created sucessfully" with the note
URL](/coller/coller-created.png)
---
![Screenshot of the "coller" CLI creating a note from a file and reading the
node with "copier"](/coller/coller-cli.png)
---
# Encryption levels
## No encryption
[It starts with](https://www.youtube.com/watch?v=eVTXPUF4Oz4) no encryption.
Sounds crazy in a world where everything has to be encrypted, right? Not so
crazy. Sometimes, we just want to paste a bunch of characters that we could
have been said publicly on social networks and that's fine. The URL will be
very short and easy to share.
## Server side encryption
The next level is to use basic encryption by letting the website generate a
password for you. You click on a checkbox and the content of the note is
encrypted before being stored. The encryption key is the password. You can
choose to keep the key for yourself and only you and the server know it. Or
share it to other people you trust. Anyway, the server knows it.
## Server side encryption with user key
Same solution as the server side encryption but this time, the user defines the
password. Security could be lowered if the key is weak (too short, words from
the dictionary) when the server will always generate strong enough keys. In the
end, the server still knows your choosen key.
## Client side encryption
If you don't trust the server but you want to use the service anyway, you could
tell the client to encrypt the content before sending it to the server. The
client will generate a random (strong) key. This time, the key is private. Only
you knows it. You can do whatever you want with the key, but you should keep it
to yourself or share it carefully.
Accessing the encrypted note using the password in the URL will make the server
aware of your password. You should use the "copier" client to download the
encrypted note and decrypt outside of the server.
## Client side encryption with user key
Same as client side encryption but you can choose the password you want.
## Encryption summary
A picture is worth a thousand words:
![Diagram with the server on the left and two URL: one with the note ID, one
with the note ID and the password. On the right, there are the copier and the
web clients. Clients and server are separated by a straight line. Three lines
are linking clients and the server. The first one is between the copier client
and the server where the key icon is on the client for client-side encryption.
The second one is between the web client and the URL without password to show
no encryption. The last one is between the web client and the server with a key
icon on the URL below the server to show the server-side
encryption.](/coller/coller-encryption.svg)
# What to choose?
| Level | Usability | Confidentiality |
| ---------------------- | --------- | --------------- |
| No encryption | ⭐⭐ | ⭐ |
| Server-side encryption | ⭐⭐⭐ | ⭐⭐ |
| Client-side encryption | ⭐ | ⭐⭐⭐ |
If you can use the copier client (CLI) and keep the password for yourself, go
for it. It's the most secure solution. If you can't, the website is designed to
use the server-side encryption with a strong generated password.
# Cipher
The most famous cipher is
[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) 256 with
[GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode). It would have been
simpler to implement
[CBC](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation) like
[pgBackRest](https://pgbackrest.org/) but the mode has been removed from TLS
1.3 for several flaws. I decided to use
[XChaha20-Poly1305](https://pkg.go.dev/golang.org/x/crypto/chacha20) because it
reminds me [this banger](https://www.youtube.com/watch?v=DGsL8hA-1rE) from this
year's Eurovision and I wanted to use something different. Don't worry, this
cipher is [one of the most secure in the
world](https://wiki.mozilla.org/Security/Server_Side_TLS).
# Source code
The source code is available [on my forgejo](https://git.riou.xyz/jriou/coller)
instance under the permissive
[MIT](https://git.riou.xyz/jriou/coller/src/branch/main/LICENSE) license.
# Conclusion
This little side project turned into a fully functional pastebin solution. It
was also a great excuse to implement encryption in Go. If you find a security
issue or want to implement a feature or fix bugs, contributions are welcomed.