Date: Fri, 6 Sep 2024 10:49:40 -0700 From: Enji Cooper <yaneurabeya@gmail.com> To: Alan Somers <asomers@FreeBSD.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: The case against C in the '20s (was "The Case for Rust (in any system)") Message-ID: <389B68AC-D6F5-47F9-BF01-D3A96A124AC7@gmail.com> In-Reply-To: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158 Content-Type: multipart/alternative; boundary="Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF" --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 5, 2024, at 11:09=E2=80=AFAM, Alan Somers <asomers@FreeBSD.org> = wrote: >=20 > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. >=20 > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. >=20 > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. >=20 > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: First off, I wholeheartedly agree and enjoy Rust, even though I also = acknowledge the immaturity of the Rust ecosystem. That being said=E2=80=A6 - I personally think us switching from standard C to modern C++ in = _certain_ components could also reduce the likelihood of these issues = occurring in the future. - Using Coverity or other SA tools like llvm scan-build (enabled in = CI/triggered by Phabricator?) might have also helped reduce the = likelihood of this occurring. I know I=E2=80=99m diverting the topic and this has probably been hashed = out already in the other threads, but I think it=E2=80=99s worth = considering as an alternative to binding Rust to FreeBSD (in Rust=E2=80=99= s current state/at its current maturity). Thanks for bringing up this topic (and others for discussing this at = length). This is something that=E2=80=99s been important as of late in = many security circles (mitigating/reducing "toe stubbing" on common = security issues). Cheers, -Enji PS I am having to deal with the whole rolling upgrade bootstrap problem = with lang/rust at $work again going from 1.7x.y to 1.80.1. It=E2=80=99s = a large resource drain having to rebuild lang/rust from scratch on = target systems because our builder nodes don=E2=80=99t support running = the prebuilt rust binaries :(. I acknowledge that=E2=80=99s a = =E2=80=9C$work=E2=80=9D problem, but=E2=80=A6 it=E2=80=99s something = that $work frankly doesn=E2=80=99t run into with other languages like = golang, Java, perl, python, etc.= --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><br><div><blockquote type=3D"cite"><div>On Sep 5, = 2024, at 11:09=E2=80=AFAM, Alan Somers <asomers@FreeBSD.org> = wrote:</div><br class=3D"Apple-interchange-newline"><div><div>By now I = expect that most of you have seen the long list of new<br>security = advisories that just came out. Strikingly, all were the<br>result = of memory handling errors. And none of them wouldn't = have<br>happened if their respective programs had been written in = a<br>memory-safe language.<br><br>In fact, of all the C bug fixes that = I've been involved with (as<br>either author or reviewer) since May, = about three quarters could've<br>been avoided just by using a better = language.<br><br>The real takeaway here is that C is no longer = sufficient for writing<br>high quality code in the 2020s. Everyone = needs to adapt their tools.<br>Programmers who don't will increasingly = come to resemble experimental<br>archaeologists, i.e. people who learn = flintknapping to "keep the<br>knowledge alive". Such people are = valuable, but definitely niche. I<br>for one don't want my career = to go in that trajectory.<br><br>To summarize, here's the list of this = week's security advisories, and<br>also some other recent C bug fixes of = my own involvement:<br></div></div></blockquote></div><br><div>First = off, I wholeheartedly agree and enjoy Rust, even though I also = acknowledge the immaturity of the Rust = ecosystem.</div><div><br></div><div>That being said=E2=80=A6</div><div>- = I personally think us switching from standard C to modern C++ in = _certain_ components could also reduce the likelihood of these issues = occurring in the future.</div><div>- U<span style=3D"caret-color: rgb(0, = 0, 0); color: rgb(0, 0, 0);">sing Coverity or other SA tools like llvm = scan-build (enabled in CI/triggered by Phabricator?) might have also = helped reduce the likelihood of this occurring.</span></div><div><span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);"><br></span></div><div><font color=3D"#000000">I know I=E2=80=99m = diverting the topic and this has probably been hashed out already in the = other threads, but I think it=E2=80=99s worth considering as an = alternative to binding Rust to FreeBSD (in Rust=E2=80=99s current = state/at its current maturity).</font></div><div><br></div><div>Thanks = for bringing up this topic (and others for discussing this at length). = This is something that=E2=80=99s been important as of late in many = security circles (mitigating/reducing "toe stubbing" on common security = issues).</div><div><br></div><div>Cheers,</div><div>-Enji</div><div><br></= div><div>PS I am having to deal with the whole rolling upgrade bootstrap = problem with lang/rust at $work again going from 1.7x.y to 1.80.1. = It=E2=80=99s a large resource drain having to rebuild lang/rust from = scratch on target systems because our builder nodes don=E2=80=99t = support running the prebuilt rust binaries :(. I acknowledge that=E2=80=99= s a =E2=80=9C$work=E2=80=9D problem, but=E2=80=A6 it=E2=80=99s something = that $work frankly doesn=E2=80=99t run into with other languages like = golang, Java, perl, python, etc.</div></body></html>= --Apple-Mail=_BA997240-B222-4E33-A6E4-25BCA9584BDF-- --Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmbbQLQACgkQGpE5DjPs NJiwvw/9G4tos0ditqxV4IXKzhV8LRNJr+WCcrUbN9tFVm12b7UEJH2LpsgAumUI xlaBcoUQBhG88+XRUIcYwwIHdxHzG6w5doQ+Fs7IlJZ85rDUAF+UutxftYPfy9PA QXgvqrXNLu4hu+ccRahIdHemB6T2UnicWZklDUYn8lcFAohTWko232avJxNw4Saf EIFWVplEtYF8xXdDRbqdsGEnzSATqANKV1fkUoMy7g4pdn8Er9271isk2R2WHKmB Ojcomwa+PMTIzPUwHQmoDefdPz61rP0nSdEvtbqh3cEmvgjhtHDuKPAbKq1//tpY fCBZZ3PdJIBM6XVpLNNkqZqsAezXbIYayn5XP97puBwC1OR8Jdi9R3xRhgwbsk+L Hofsr+bLNt7brq20spIfaDKLv4wQeU6geAF7jMZwd8gK67sIrvPsD3697eWbtera XzP1DEm0QlLWXIXy+CjTcC8pNfEWBDCCD1RlH3++yYeNAE/Ec+SCev6CXJg9M+12 8BYuBsLXfLo+LWcPkPu0UGtrBswl1HsSCRyTqgocC7ai6/SZA9YoGs7ZW7qUfKZZ mvZLKULFoPfohT5XAl7O/vS775tfN6rw17lFRvz5Lg8GdunyRFfl+OcLuEdAeIrs N7yugngNOALa7QJWUf0IkW4CT+AV3Q8J/Hd8H/rj3DiMKJi7kFc= =/Xfz -----END PGP SIGNATURE----- --Apple-Mail=_DBEBFE28-1E3D-4964-AA3E-C5D636C23158--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?389B68AC-D6F5-47F9-BF01-D3A96A124AC7>