IoT Edge release branches use floating iot-identity-service main Cargo dependencies, breaking reproducible builds
Expected Behavior
IoT Edge release branches and pinned source revisions should be reproducible. I.e. building from a fixed commit or release should at least result in the same versions being pulled in.
This is especially relevant when using Yocto, e.g. https://github.com/Azure/meta-iotedge
So, also Cargo dependencies on Azure/iot-identity-service should be pinned to a release branch, tag, or exact commit appropriate for the IoT Edge release line. A pinned Azure/iotedge commit should not later break because Azure/iot-identity-service/main changed.
Current Behavior
This can and does currently happen.
IoT Edge Cargo manifests contain floating Git dependencies on Azure/iot-identity-service using branch = "main".
Examples:
This means a build of a pinned IoT Edge revision (or a pinned Yocto layer for that matter) can and will still fetch the current state of iot-identity-service/main during Cargo build.
Additional Information
In our Yocto/OpenEmbedded build, this recently broke because iot-identity-service/main now requires Cargo edition 2024 support, while the IoT Edge recipe/toolchain uses Rust/Cargo 1.82.0. But that only happened to surface this issue.
Fundamentally this breaks reproducability and becomes a big issue when a strict SBOM is required.
My suggestions would be to replace branch = "main" dependencies on Azure/iot-identity-service (at least for releases) fixed revisions, tags, or release branch references appropriate for that IoT Edge release line.
IoT Edge release branches use floating iot-identity-service main Cargo dependencies, breaking reproducible builds
Expected Behavior
IoT Edge release branches and pinned source revisions should be reproducible. I.e. building from a fixed commit or release should at least result in the same versions being pulled in.
This is especially relevant when using Yocto, e.g. https://github.com/Azure/meta-iotedge
So, also Cargo dependencies on Azure/iot-identity-service should be pinned to a release branch, tag, or exact commit appropriate for the IoT Edge release line. A pinned Azure/iotedge commit should not later break because Azure/iot-identity-service/main changed.
Current Behavior
This can and does currently happen.
IoT Edge Cargo manifests contain floating Git dependencies on Azure/iot-identity-service using branch = "main".
Examples:
main:
https://github.com/Azure/iotedge/blob/main/edgelet/Cargo.toml
Release example:
https://github.com/Azure/iotedge/blob/1.5.40/edgelet/iotedge/Cargo.toml
This means a build of a pinned IoT Edge revision (or a pinned Yocto layer for that matter) can and will still fetch the current state of iot-identity-service/main during Cargo build.
Additional Information
In our Yocto/OpenEmbedded build, this recently broke because iot-identity-service/main now requires Cargo edition 2024 support, while the IoT Edge recipe/toolchain uses Rust/Cargo 1.82.0. But that only happened to surface this issue.
Fundamentally this breaks reproducability and becomes a big issue when a strict SBOM is required.
My suggestions would be to replace branch = "main" dependencies on Azure/iot-identity-service (at least for releases) fixed revisions, tags, or release branch references appropriate for that IoT Edge release line.