fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-10 00:12:09 +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

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

@ -67,8 +67,8 @@ Analyzing every relevant program and library's source code would have taken me m
```
strace name-of-program program-args 2>&1 \
| rg '^([a-z_]*)\(.*' --replace '$1' \
| sort | uniq
| rg '^([a-z_]*)\(.*' --replace '$1' \
| sort | uniq
```
This also extends to determining how programs utilize the network: packet analyzers like Wireshark can determine when a program connects to the network, and where it connects.
@ -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.

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

@ -9,7 +9,7 @@ title: "The right thing for the wrong reasons: FLOSS doesn't imply security"
---
I find it easy to handle views different from my own. I feel more troubled when I see people agree with me for the wrong reasons.
It's no secret that I'm a passionate supporter of software freedom: I've written two posts ([one](./../../../2021/01/27/whatsapp-and-the-domestication-of-users.html), [two](./../../../2021/02/23/keeping-platforms-open.html)) about how Free, Libre, and Open-Source software (<abbr title="Free, Libre, and Open-Source Software">FLOSS</abbr>) is necessary but insufficient to preserve user autonomy. After two posts spanning over 5000 words, I need to add some nuance.
It's no secret that I'm a passionate supporter of software freedom: I've written two posts ([one](./../../../2021/01/27/whatsapp-and-the-domestication-of-users.html), [two](./../../../2021/02/23/keeping-platforms-open.html)) about how Free, Libre, and Open-Source software (<abbr title="Free, Libre, and Open-Source Software">FLOSS</abbr>) is necessary but insufficient to preserve user autonomy. After two posts spanning over 5000 words, I need to add some nuance.
One of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. I agree that such access is essential; however, far too many people support source availability for the _wrong_ reasons. One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy. Although security through obscurity is certainly not a robust measure, this claim has two issues:
@ -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.