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
@mdb thanks for bringing this up. Not verifying the host keys does open up a potential man-in-the-middle vulnerability. I'd be happy to accept a PR that allows the resource to use access tokens to authenticate against HTTPS endpoints. Alternatively, the resource could accept a list of trusted SSH host keys. Looks like Github publishes their SSH host keys. That said I think I agree with you that access tokens seem a bit more robust.
@ljfranklin Thanks for the response! Your suggestion that the resource could accept a list of trusted SSH host keys is an interesting thought. However, I don't believe that solution addresses my concern in scenarios where modules are fetched from non-github.aaakk.us.kg sources where trusted host keys are less easy to obtain, such as a GitHub enterprise instance or a non-GitHub git server.
I can try and carve out some time to create a pull request but if you or any other users are inspired to take a stab, please don't feel compelled to wait for my pull request.
Thanks for your hard work on
terraform-resource
!In current implementation,
terraform-resource
supports the use of aprivate_key
as "An SSH key used to fetch modules."However, in many scenarios, a personal access token is arguably preferable, as it is the GitHub-recommended way to clone and does not require strict host key checking to be disabled.
Is it an option to consider supporting fetching modules with personal access tokens?
Thanks!
The text was updated successfully, but these errors were encountered: