mirror of
https://git.proxmox.com/git/proxmox
synced 2025-05-23 15:14:38 +00:00
b926ea1f5c
previously we only used asymmetric cryptographic schemes to authenticate tickets. this is fairly costly and not necessary in every instance. imagine a service that runs as a single daemon. this daemon is then the only party that needs to sign and verify tickets. this makes hmac perfectly suitable for such usecases. hmac has some advantages over asymmetric schemes: - much simpler and well reviewed construction - much faster and better optimized crypto primitives (hash functions) this commit first introduces a new hmac key wrapper that uses openssl's hmac implementation and can easily be reused by other parts of the code. it also refactors the keyring code to make it easier to rotate new hmac keys into place so switching to hmac keys is easier. hmac keys are symmetric, so the verification key is the same key as the signing key. this breaks the previous assumption by the keyring that these correspond to public and private keys. thus, this commit introduces two wrapper enums to distinguish between hmac and asymmetric signature schemes. the verification of hmac keys is also done via `openssl::memcmp::eq()` to avoid potential timing side-channel attacks. below are some simple benchmarks done with criterion.rs to show how much faster hmac is, no matter the actual hash function: rsa 4096 + sha256 time: [2.7825 ms 2.7907 ms 2.7995 ms] ed25519 time: [94.411 µs 94.840 µs 95.324 µs] hmac sha256 time: [5.7202 µs 5.7412 µs 5.7645 µs] hmac sha384 time: [6.6577 µs 6.6780 µs 6.7006 µs] hmac sha3_256 time: [5.6930 µs 5.7114 µs 5.7322 µs] rsa with 4096 bit keys and a sha256 digest is our current default. the test itself consists of a single sign + verification cycle. criterion repeats this test as it sees fit to arrive at the above numbers. Signed-off-by: Stefan Sterz <s.sterz@proxmox.com> |
||
|---|---|---|
| .cargo | ||
| proxmox-acme | ||
| proxmox-acme-api | ||
| proxmox-api-macro | ||
| proxmox-apt | ||
| proxmox-async | ||
| proxmox-auth-api | ||
| proxmox-borrow | ||
| proxmox-client | ||
| proxmox-compression | ||
| proxmox-http | ||
| proxmox-http-error | ||
| proxmox-human-byte | ||
| proxmox-io | ||
| proxmox-lang | ||
| proxmox-ldap | ||
| proxmox-login | ||
| proxmox-metrics | ||
| proxmox-notify | ||
| proxmox-openid | ||
| proxmox-product-config | ||
| proxmox-rest-server | ||
| proxmox-router | ||
| proxmox-rrd | ||
| proxmox-schema | ||
| proxmox-section-config | ||
| proxmox-serde | ||
| proxmox-shared-memory | ||
| proxmox-sortable-macro | ||
| proxmox-subscription | ||
| proxmox-sys | ||
| proxmox-system-management-api | ||
| proxmox-tfa | ||
| proxmox-time | ||
| proxmox-uuid | ||
| .gitignore | ||
| build.sh | ||
| bump.sh | ||
| Cargo.toml | ||
| Makefile | ||
| README.rst | ||
| rustfmt.toml | ||
Local cargo config
==================
This repository ships with a ``.cargo/config`` that replaces the crates.io
registry with packaged crates located in ``/usr/share/cargo/registry``.
A similar config is also applied building with dh_cargo. Cargo.lock needs to be
deleted when switching between packaged crates and crates.io, since the
checksums are not compatible.
To reference new dependencies (or updated versions) that are not yet packaged,
the dependency needs to point directly to a path or git source.
Steps for Releases
==================
- Run ./bump.sh <CRATE> [patch|minor|major|<VERSION>]
-- Fill out changelog
-- Confirm bump commit
- Build packages with `make deb`.
-- Don't forget to commit updated d/control!
Adding Crates
=============
1) At the top level:
- Generate the crate: ``cargo new --lib the-name``
- Sort the crate into ``Cargo.toml``'s ``workspace.members``
2) In the new crate's ``Cargo.toml``:
- In ``[package]`` set:
authors.workspace = true
license.workspace = true
edition.workspace = true
exclude.workspace = true
repository.workspace = true
- Add a meaningful ``description``
- Copy ``debian/copyright`` and ``debian/debcargo.toml`` from another subcrate.
Adding a new Dependency
=======================
1) At the top level:
- Add it to ``[workspace.dependencies]`` specifying the version and any
features that should be enabled throughout the workspace
2) In each member's ``Cargo.toml``:
- Add it to the desired dependencies section with ``workspace = true`` and no
version specified.
- If this member requires additional features, add only the extra features to
the member dependency.
Updating a Dependency's Version
===============================
1) At the top level:
- Bump the version in ``[workspace.dependencies]`` as desired.
- Check for deprecations or breakage throughout the workspace.
Notes on Workspace Inheritance
==============================
Common metadata (like authors, license, ..) are inherited throughout the
workspace. If new fields are added that are identical for all crates, they
should be defined in the top-level ``Cargo.toml`` file's
``[workspace.package]`` section, and inherited in all members explicitly by
setting ``FIELD.workspace = true`` in the member's ``[package]`` section.
Dependency information is also inherited throughout the workspace, allowing a
single dependency specification in the top-level Cargo.toml file to be used by
all members.
Some restrictions apply:
- features can only be added in members, never removed (this includes
``default_features = false``!)
- the base feature set at the workspace level should be the minimum (possibly
empty!) set required by all members
- workspace dependency specifications cannot include ``optional``
- if needed, the ``optional`` flag needs to be set at the member level when
using a workspace dependency