SieveManager

New versions of SieveManager typically have the same system requirements and dependencies as older versions, and since the ManageSieve protocol has ossified, this is unlikely to change. Moreover, SieveManager can be obtained using common package managers from Codeberg and the Python Package Index. So upgrading is trivial.

Bugs can be reported using an issue tracker on GitHub. Bugs reported by email are posted on the issue tracker.

No vulnerabilities have been reported so far.

See https://odkr.codeberg.page/sievemgr/contrib.html.

Git hooks are used to run Flake8, PyLint, and Ruff, which are set up to enforce those styles.

No binaries are generated.

SieveManager is written in Python. There is no build system in the sense of the question.

There is no build system in the sense of the question.

Python is a scripting language.

SieveManager can be installed using "make" as well as "pip", which is the default for Python packages. There is also an APT repository for Debian-based systems.

SieveManager's makefile conforms to the GNU coding standards (chap. 7), to the extent to which they are applicable.

SieveManager uses standard Python tools and ships machine-readable files that can be used to install linters, static code analysers, and documentation generators.

See:

• https://codeberg.org/odkr/sievemgr/src/branch/main/pyproject.toml
• https://codeberg.org/odkr/sievemgr/src/branch/main/linters.txt
• https://codeberg.org/odkr/sievemgr/src/branch/main/docs/sphinx.txt

SieveManager depends on the cryptography and dnspython Python modules, both of which use GitHub as a version control system. The maintainer has subscribed to releases and security alerts for both repository. Safety is used to scan dependencies for known vulnerabilities periodically and before each release.

Externally used components can be installed and updated using pip, which is the standard for Python. Dependencies are kept to a minimum.

SieveManager uses FLOSS tools and libraries only.

Bandit, MyPy, and a subset of the test suite are run on each commit by a Git pre-commit hook. Additionally, Dlint, Flake8, PyLint, Pyright, Ruff, , vermin, vulture, and the full test suite are run on each push by a Git pre-push hook and when releases are compiled by a Make prerequisite.

Contributors are asked to write tests for their contributions on https://odkr.codeberg.page/sievemgr/contrib.

Contributors are asked to write tests for their contributions on https://odkr.codeberg.page/sievemgr/contrib.

SieveManager implements the following Security design principles:

• Secure by default
• Separation of duties
• Open design
• Application coding best practices

Support for SCRAM-SHA-1 is mandated by RFC 5804. But connections are secured with TLS by default, so the use of SHA-1 should not be problematic. Also, SCRAM-SHA-1 is only used if the server supports neither SCRAM-SHA-2 nor SCRAM-SHA-3, and SCRAM-SHA-1 is still preferable to plaintext authentication.

SieveManager uses OpenSSL or LibreSSL (via Python) and supports every variant of the SCRAM authentication mechanism family (SHA-1, SHA-2, and SHA-3).

SieveManager supports using passwords managers and TLS client authentication.

SieveManager secures connections with TLS by default.

SieveManager requires Python v3.9, which supports TLS v1.2.

Server certificates are verified and checked for having been revoked.

STARTTLS is issued right after a connection is established.

Releases are signed with GnuPG. The installation instructions cover obtaining the developer key. See https://odkr.codeberg.page/sievemgr/install.

Each commit is signed, each tag is signed, each release is signed.

SieveManager is a client. It only accepts input from the user and the server. The server is verified against its TLS certificate and, if supported, a shared secret using SCRAM by default. Server messages are validated for syntactical and, to the extent possible, semantic correctness.

I am following Python and TLS best practices; "hardening" in the sense of compiling hardened binaries or securing connections beyond using TLS (e.g., CSP, certificate pinning) does not apply.

Bandit and Dlint include such rules.

Python is a memory-safe language.