diff options
| -rw-r--r-- | subtitles.rst | 31 |
1 files changed, 17 insertions, 14 deletions
diff --git a/subtitles.rst b/subtitles.rst index 9c62ed7..a9d32e7 100644 --- a/subtitles.rst +++ b/subtitles.rst @@ -1,8 +1,8 @@ When I was young, my parents taught me not to accept candy from strangers, unless they were present and approved of it, because there was a small risk of very bad things happening. -It was of course a simplicistic rule, but it had to be easy enough to follow -for somebody who wasn't proficient (yet) in the subleties of social +It was of course a simplistic rule, but it had to be easy enough to follow +for somebody who wasn't proficient (yet) in the subtleties of social interactions. One of the reasons why it worked well was that following it wasn't a big @@ -12,7 +12,7 @@ been a great one, the ones I could have at home were also good. Contrary to candy, offers of gratis software from random strangers are quite common: from suspicious looking websites to legit and professional looking -ones, to platforms that are explicitely designed to allow developers to +ones, to platforms that are explicitly designed to allow developers to publish their own software with little or no checks. Just like candy, there is also a source of trusted software in the Linux @@ -38,7 +38,7 @@ agree is a good thing. What I however believe is that getting code from such sources and using it *without carefully checking it* is even more risky than accepting candy from a -random stranger on the street in an unfamiliar neighborhood. +random stranger on the street in an unfamiliar neighbourhood. The risk aren't trivial: while you probably won't be taken as an hostage for ransom, your data could be, or your devices and the ones who run your @@ -52,14 +52,14 @@ compatibility and what can be expected in case an old version is found to have security issues. The very fact that everybody can publish anything on such platforms is -both their biggest strenght and their main source of vulnerability: +both their biggest strength and their main source of vulnerability: while most of the people who publish their libraries do so with good intentions, attacks have been described and publicly tested, such as the -fun typosquatting_ one (`archived url`_) that published harmless +fun `typo-squatting`_ one (`archived URL`_) that published harmless malicious code under common typos for famous libraries. -.. _typosquatting: http://incolumitas.com/2016/06/08/typosquatting-package-managers/ -.. _`archived url`: http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers/ +.. _`typo-squatting`: http://incolumitas.com/2016/06/08/typosquatting-package-managers/ +.. _`archived URL`: http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers/ Contrast this with Debian, where everybody can contribute, but before they are allowed full unsupervised access to the archive they have to @@ -83,7 +83,7 @@ Additionally, package maintainers don't work in isolation: a growing number of packages are being maintained by a team of people, and most importantly there are aspects that involve potentially the whole community, from the fact that new packages that enter the distribution -are publicy announced on a mailing list to the various distribution-wide +are publicity announced on a mailing list to the various distribution-wide QA efforts. Going back to the language specific distribution platforms, sometimes @@ -108,21 +108,24 @@ in its constitution_. .. _`social contract`: https://www.debian.org/social_contract .. _constitution: https://www.debian.org/devel/constitution -Additionally, +Additionally, the long history of the distribution model means that many +issues have already been met, the errors have already been done, and +there are established technical procedures to deal with them in a better +way. -So, shouln't we use language specific distribution platforms at all? +So, shouldn't we use language specific distribution platforms at all? No! As developers we aren't children, we are adults who have the skills to distinguish between safe and unsafe libraries just as well as the average distribution maintainer can do. What I believe we should do is stop treating them as a safe source that -can be used blindly and reserve that status to actual trustable sources +can be used blindly and reserve that status to actual trustful sources like Debian, falling back to the language specific platforms only when strictly needed, and in that case: * actually check carefully what we are using, both by reading the code - and by analyzing the developement and community practices of the + and by analysing the development and community practices of the authors; -* if possible, share that work by becoming ourself maintainers of that +* if possible, share that work by becoming ourselves maintainers of that library in our favourite distribution, to prevent duplication of effort and to give back to the community whose work we get advantage from. |