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

Minor wording fixes

Browse source
This commit is contained in:
Rohan Kumar 2022-02-03 18:31:13 -08:00
parent 89d8e99830
commit eb6d909539
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

@ -1,4 +1,4 @@
Supporting something I disagree with is generally easy to ignore. What I find more troubling is using the wrong reasons to support something I do agree with.
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 about how Free, Libre, and Open-Source Software (FLOSS) is necessary but insufficient to preserve user autonomy:
@ -12,9 +12,9 @@ One of the biggest parts of the Free and Open Source Software definitions is the
* Source code describes what a program is designed to do; it is unnecessary and insufficient to determine if what it actually does aligns with its intended design.
* Vulnerability discovery doesn't require source code.
I'd like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is *useless* from a security perspective, and I *do* think that source availability is required for user freedom. I'm arguing only that **source unavailability doesn't automatically imply insecurity**, and **source availability doesn't imply security**. It's possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn't typically rely on source code analysis.
I'd like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is _useless_ from a security perspective, and I _do_ think that source availability is required for user freedom. I'm arguing only that *source unavailability doesn't imply insecurity*, and *source availability doesn't imply security*. It's possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn't typically rely on source code analysis.
*PS: this stance is not absolute; I concede to several good counter-arguments at the bottom!*
(PS: this stance is not absolute; I concede to several good counter-arguments at the bottom!)
## How security fixes work

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

@ -7,7 +7,7 @@ outputs:
footnote_heading: Notes
title: "The right thing for the wrong reasons: FLOSS doesn't imply security"
---
Supporting something I disagree with is generally easy to ignore. What I find more troubling is using the wrong reasons to support something I do agree with.
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 <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.
@ -16,7 +16,7 @@ One of the biggest parts of the Free and Open Source Software definitions is the
- Source code describes what a program is designed to do; it is unnecessary and insufficient to determine if what it actually does aligns with its intended design.
- Vulnerability discovery doesn't require source code.
I'd like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is _useless_ from a security perspective, and I _do_ think that source availability is required for user freedom. I'm arguing only that **source unavailability doesn't automatically imply insecurity**, and **source availability doesn't imply security**. It's possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn't typically rely on source code analysis.
I'd like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is _useless_ from a security perspective, and I _do_ think that source availability is required for user freedom. I'm arguing only that **source unavailability doesn't imply insecurity**, and **source availability doesn't imply security**. It's possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn't typically rely on source code analysis.
_PS: this stance is not absolute; I concede to several good counter-arguments at the bottom!_