Proxmox backup client - Latest version fails to build (pxar)

[bbarik]

Using latest rust 1.89, proxmox-backup-client fails to build, because of implicit autoreference in unsafe block.

See the error log here:

   Compiling pxar v1.0.0 (/build/pxar)
   Compiling enum-as-inner v0.6.1
   Compiling rand v0.8.5
   Compiling pbs-tools v0.1.0 (/build/proxmox-backup/pbs-tools)
   Compiling proxmox-shared-memory v1.0.0 (/build/proxmox/proxmox-shared-memory)
warning: hiding a lifetime that's elided elsewhere is confusing
  --> pbs-tools/src/crypt_config.rs:87:24
   |
87 |     pub fn data_signer(&self) -> openssl::sign::Signer {
   |                        ^^^^^     --------------------- the same lifetime is hidden here
   |                        |
   |                        the lifetime is elided here
   |
   = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
   = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
   |
87 |     pub fn data_signer(&self) -> openssl::sign::Signer<'_> {
   |                                                       ++++

   Compiling async-trait v0.1.88
   Compiling data-encoding v2.9.0
   Compiling ipnet v2.11.0

<multiple elided lifetimes warnings....>

error: implicit autoref creates a reference to the dereference of a raw pointer
  --> /build/pxar/src/decoder/mod.rs:38:14
   |
38 |         &mut (*ptr.as_mut_ptr())[..]
   |              ^^----------------^^^^^
   |                |
   |                this raw pointer has type `*mut [u8; 4096]`
   |
   = note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
note: autoref is being applied to this expression, resulting in: `&mut [u8; 4096]`
  --> /build/pxar/src/decoder/mod.rs:38:14
   |
38 |         &mut (*ptr.as_mut_ptr())[..]
   |              ^^^^^^^^^^^^^^^^^^^
   = note: `#[deny(dangerous_implicit_autorefs)]` on by default
help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
   |
38 |         &mut (&mut (*ptr.as_mut_ptr()))[..]
   |              +++++                    +

<multiple elided lifetimes warnings....>

warning: `pxar` (lib) generated 6 warnings
error: could not compile `pxar` (lib) due to 1 previous error; 6 warnings emitted
warning: build failed, waiting for other jobs to finish...
warning: `pbs-tools` (lib) generated 1 warning

 

[dcsapak]

Hi,

I cannot reproduce on current master here.

What does

git status
cargo tree

say?
what's the steps and command that you use to build it ?

 

[bbarik]

I can still reproduce on my end (7aa8965e42674fa41ecde168ef00429edc7935ee):

git status (updated to match my nixos environment):

On branch master

Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
modified:   .cargo/config.toml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
.devenv.flake.nix
.devenv/
devenv.lock
devenv.nix
devenv.yaml

I modified the config to disable the hardcoded path to debian /usr/share/cargo/registry and the replacement by debian-packages.

The devenv.nix file only enables the latest cargo version for the dev environment:

{
  languages.rust = {
    enable = true;
    channel = "stable";
  };
}

The rest of the devenv* files are generated by devenv (https://devenv.sh/), so not important in this context.

Cargo information:
- Cargo version: cargo 1.89.0 (c24e10642 2025-06-23)
- Cargo tree:

pxar v1.0.0 (/path/to/pxar)
├── endian_trait v0.6.0
│   └── endian_trait_derive v0.6.0 (proc-macro)
│       ├── quote v0.4.2
│       │   └── proc-macro2 v0.2.3
│       │       └── unicode-xid v0.1.0
│       └── syn v0.12.15
│           ├── proc-macro2 v0.2.3 (*)
│           ├── quote v0.4.2 (*)
│           └── unicode-xid v0.1.0
├── libc v0.2.175
├── siphasher v1.0.1
└── tokio v1.47.1
    └── pin-project-lite v0.2.16

- To build : cargo build

 

[dcsapak]

I can still reproduce on my end (7aa8965e42674fa41ecde168ef00429edc7935ee):

that commit hash does not exist here in the proxmox-backup repository but in the 'pxar' repository, so it's not actually the proxmox-backup-client?

git status (updated to match my nixos environment):

well, building it is only supported on debian with our developement repos. some of the pacakges are patched, e.g. to use different dependencies, etc.
so you don't use those packages, you'd have to track down the changes and packages yourself, e.g. a cargo tree looks here like this:

pxar v1.0.0 (/home/dcsapak/rust/pxar)
├── endian_trait v0.6.0
│   └── endian_trait_derive v0.6.0 (proc-macro)
│       ├── proc-macro2 v1.0.92
│       │   └── unicode-ident v1.0.13
│       ├── quote v1.0.40
│       │   └── proc-macro2 v1.0.92 (*)
│       └── syn v2.0.98
│           ├── proc-macro2 v1.0.92 (*)
│           ├── quote v1.0.40 (*)
│           └── unicode-ident v1.0.13
├── libc v0.2.169
├── siphasher v1.0.1
└── tokio v1.43.1
    └── pin-project-lite v0.2.13

see the different versions in libc, tokio, pin-project-lite, quote, etc.

 

[fabian]

we are currently using rustc 1.85, so maybe you have better luck with that. or you could try disabling the lint dangerous_implicit_autorefs.. in any case, if you try to build a complex project like PBS in a very non-standard environment, you need to be prepared to dive in and analyze problems yourself and provide all the details..

 

[bbarik]

Ah yes I see:
- I did meant pxar (even wrote that in the title but wrote proxmox-backup-client)
- I know I am using an unsupported OS (NixOS), but finds it quite weird why there would be debian-specific dependencies. I understand that all the proxmox stack is based on debian, but for pxar (which is a client-side backup application) it could be installed on any machine. I understand the stability argument. I do think that it would be a very compelling argument to be made for the wide range of systems that could be backed up on proxmox backup server, even if I do understand well the need to work on the business features first.
- It is probably an error introduced in the latest versions of Rust to avoid very unsafe memory management, and still think this could still be of interest if someone would want to fix this before it breaks when all the tooling updates on Debian too.
- I do see the difference in the dependency versions but the very minor revision differences only indicate bug fixes. If you absolutely need specific versions to guarantee the usage of the applications, the versions can be specified even more precisely in the Cargo.toml.

Applying the proposed fix does make pxar compile correctly:

diff --git a/src/decoder/mod.rs b/src/decoder/mod.rs
index d62d030..84a5c24 100644
--- a/src/decoder/mod.rs
+++ b/src/decoder/mod.rs
@@ -35,7 +35,7 @@ fn scratch_buffer() -> &'static mut [u8] {
     unsafe {
         let ptr: *mut MaybeUninit<[u8; 4096]> = &raw mut SCRATCH_BUFFER;
         let ptr: &mut MaybeUninit<[u8; 4096]> = &mut *ptr;
-        &mut (*ptr.as_mut_ptr())[..]
+        &mut (&mut (*ptr.as_mut_ptr()))[..]
     }
 }

I would have opened a pull request but it seems like your system is gated to Proxmox employees, so I will leave it at your team discretion to apply this patch now or when it becomes necessary. Thank you for your hard work!

 

[fabian]

- I know I am using an unsupported OS (NixOS), but finds it quite weird why there would be debian-specific dependencies. I understand that all the proxmox stack is based on debian, but for pxar (which is a client-side backup application) it could be installed on any machine. I understand the stability argument. I do think that it would be a very compelling argument to be made for the wide range of systems that could be backed up on proxmox backup server, even if I do understand well the need to work on the business features first.

it's only built and tested on Debian, and we also package all the dependencies, which sometimes means that certain bug fixes or other changes are also included in those packaged dependencies, but not (yet) upstream (or not in the version used by us). it's not that pxar has anything Debian specific in it, but that there might be subtle differences between the crates-as-packaged-by-us/Debian and upstream ones (e.g., bundled C libraries are excluded and the ones from Debian used instead).

- It is probably an error introduced in the latest versions of Rust to avoid very unsafe memory management, and still think this could still be of interest if someone would want to fix this before it breaks when all the tooling updates on Debian too.

yes. I just wanted to give you pointers how to avoid it for now on your end, that doesn't mean that the new lint doesn't indicate that there should be code changes on our end as well - but see below

- I do see the difference in the dependency versions but the very minor revision differences only indicate bug fixes. If you absolutely need specific versions to guarantee the usage of the applications, the versions can be specified even more precisely in the Cargo.toml.

no they can't, because there is no way to indicate in Cargo.toml "we need this crate exactly as packaged for Proxmox products", which is the only environment that they are currently tested in for some crates we do have plans to publish them on crates.io, at which point they should be reasonably free of such requirements. and it mostly works anyway, as you can see with your experiment or the packages in AUR. note that if you don't want to compile from scratch, we also offer a pre-compiled static binary for the client nowadays (in .deb format, but you can just extract the binary from within).

Applying the proposed fix does make pxar compile correctly:

diff --git a/src/decoder/mod.rs b/src/decoder/mod.rs
index d62d030..84a5c24 100644
--- a/src/decoder/mod.rs
+++ b/src/decoder/mod.rs
@@ -35,7 +35,7 @@ fn scratch_buffer() -> &'static mut [u8] {
     unsafe {
         let ptr: *mut MaybeUninit<[u8; 4096]> = &raw mut SCRATCH_BUFFER;
         let ptr: &mut MaybeUninit<[u8; 4096]> = &mut *ptr;
-        &mut (*ptr.as_mut_ptr())[..]
+        &mut (&mut (*ptr.as_mut_ptr()))[..]
     }
 }

I would have opened a pull request but it seems like your system is gated to Proxmox employees, so I will leave it at your team discretion to apply this patch now or when it becomes necessary. Thank you for your hard work!

we use a patch-based workflow, see https://pve.proxmox.com/wiki/Developer_Documentation#Sending_Patches and https://pve.proxmox.com/wiki/Developer_Documentation#Software_License_and_Copyright - but this patch is probably trivial enough that we can just fold it in while attributing you, if you want that (just give us an identifier like First Last <mail> in that case )

 

[bbarik]

Thank you for the explanation of your processes. If you want, you can attribute the patch to BBArikL <bbarik@protonmail.com>.

 

[fabian]

https://git.proxmox.com/?p=pxar.git;a=commitdiff;h=957acc8917294a62d829d51e06cff9dc88845fb3