--- Begin Message ---
I have just re-read the cover and looked at the applied changes as of now
(assuming nothing more is coming) and considering what it was supposed to fix
(4886 only) and what it breaks (original myself quoted below).
I can't help, but wonder, if the whole change was about avo
--- Begin Message ---
On Thu, Jan 11, 2024 at 11:51:18AM +0100, Fabian Grünbichler wrote:
> and allow explicitly unmerging to remove the symlink altogether.
Apologies if I am second guessing here, but this is meant to be explicitly
later "unmerging" on pveproxy start of new version of PVE? If so,
Hey,
thanks for contributing!
Your right, the RFC suggests that the key the user supplies should be
interpreted as base64url and not base64. Since I'm not the first and
probably won't be the last to run into this mistake, I wonder if it
might be worth to be a bit more lenient and implement a simp
The default certificate does not have a name.
Reported-by: Dietmar Maurer
Signed-off-by: Maximiliano Sandoval
---
src/panel/Certificates.js | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/panel/Certificates.js b/src/panel/Certificates.js
index a522ab6..f9
If the metadata archive under /etc/lvm/archive for a particular VG has
a lot of files or is overly large, `vgs` occasionally prints a message
to stdout [1]. Currently, the LVM plugin tries to parse this message
and thus produces the following confusing warnings in the output of
`pvesm status` or th
Accroding to RFC 8555:
> The MAC key SHOULD be provided in base64url-encoded form...
However, currently we are only decoding the MAC key as base64.
This patch uses the correct function to decode the user provided
MAC key as base64url format. This can fix authentication error
when a user uses comma
