S3: Add logging for silent SigV4 to SigV2 downgrade in presigned URLs

[alexandrebl]

Describe the bug

The AWS SDK for .NET silently downgrades presigned URLs from SigV4 to SigV2 when the requested expiration time exceeds the SigV4 maximum limit (7 days / 604,800 seconds) in regions that support SigV2. This automatic downgrade occurs without any notification to developers, creating several issues:

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

When generating presigned URLs with GetPreSignedURL():

1. Developer requests a presigned URL with expiration > 7 days
2. SDK automatically switches from SigV4 to SigV2 (in supported regions like us-east-1)
3. No logging or notification occurs
4. Developer receives a working URL but may be unaware of the security implications

Current Behavior

• Developers unknowingly use less secure SigV2 signatures
• No visibility into when signature version changes occur
• Difficult to audit security practices across applications

2. Debugging Challenges

• No indication why signature format differs between requests
• Troubleshooting signature-related issues becomes complex
• Inconsistent behavior between short and long expiration URLs

3. Missed Optimization Opportunities

• Developers aren't informed they could use more secure SigV4 with shorter expiration times
• No guidance on security best practices

Reproduction Steps

Applly expiration more than 7 days in a support regions

Possible Solution

Output logging when shfit from SigV4 to SigV2

Additional Information/Context

Expected Behavior

When generating presigned URLs with expiration times that exceed the SigV4 maximum limit (7 days), the SDK should:

1. Provide Transparent Logging

• Generate an informative log message when SigV4 automatically downgrades to SigV2
• Use appropriate log level (INFO) to ensure visibility without being intrusive
• Follow existing SDK logging patterns and conventions

2. Include Comprehensive Details

The log message should contain:

• Requested expiration time (in seconds) that triggered the downgrade
• SigV4 maximum limit (604,800 seconds) for context
• Affected bucket name for request identification
• Region/endpoint information where the downgrade occurred

3. Encourage Security Best Practices

• Provide actionable guidance suggesting shorter expiration times
• Explain the security benefits of using SigV4 over SigV2
• Help developers make informed decisions about their security posture

Example Expected Log Output

INFO: Presigned URL expiration (864000 seconds) exceeds SigV4 maximum (604800 seconds). Automatically using SigV2 for bucket 'my-bucket' in region 'us-east-1'. Consider reducing expiration time to use SigV4 for better security.

Example Scenario

var request = new GetPreSignedUrlRequest
{
    BucketName = "my-bucket",
    Key = "my-file.txt",
    Verb = HttpVerb.GET,
    Expires = DateTime.UtcNow.AddDays(10) // Exceeds SigV4 limit
};

var url = s3Client.GetPreSignedURL(request);
// Currently: Silent downgrade to SigV2
// Desired: Log message explaining the downgrade

Benefits
Improved Security Awareness: Developers understand when less secure signatures are used
Better Debugging: Clear visibility into signature version decisions
Security Best Practices: Actionable guidance to optimize security
Backward Compatibility: No breaking changes to existing functionality
Environment
SDK: AWS SDK for .NET
Service: Amazon S3
Component: Presigned URL generation
Affected Regions: SigV2-supported regions (primarily us-east-1)
Impact: Any application generating presigned URLs with expiration > 7 days
Labels



### AWS .NET SDK and/or Package version used

AWSSDK.S3 3.7.8.13

### Targeted .NET Platform

.Net 8, .Net 9

### Operating System and version

Cross Platform

[alexandrebl]

Issue #3964

[GarrettBeatty]

ive reviewed the left a couple of comments. thanks!