The Update Canary 🐦

[pinkforest]

Following-up from: #227 I think this deserves it's own issue.

I was thinking of the general problem around keeping things Up-to-Date (tm)

I don't think distros / packaging management will help us much here given their fragmentation, current state and realities (tm)

Distros and packaging systems generally work in shared objects basis across the host system being the legacy model where as Rust 🦀 is statically linked and is ill suited to that.

I would love to explain it - in depth - but I would prefer and this deserves - a separate blog post at some stage about that alone later -

However -

How many people realise (if they are lucky) that openssh is out of date and not the latest fanciest of 8.2.p1 that ubuntu LTS 20.04 e.g. provides that we require.

Or how many people realise (or more importantly don't realize) the static OpenSSL (or other -like) library (whether vendored or pulled from outdated system dependency) they staticly linked into binaries we either distributed or they built themselves suddenly discovered a security vulnerability - I have strong doubts packaging system helps us here especially in addition if we don't control the inputs end-to-end and where the whole package management is so fragmented as it's today.

It's my pet issue to blog about e.g. openssl-src is my regular on how it manages to stay out of way (in both good and bad)
https://missmissm.medium.com/that-vendored-openssl-most-of-us-rely-on-probably-needs-a-patch-aae8fea5160f

fyi OpenSSL C-library had a recent vulnerability... and nobody knows how many existing binaries there are that are affected from that vulnerability.. to me that is a bit of a concern

There is also this by colleague on wider on-point analysis: https://hackmd.io/cgaGMQAFQBGprGyFO3ofvg

This is why cargo-auditable was born and ended up as an rfc: rust-lang/rfcs#2801

In addition to wiring cargo-auditable into our builds -

I think one of the directions here would be to have "a canary" in the CLI itself that warns if the update has not been checked or alternatively if the client talks to the server / nodes and the node / client version difference is too high or something around that.

The CLI could read it's own auditable data and figure out if the dependant statically linked components from that list are out-of-date / have gained advisories and advise about using radup to run radup update

Thoughts ?

In K8S the client / server version difference is pretty streamed but it can be simpler e.g. a simple canary as above.

[adaszko]

It's my pet issue to blog about e.g. openssl-src is my regular on how it manages to stay out of way (in both good and bad) https://missmissm.medium.com/that-vendored-openssl-most-of-us-rely-on-probably-needs-a-patch-aae8fea5160f

I've posted a comment on the original blog post: https://medium.com/@adaszko_77765/hi-correct-if-im-misunderstanding-you-re-stating-here-that-the-exact-picked-version-of-openssl-feab906dc0d6

It's not to discourage cargo-auditable approach by any means — it's still a great and useful tool. It's just to paint a more accurate picture of the situation with OpenSSL.