You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Practitioners currently have the ability to create certificates via the tls_self_signed_certificate and tls_locally_signed_certificate resources which have a validity period of no time in the future. Recent changes to the validity_period_hours attribute have enabling configuration validation that the value is an integer that is 0 and greater, however the 0 value likely has limited usage in real world configurations. It is unclear if the provider should warn practitioners about the situation so they can avoid it, or if there are enough valid use cases that a 0 value should continue to work without feedback. Practitioners would not be able to avoid the warning diagnostic output since there are no options in CLI flags or the configuration language to disable it.
Proposal
Consider updating the attribute validation of the validity_period_hours attribute on the tls_self_signed_certificate and tls_locally_signed_certificate resources to return a warning diagnostic if its value is known and 0.
How much impact is this issue causing?
Low
Additional Information
This change may be best suited for a future major version release or just consider updating the attribute validation to be 1 or greater for that configuration.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Terraform CLI and Provider Versions
v1.x / 4.x
Use Cases or Problem Statement
Practitioners currently have the ability to create certificates via the
tls_self_signed_certificate
andtls_locally_signed_certificate
resources which have a validity period of no time in the future. Recent changes to thevalidity_period_hours
attribute have enabling configuration validation that the value is an integer that is0
and greater, however the0
value likely has limited usage in real world configurations. It is unclear if the provider should warn practitioners about the situation so they can avoid it, or if there are enough valid use cases that a0
value should continue to work without feedback. Practitioners would not be able to avoid the warning diagnostic output since there are no options in CLI flags or the configuration language to disable it.Proposal
Consider updating the attribute validation of the
validity_period_hours
attribute on thetls_self_signed_certificate
andtls_locally_signed_certificate
resources to return a warning diagnostic if its value is known and0
.How much impact is this issue causing?
Low
Additional Information
This change may be best suited for a future major version release or just consider updating the attribute validation to be
1
or greater for that configuration.Code of Conduct
The text was updated successfully, but these errors were encountered: