 |
| (Image credit: Wikipedia.org) |
We've witnessed what happens when changes in source code to intentionally insert rogue code go unnoticed.
The example of how the NSA intentionally inserted weakened string constants into Elliptic Curve Cryptography lay hidden for several years, in fact, and was only exposed by a languishing open Red Hat trouble ticket. What was odd was how given the potential seriousness of the incident, no action was being taken to look at the source code and change it. As more comments appended to the ticket, the level of suspicion grew to the point of where NIST was forced to open up an investigation.
It was a potential public relations disaster in the making for them, as they pleaded being unaware of what the NSA had done. Immediately, the code base was opened up for public comment. The code has since received a thorough going over, particularly those merged diffs that sourced from the NSA and corrective action was taken.
But, this was a roadside billboard that should have alerted everyone in the FOSS Community to the realization that every corner of FOSS should be revisited for a thorough security review and vetting.
Code obfuscation should be a 'red flag' to anyone who has seen it. The first concern should be: Why is this code obfuscated? If there isn't good documentation giving a reason for doing so, then, it's time to dig in and find out what the code is or isn't doing, at the very least.
It is believed, however, relative to all FOSS code, little obfuscated code exists.
It would be most difficult to secret rogue code otherwise, as it must pass several levels of code review to reach final merge.
This is why it is an imperative that the FOSS Community become rigid and not deviate on the issue of Security Transparency.
Security Transparency assurance can only be guaranteed if and only if ALL source code is vetted independently by more than one project maintainer. Oversight must be maintained and all Linux Distribution binaries which don't provide accompanying Gnu General Public Licensed (GPL) source code should be rejected out of hand as not just a license violation but also a breach of Security Transparency.
That being the case, Linux Advocates is taking a position against the following software vendor sources of 'semi-open' code bases. They are:
- Google ChromeOS
- Google Chrome Browser
- Opera Browser
Linux Advocates categorically does not support using the above-listed products which include a mix of open source and proprietary code. There is an attendant heightened risk of exposure to cyber attack and exploitation when using any non-FOSS proprietary stack implementation on your computing device.
Enforce Security Transparency by insisting on using Linux with GPL open source code only. -- Dietrich
0 comments:
Post a Comment