[feature] conan upload should enforce strict overwrite control to prevent package revision ambiguity and enable reliable traceability

[AaronKonishi]

What is your suggestion?

Description:

In production environments with strict version control and traceability requirements, the ability to distinguish between different builds of the same source code is critical. The current conan upload
behavior allows uploading new package revisions (package_revisions) even when the package_id and recipe_revisions remain unchanged, creating ambiguity that makes it impossible to determine whether a new
package revision represents:

• A rebuild of the same source code at a different time (e.g., CI infrastructure rebuild, flaky test retry)
• A rebuild of different source code (e.g., actual code changes, dependency updates, environment variations)

This ambiguity breaks traceability and makes it impossible to reliably reproduce issues or track which source code was actually used in a specific deployment.

Problem Scenario:

Consider the following production workflow:

1. Initial Upload (Monday 9:00 AM):
   - Package: host-service/1.1.4@application/mk
   - Platform: mr536, Build Type: Release
   - Recipe Revision: abc123
   - Package ID: sha256::XYZ111 (based on settings)
   - Package Revision: rev001
   - Source: Commit A1B2C3D
   - Upload Success
2. Attempted Re-upload (Monday 2:00 PM):
   - Same Package: host-service/1.1.4@application/mk
   - Same Platform: mr536, Build Type: Release
   - Same Recipe Revision: abc123
   - Same Package ID: sha256::XYZ111 (identical settings)
   - New Package Revision: rev002
   - Source: Same Commit A1B2C3D (rebuild due to CI retry)
   - Current Behavior: Upload succeeds, creating rev002
3. Critical Issue:
   - Both rev001 and rev002 appear to be valid packages for the same configuration
   - There is no way to determine which revision corresponds to which actual source code
   - If rev002 was accidentally built from a different commit (e.g., D4E5F6G), this discrepancy goes undetected
   - Debugging issues becomes impossible: "Which package revision was actually deployed? Was it built from the correct commit?"

Current Behavior:

The conan upload command allows uploading new package revisions even when the package already exists with the same package_id and recipe_revisions:

conan upload -r artifactory host-service/1.1.4@application/mk

This command:

• ✗ Does not check if a package with the same package_id already exists
• ✗ Allows creating new package_revisions without any warning or confirmation
• ✗ Does not provide a flag to prevent this behavior
• ✗ Creates ambiguity that cannot be resolved after upload

Expected Behavior:

The conan upload command should:

1. Add a --force or --allow-overwrite flag (default: FALSE)

Default: fail if package_id already exists

conan upload -r artifactory pkg/version@user/channel

Error: Package with package_id 'sha256::XYZ111' already exists. Use --force to allow overwrite.

Explicitly allow creating new package revision

conan upload -r artifactory pkg/version@user/channel --force
2. Provide a --strict mode (recommended for production)
conan upload -r artifactory pkg/version@user/channel --strict

Fails if ANY combination of [recipe_revision, package_id] exists

3. Add a --check-only flag for dry-run validation
   conan upload -r artifactory pkg/version@user/channel --check-only

Returns exit code 1 if package would be overwritten

Without actually uploading

4. Display detailed information when overwrite is detected
   ERROR: Package already exists in remote repository:

• Recipe: host-service/1.1.4@application/mk
• Recipe Revision: abc123
• Package ID: sha256::XYZ111
• Existing Package Revision: rev001
• Existing Upload Date: 2025-12-25 09:00:00

To upload anyway and create a new package revision, use --force flag.
To prevent accidental overwrites, omit the --force flag (default behavior).

Impact and Risks:

1. Traceability Loss (CRITICAL):
   - Cannot determine which source code corresponds to which package revision
   - Impossible to reproduce production bugs with confidence
   - Cannot verify that deployed binaries match expected source code
2. CI/CD Reliability:
   - Automatic retries may create duplicate package revisions
   - Flaky infrastructure issues generate unnecessary package revisions
   - Cannot distinguish between intentional rebuilds and accidental duplicates
3. Security and Compliance:
   - Cannot guarantee which code was actually deployed
   - Audit trails become unreliable
   - Violates traceability requirements in regulated industries (automotive, medical, aerospace)
4. Storage and Performance:
   - Accumulation of redundant package revisions
   - Increased repository size and backup costs
   - Slower package queries and downloads

Use Cases:

Use Case 1: Production Environment (Strict Mode)

CI/CD pipeline - should fail if package already exists

conan upload -r artifactory pkg/version@user/channel --strict

Prevents accidental overwrites and duplicate revisions

Ensures traceability between source code and binaries

Use Case 2: Development/Testing (Allow Overwrites)

Development rebuild - explicitly allow overwrite

conan upload -r artifactory pkg/version@user/channel --force

Allows rapid iteration during development

Requires explicit intent to overwrite existing packages

Use Case 3: Validation Before Upload

Check if upload would cause conflicts

conan upload -r artifactory pkg/version@user/channel --check-only
if [ $? -eq 0 ]; then
echo "Safe to upload"
conan upload -r artifactory pkg/version@user/channel
else
echo "Package already exists, aborting"
exit 1
fi

Suggested Implementation:

1. Add new command-line arguments:
   - --force / --allow-overwrite: Explicitly allow overwriting existing package_ids
   - --strict: Fail if any matching package_id exists (default behavior for production)
   - --check-only: Validate without actually uploading
2. Remote repository check before upload:

Pseudo-code for upload logic

existing_packages = conan_search_remote(package_reference, package_id)
if existing_packages and not args.force:
if args.strict:
logger.error(f"Package with package_id '{package_id}' already exists")
return 1
else:
# Ask for confirmation
if not confirm("Package exists. Overwrite?"):
return 1
3. Metadata enhancement:
- Store build timestamp in package metadata
- Store source commit hash in package metadata (if available)
- Display this information in conan search output
4. Backward compatibility:
- Make --strict the default for new Conan versions (3.0+)
- Provide migration guide for existing workflows
- Allow configuration file setting: [upload] strict=True

Recommended Default Behavior (Conan 3.0):

Default: strict mode (fail on existing package_id)
Override: --force flag to allow overwrites

This aligns with security best practices: secure by default, explicit intent for risky operations.

Additional Recommendations:

1. Add conan diff command:
   conan diff pkg/version@user/channel:rev1 pkg/version@user/channel:rev2

Show differences between two package revisions

Helps identify if revisions are from same or different source

2. Enhanced package metadata:
   - Require or auto-detect git commit hash
   - Store build environment information (compiler version, toolchain versions)
   - Make this metadata queryable via conan search
3. Configuration option:

~/.conan2/global.conf

upload_strict_mode=True
upload_default_force=False

Environment:

• Conan Version: 2.x / 3.0 (proposed)
• Impact: All platforms and use cases
• Priority: CRITICAL for production environments with traceability requirements

Conclusion:

The current behavior of conan upload creates a fundamental traceability problem that undermines confidence in package management for critical systems. By implementing strict overwrite control with opt-in
--force functionality, Conan can provide the reliability and auditability required for enterprise-grade C/C++ development while maintaining flexibility for development workflows.

This feature is essential for teams practicing DevOps, CI/CD, and continuous delivery where the ability to trace deployed binaries back to exact source code is not just a convenience—it's a requirement.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide