an hour ago
how compliant is Tesla to GPL? Last time I checked things didn't look that good: https://sfconservancy.org/blog/2023/dec/21/tesla-no-source-c...
an hour ago
There is a HN discussion about it: https://news.ycombinator.com/item?id=38740239
12 hours ago
Such Open. Much Wow.
Tesla OpenSource committed on May 17
Showing 161 changed files with 13,686 additions and 1,939 deletions
Showing 5,586 changed files with 69,988 additions and 53,751 deletions12 hours ago
Oooh, kernel 5.4 This means that Teslas are vulnerable to every exploit discovered since, and anyone wanting to gain full access to the system has a multitude of tools to get there.
12 hours ago
No, this does not mean that. An old version can be fully patched (at least all upstream newer bugs fixed). Not saying it's the case here though...
9 hours ago
Not necessarily. The problem with clipboard audits using version number matching alone is they don't account for patching. The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it. For example, RHEL would be a Swiss cheese exploit magnet if they didn't regularly patch the heck out of every CVE for every component that came down the feed.
8 hours ago
> The proper way to do a vulnerability audit is by building and running code under test in sandboxed environment, and running each CVE-indicative sploit against it.
that doesn't work if there isn't an exploit
the other problem with both "clipboard audits" and your suggestion is that neither take into account the full context of the system. in general, a potential vulnerability might be significant, but in the context of your system, or tesla's, it might often be completely irrelevant. the converse is also true, and more problematic. it is very common for a potential vulnerability to be masked by other system characteristics.
the only way to do an audit is to do a comprehensive review of known potential vulnerabilities in the full context of your entire system stack and a well defined threat model requirement. otherwise, you will both underestimate some and overestimate many others. and you can't assume this is static; it must be repeated continuously because inputs and assumptions are constantly changing.
patch-and-pray is worse than a waste of time.