Table of Contents

Lacre Ideas

Better decoupling of backend and frontend

Lacre frontend (the interface used to upload, verify and delete keys) communicates with the backend (the job actually importing keys and encrypting messages with them) via database.

This could be changed by moving all database accessing-code to the backend and exposing a simple API for the frontend to call. This API could be a Unix or TCP socket, or maybe some queue to send messages to.

Translations

We could use gettext to translate Lacre messages to different languages (for example Spanish).

Package Lacre

See Python Packaging User Guide.

There's a very well documented setup.py example.

Use database migration framework

See Alembic

Replace custom GnuPG wrapper

Instead of using our own wrapper for GnuPG we should consider using something more thorough, like pretty-bad-protocol. (However, this project seems to be inactive since 2018…)

Use advanced logging features

We could use context variables and logging.LoggerAdapter or logging.Filter to log more contextual information, like Message-Id of the message processed. That would make it easier to debug if something went wrong.

Read more in Logging Cookbook - Use of contextvars and documentation of contextvars module.

Provide a Milter

Instead of using after-queue mail filters, we could use Sendmail 8's Milter API. They can be written in Python too (see Python milters).

With Lacre being a Milter, it would become available for a wider audience (i.e. for Postfix and Sendmail admins).

Rewrite in Rust

Since Python has some limitations (e.g. its email module makes it hard to process messages without modifying their contents), I'm considering rewriting Lacre in Rust.

Crates I consider using:

Make Lacre observable

Monitoring Lacre's performance and correctness requires following logs at the moment.

We could expose endpoints with Lacre statistics for monitoring tools to consume, or consider other observability solutions.

Things to check: