I am back! =^/.^=

[ZZ-Cat]

Update, 2023-4-15 1736 Hrs NZST

Development of Version 1.1.0 is being tracked in #111

Warning

NO NEW FEATURES WILL BE ADDED TO CRSF FOR ARDUINO UNTIL STATIC CODE ANALYSIS AND CODE VULNERABILITY SCANNING IS SET-UP AND SUCCESSFULLY IMPLEMENTED ACROSS ALL PULL REQUESTS!

In the wake of the xzutils backdoor (of which was a supply chain attack), I am taking it upon myself to prioritise re-factoring my continuous integration automations. This re-factor will completely overhaul the existing code checks, and will include code vulnerability scanning and static code analysis in addition to build-testing CRSF for Arduino on compatible targets.

I am discontinuing the Arduino CI that I am currently using, because it has been nothing short of problematic and I am tired of it returning false errors and causing my builds to erroneously fail when CRSF for Arduino's code examples build in the latest Arduino IDE with impunity.

Ultimately, this means my continuous integrations will be consolidated into one continuous integration script called "Quality Control" and its badge will take the place of both my existing Arduino and PlatformIO build badges.

---

Original post

...even if I am a couple of days late.

Over the course of my hiatus, it has come to my attention that there is a need for me to prioritise my supply chain before I consider adding any new features. Currently, I don't have CI automations that scan Pull Requests for vulnerabilities nor conduct static analyses. My automations only perform compile tests on all compatible hardware. This makes CRSF for Arduino incredibly vulnerable to supply chain attacks. Because I am the only one that vets code coming into my project, and my own eyesight and knowledge can only go so far, and as the popularity of CRSF for Arduino grows, this increases the likelihood that I could be overwhelmed (IE Unable to manually vet everyone's Pull Requests, due to the sheer number of Pull Requests).

What do I mean by "supply chain attacks"?
I am talking about the type of attack where a rogue maintainer intentionally introduces malware into a code-base. I am talking about this type of attack. Where a bad actor can gain the trust of their fellow project maintainers (such as yours truly), create malicious code, commit that shit to the code-base over an arbitrary amount of time, and that creates dangerous levels of problems.

How does this affect CRSF for Arduino? Isn't your project "offline" and "hardware-based"?
This does not mean my project is immune to supply chain attacks.
I am highly discerning of people when they contribute to my project, and I do manually vet Pull Requests. However, as CRSF for Arduino grows in popularity, so does the number of third party Pull Requests coming into my project. Eventually, there will be a point where I simply cannot manually vet everyone, simply because there could be far too many Pull Requests coming in for one person to vet manually. IE I am implementing static code analysis and code vulnerability scanning this early on, to minimise my chances of becoming overwhelmed in this way.

I am currently researching a concept called "zero trust", and that concept is still very new to me.
However, this is what I understand of it so far...
Zero trust is, as the name suggests, means trust nobody. IE Assume all code coming from all third parties is vulnerable until proven otherwise.
This means things such as third party libraries, toolchains, extensions, continuous integration, continuous deployment etc.... all of it is vulnerable until proven otherwise. This could also be implied as "all contributors are bad... until proven otherwise", which has the potential to piss a lot of people off. However, the connotation of "all contributors are bad" that some people could associate with zero trust is false. A bad maintainer or contributor would:

• Ignore the vulnerabilities that exist in their project and/or pretend like those vulnerabilities don't exist.
• Lie about those vulnerabilities.
• Outright shun any Issues what contain bug reports or they would only pay attention to a select few bugs and almost never fix others what could be more pertinent.
• Pretend that their project is "perfect" and that there is "nothing wrong" with it at all, despite the evidence to the contrary.

As a responsible and ethical project maintainer, I share a common responsibility with other maintainers (of their own individual projects) to ensure their supply chains aren't shipping firmware or software that is full of vulnerabilities what could be exploited by bad actors. It would be incredibly irresponsible of me to continue working on CRSF for Arduino and simultaneously ignore any vulnerabilities that are (or could be) present.

The impact of the xz utils backdoor has highlighted the utmost importance of securing software and firmware right from the start of the supply chain all the way to where the software or firmware ships to the end user. Especially when I want to consider CRSF for Arduino being a high quality library.

Two final things I will say here, and I know this has become a bit of a wall-of-text here. However, necessary.
Anyway... I have noticed that the overwhelming majority of Arduino libraries are vulnerable or have their own known vulnerabilities. Therefore, it's all the more reason for me to implement the security measures I have stated in this announcement. CRSF for Arduino originally started up as my response to seeing an overwhelming amount of people using PWM receivers (that are often outdated/discontinued, are severely limited in range and latency, lack telemetry etc) in their RC projects.
The implementation of those receivers would make their projects woefully unreliable, and budding developers would erroneously blame themselves for their projects' lack of reliability.
CRSF for Arduino significantly improves not only the reliability of your RC project, but also improves upon and expands the possibilities of what your RC project is capable of.
Moving forward, this high reliability includes ensuring CRSF for Arduino is free from known vulnerabilities, and the ways I am doing this is through static code analysis (via PlatformIO) and code vulnerability scanning (via GitHub's own CI). This may not be a silver bullet. However, it is a step in the correct direction to ensuring that I am delivering a high quality and highly reliable product (because that's what CRSF for Arduino ultimately is) to you, my user-base.

...and lastly, with all this talk of vulnerabilities and security etc, why is the Serial Transmitter Interface prioritised above everything else?
Because this has come about before the xz utils backdoor (over in the Linux realm) was discovered.
Generally, when I prioritise a branch-and-pull-request combo or an issue-branch-pull-request combo, the chronological order plays a significant role. IE If I am already working on one branch, and another Issue or Pull Request comes up, my attention is primarily on the thing I am already working on before I turn my attention to the next Issue or Pull Request in my list.
It currently takes priority because over my hiatus, I have been heavily indecisive over which one took priority, given the fact I have told everyone that the Serial Transmitter Interface is the first priority when I come back from my hiatus.
So, I am upholding my word. Once the Serial Transmitter Interface is complete, NO NEW FEATURES WILL BE ADDED TO CRSF FOR ARDUINO UNTIL STATIC CODE ANALYSIS AND CODE VULNERABILITY SCANNING IS SET-UP AND SUCCESSFULLY IMPLEMENTED ACROSS ALL PULL REQUESTS!