Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Nov 2019 13:28:04 -0600 (CST)
From: Bob Friesenhahn <>
To: Aditya Sirish Arunkumar Yelgundhalli <>
Subject: Re: Mitigating malicious packages in gnu/linux

The ideas I have seen posted on this topic thus far are about assuring 
correct provenance and that installed binaries are based on what the 
maintainer/developer intended.

The extreme focus on delivery mechanisms entirely ignores the fact 
that development source code is produced in environments which are not 
assured to be trustworthy (possibly sitting on hard drives for months 
or multiple years), and then stored in environments which may or may 
not be trustworthy (e.g. somewhere in a communal cloud).  This means 
that changes may be inserted into the source code without the 
developer/maintainer being aware.

There is also the implicit assumption that all developers and 
maintainers have the intention of being good and not intentionally 
inserting malicious code.  This is not always the case, particularly 
if a developer becomes deranged or disgruntled.  Not all developers 
are equally competent and sometimes a developer submits code with 
severe flaws.

Modern GNU/Linux systems have far too much executing code to 
reasonably secure.  Paring down the amount of executing code helps 
quite a lot with improving security.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.