it can happen that we have leftover entries with non-completed challenges.
since a user cannot continue here in a sensible way, ignore and discard
them
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
to is the last *valid* character, and ranges end by default with one
less, so extend the range to the actual last character
this fixes an issue that we could not parse old configs with
non-padded base64 values
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This consists of two parts:
1) A proxmox_tfa_api module which temporarily lives here but
will become its own crate.
Most of this is a copy from ' src/config/tfa.rs with some
compatibility changes:
* The #[api] macro is guarded by a feature flag, since we
cannot use it for PVE.
* The Userid type is replaced by &str since we don't have
Userid in PVE either.
* The file locking/reading is removed, this will stay in
the corresponding product code, and the main entry
point is now the TfaConfig object.
* Access to the runtime active challenges in /run is
provided via a trait implementation since PVE and PBS
will use different paths for this.
Essentially anything pbs-specific was removed and the
code split into a few submodules (one per tfa type
basically).
2) The tfa module in pve-rs, which contains:
* The parser for the OLD /etc/pve/priv/tfa.cfg
* The parser for the NEW /etc/pve/priv/tfa.cfg
* These create a blessed PVE::RS::TFA instance which:
- Wraps access to the TfaConfig rust object.
- Has methods all the TFA API call implementations
These are copied from PBS' src/api2/access/tfa.rs,
and pbs specific code removed.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
