Bit-baking with soda

Anyone that dealt with container engines came across go - a wonderful language, that was built to provide a right way of what C++ intended to do. The language itself is pretty straight forward and upstream poky support is given since ages... In the go world one would just run 1 2 go get github.com/foo/bar go build github.com/foo/bar and magically the go ecosystem would pull all the needed sources and build them into an executable. This is where the issues start... In the Openembedded world, one would have  one provider (aka recipe) for each dependency each recipe comes with a (remote) artifact (e.g. tarball, git repo, a.s.o.) which can be archived (so one can build the same software at a later point in time without any online connectivity) dedicated license information all this information is pretty useful when working is an environment (aka company) that has restrictions, such as reproducible builds license compliance security compliance (for instance no unpatched CVE) but whe...

Have you ever faced software security alerts in your embedded product or project? I did - several times. Mostly this had been going in the following way read an article or got a mail about the security issue checked (or may double-checked) the version actually used in the product is affected informed head of development (or head of security) that there is a problem in the software made several rounds of discussions and planning (which could take some time) included the fix, if there was one available did all the needed Q&A process deployed the fixed version kept the fingers crossed that software will be installed to most of the devices before anyone actually exploits the issue The chain of disaster already starts at the first bullet - it's far too late - the whole process usually takes at least a few days - days devices in the field might be exploitable - and who's responsible in the end? Take a guess - mostly it's you. Of course you can put yourself on...