Ultimately, they selected CockroachDB, as described in "RFD 110: CockroachDB for the control plane database" [1]. Now, published just yesterday, "RDD 508: Whither CockroachDB?" [2] discusses what to do in light of Cockroach going proprietary.
I'm getting increasingly nervous about baking in assumptions on software that doesn't have a strong guarantee of staying open source. Foundations like the CNCF help here, where projects are assigned ownership to the foundation.
There is a middle ground though. It's not practical to only build on top of foundation-owned software. So a metric I use these days is to consider the cost of replacement or fork maintenance, combined with how likely I think a license change would be, as part of evaluation.
Even with the Apache foundation therenis no guarantee they’ll be maintainers for support and active development. Only guarantee is a company that is profitable but doesn’t want more money…
Maybe people should be getting nervous that the whole flower power mentality of FOSS doesn't really scale when there are bills to pay, and families to nurture.
Processing [1] is a language (/ ecosystem and IDE) that serves a lot of creative use cases, particularly creative graphics projects. Arduino re-used the GUI of the Processing IDE to build the Arduino IDE, which is called out on the startup splash screen for the latter, and is probably what you're thinking of.
An aside, I don't use Processing very often but every time I've dipped into it I've found it simple and enjoyable.
I prefer using hardware tokens (in most cases a PKCS#11 smart card) because it means that even with a forwarded SSH agent, every request to use my private key requires a PIN on my client which is verified by the isolated cryptographic processor. It's impossible for my private key to leave that card and get cached anywhere else. While I haven't enabled it on my Yubikey I understand they can do similar.
The downside is that compatibility in edge cases, while much better than I'd expect, is still not perfect. In particular Windows support outside of Putty gets challenging.
The RCE is related to ssh-agent's support for PKCS#11, so, yeah you are right this is a valid method to prevent key access or theft via the agent (I also have to approve every use of my PK), but in this case it's not protecting against the RCE, and the workaround in the meantime is to disable PKCS#11 `ssh-agent -P ''`
The other downside is it's much harder to do bulk operations against a fleet. It's not reasonable to enter a PIN for each access when you need to push something to 1000 nodes. 100 nodes is probably ok, but not great.
