Is your feature request related to a problem? Please describe.
Fluent Bit currently contains a small number of SHA-1 and MD5 code paths.
Some MD5 usages are required for interoperability with external services (for example, cloud-provider APIs that mandate MD5-based integrity checks) and therefore cannot be removed without breaking compatibility.
The remaining SHA-1 usage appears to be limited primarily to legacy operations such as X.509 certificate fingerprint generation (for example, via X509_digest) rather than security-sensitive operations like authentication, digital signatures, or TLS certificate validation.
Although these usages do not present an immediate security vulnerability, both SHA-1 and MD5 are considered legacy cryptographic algorithms and are increasingly flagged by security scanners, compliance frameworks, and FIPS-oriented environments. Their presence often results in unnecessary compliance findings even when they are only used for non-security purposes.
Describe the solution you'd like
- Phase1: all new functionality should use SHA-256 (or stronger algorithms where appropriate)
- Phase2: the existing SHA-1/MD5 implementation is retained only for backward compatibility with warning messages like "SHA1/MD5 is going to deprecate in the future"
- Phase3: evaluate and enable support for newer cloud provider checksum mechanisms: Newer cloud-provider APIs that can use stronger checksums (e.g., SHA-256 for AWS S3, CRC64 for Azure Blob Storage)
- Phase4: remove SHA-1 and MD5 implementations from Fluent Bit completely when all external dependencies have officially deprecated them.
This would reduce compliance findings while keeping Fluent Bit fully compatible with existing integrations.
Is your feature request related to a problem? Please describe.
Fluent Bit currently contains a small number of SHA-1 and MD5 code paths.
Some MD5 usages are required for interoperability with external services (for example, cloud-provider APIs that mandate MD5-based integrity checks) and therefore cannot be removed without breaking compatibility.
The remaining SHA-1 usage appears to be limited primarily to legacy operations such as X.509 certificate fingerprint generation (for example, via X509_digest) rather than security-sensitive operations like authentication, digital signatures, or TLS certificate validation.
Although these usages do not present an immediate security vulnerability, both SHA-1 and MD5 are considered legacy cryptographic algorithms and are increasingly flagged by security scanners, compliance frameworks, and FIPS-oriented environments. Their presence often results in unnecessary compliance findings even when they are only used for non-security purposes.
Describe the solution you'd like
This would reduce compliance findings while keeping Fluent Bit fully compatible with existing integrations.