4d6922e2c4
previously we used our own hmac-like implementation for csrf token signing that simply appended the key to the message (csrf token). however, this is possibly insecure as an attacker that finds a collision in the hash function can easily forge a signature. after all, two messages would then produce the same start conditions before hashing the key. while this is probably a theoretic attack on our csrf implementation, it does not hurt to move to the safer standard hmac implementation that avoids such pitfalls. this commit re-uses the hmac key wrapper used for the keyring. it also keeps the old construction around so we can use it for a transition period between old and new csrf token implementations. this is a breaking change as it changes the signature of the `csrf_secret` method of the `AuthContext` trait to return an hmac key. also exposes `assemble_csrf_prevention_toke` so we can re-use this code here instead of duplicating it in e.g. proxmox-backup's auth_helpers. 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