diff options
| -rw-r--r-- | subtitles.rst | 76 |
1 files changed, 75 insertions, 1 deletions
diff --git a/subtitles.rst b/subtitles.rst index 98ac76c..9c62ed7 100644 --- a/subtitles.rst +++ b/subtitles.rst @@ -27,7 +27,7 @@ Among the unsafe sources there are many different cases and while they do share some of the risks, they have different targets with different issues; for brevity the scope of this article is limited to the ones that mostly concern software developers: language specific package managers and -software distribution platforms like pypi, npm and rubygems etc. +software distribution platforms like PyPi, npm and rubygems etc. These platforms are extremely convenient both for the writers of libraries, who are enabled to publish their work with minor hassles, and for the people @@ -51,4 +51,78 @@ platform has a different policy with regards to updates, their backwards 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: +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 +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/ + +Contrast this with Debian, where everybody can contribute, but before +they are allowed full unsupervised access to the archive they have to +establish a relationship with the rest of the community, which includes +meeting other developers in real life, at the very least to get their +gpg keys signed. + +This doesn't prevent malicious people from introducing software, but +raises significantly the effort required to do so, and once caught +people can usually be much more effectively prevented from repeating it +than a simple ban on an online-only account can do. + +It is true that not every Debian maintainer actually does a full code +review of everything that they allow in the archive, and in some cases +it would be unreasonable to expect it, but in most cases they are at +least reasonably [] with the code to do at least bug triage, and most +importantly they are in an excellent position to establish a +relationship of mutual trust with the upstream authors. + +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 +QA efforts. + +Going back to the language specific distribution platforms, sometimes +even the people who manage the platform themselves can't be fully +trusted to do the right thing: I believe everybody in the field +remembers the `npm fiasco`_ where a lawyer letter requesting the removal +of a package started a series of events that resulted in potentially +breaking a huge amount of automated build systems. + +.. _`nmp fiasco`: https://lwn.net/Articles/681410/ + +Here some of the problems were caused by some technical policies that +caused the whole ecosystem to be especially vulnerable, but one big +issue was the fact that the managers of the npm platform are a private +entity with no oversight from the user community. + +Here not all distributions are equal, but contrast this with Debian, +where the distribution is managed by a community that is based on a +`social contract`_ and is governed via democratic procedures established +in its constitution_. + +.. _`social contract`: https://www.debian.org/social_contract +.. _constitution: https://www.debian.org/devel/constitution + +Additionally, + +So, shouln'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 +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 + authors; +* if possible, share that work by becoming ourself 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. |