Reimplement in Another Language

[aws]

Reimplement in Another Language

+1 For golang

[arianvp]

curl ships with a full Sigv4 implementation. So any language that supports libcurl seems to be fine

[LordAlfredo]

Options considered thus far:

• C & C++ have high build/support complexity, particularly if Windows instances are supported in the future
• Java, Scala, etc's need for a JVM means either huge latency for startup or needing a background JVM running at all times
• Python, Ruby, and similar languages have some degree of interpreter startup time, but more annoyingly (as with all dynamic langauges) require ensuring dependency availability (eg, crypto libraries) when private subnets may not have access to standard repositories
• Golang has the advantages of static compilation without the build complexity of C/C++
• Due to need for minimum-version across various AMIs and historical precedent, Perl is considered too insecure an option for an sshd dependency

Current leading considerations:

• While Python would be a good choice, the issue of supporting private subnets still stands - if standard repositories are not available we cannot guarantee dependency availability. Amazon will consider this facet internally. Similarly, the concern of interpreter performance/time still stands but may be assuaged through testing.
• Golang would require some build complexity to support standard AMIs (Amazon Linux, Ubuntu, RHEL, etc), but thanks to static compilation would avoid many of the concerns with Python.

For anyone watching this repository: any other particular opinions on language?

[LordAlfredo]

Secondary-but-manageable concern with Python: CentOS adds a particular concern due to how deeply baked into the system it is. We would need to earliest still-supported CentOS AMI as a guide for picking a Python version and ensure it is not exceeded. While less likely to break, we would also need to ensure language compatibility with newer Python versions that may be available on other AMIs.

[LordAlfredo]

Third concern that makes Python a non-option: The eic_harvest_hostkeys script needs to make a Sigv4 call to the EC2 Instance Connect Service. Currently this is written in a hard shell implementation. Part of the draw of re-implementing in another language is the ability to use native language SDKs vended by AWS.

There is no official release of the AWS CLI/Python SDKs for RHEL and its sibling distributions - they instead expect installation through Pip. This would mean a package install for those distros would need to invoke Pip install, which is not something a package installation process should do (particularly as that also means installing and configuring Pip itself). We could simply (re-)write an implementation of AWS Sigv4, but that would mean needing to make breaking changes if and when AWS ever releases a new signature algorithm (versus simply updating SDK).

[ferricoxide]

For consistency's sake, I'd probably say "go with however AWS CLIv2 is implemented".

That said: if you implement in Go, you'll need to ensure that your releases include binary-packagings for various platforms. Many Go-based packages can be a righteous pain to compile on isolated networks or non-public AWS-partitions (and supporting such networks' security-demands are where InstanceConnect and similar solutions are really nice options to have available).