fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-13 01:02:10 +00:00
Code Issues Projects Releases Wiki Activity

Add a summarizing statement to conclusion

Browse source 
Explicity state that security is determined through study, regardless of
source model.

Also fix some whitespace.
This commit is contained in:
Rohan Kumar 2022-02-04 11:16:05 -08:00
parent 77d003a640
commit 42c87d6970
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
2 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/posts/floss-security.gmi
View file

@ -200,7 +200,7 @@ Likewise, don't assume software is safer than proprietary alternatives just beca
=> https://madaidans-insecurities.github.io/linux.html Linux (In)security
I'm *not* arguing that source code is useless from a security perspective. Releasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. My main point is that source unavailability does not imply insecurity, and source availability does not imply security. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don't need to rely on bad ones.
I'm *not* arguing that source code is useless from a security perspective. Releasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. My main point is that source unavailability does not imply insecurity, and source availability does not imply security. No matter the source model, we should evaluate software security through *study* rather than development model. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don't need to rely on bad ones.
¹ Writing an alternative or re-implementation doesn't require access to the original's source code, as is evidenced by a plethora of clean-room re-implementations of existing software written to circumvent the need to comply with license terms.

2
content/posts/floss-security.md
View file

@ -163,7 +163,7 @@ I've gone over some examples of how analyzing a software's security properties n
Likewise, don't assume software is safer than proprietary alternatives just because its source is visible. There are lots of great reasons to switch from macOS or Windows to Linux (it's been my main OS for years), but security is [low on that list](https://madaidans-insecurities.github.io/linux.html).
I'm _not_ arguing that source code is useless from a security perspective. Releasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. My main point is that source unavailability does not imply insecurity, and source availability does not imply security. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don't need to rely on bad ones.
I'm _not_ arguing that source code is useless from a security perspective. Releasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. My main point is that source unavailability does not imply insecurity, and source availability does not imply security. No matter the source model, we should evaluate software security through *study* rather than development model. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don't need to rely on bad ones.
[^1]: Writing an alternative or re-implementation doesn't require access to the original's source code, as is evidenced by a plethora of clean-room re-implementations of existing software written to circumvent the need to comply with license terms.