<story><title>Some thoughts on security after ten years of Qmail 1.0</title><url>https://blog.acolyer.org/2018/01/17/some-thoughts-on-security-after-ten-years-of-qmail-1-0/</url></story><parent_chain></parent_chain><comment><author>pilif</author><text>Something to keep in mind with regards to qmail is that it&amp;#x27;s extremely feature-poor and it never got features beyond its initial design goal.&lt;p&gt;This makes it much easier to keep the bugs out, to the point that making software under such constraints is much more similar to traditional construction projects.&lt;p&gt;I mean: Nobody ever tells you after you have built a bridge that they are now going to upgrade gravity to gravity 2.0 with 100% more pull. And nobody will ever tell you that your bridge will now get a shopping mall in the middle of it where people can purchase products of their favorite brands.&lt;p&gt;Software starts to break down when it has to be taken above initial design constraints and when there is not enough time to rewrite subsystems (or all of it) but instead when you have to make the abstractions leaky and compromise.&lt;p&gt;But back to qmail:&lt;p&gt;qmail itself is so feature-poor that traditionally, nobody was and is actually running qmail. Instead everybody is running &amp;quot;qmail&amp;quot; which is qmail plus some patches. Sometimes home-grown, sometimes taken from third parties.&lt;p&gt;But more often than not they are unmaintained and very far removed from the high quality standards of the underlying software.&lt;p&gt;This is the downside. Yes. You have a bug-free core that totally meets its designers (limited) use-case, but in reality nobody is actually running that.</text></comment>
<story><title>Some thoughts on security after ten years of Qmail 1.0</title><url>https://blog.acolyer.org/2018/01/17/some-thoughts-on-security-after-ten-years-of-qmail-1-0/</url></story><parent_chain></parent_chain><comment><author>diafygi</author><text>As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_.&lt;p&gt;(1996) &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.fastcompany.com&amp;#x2F;28121&amp;#x2F;they-write-right-stuff&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.fastcompany.com&amp;#x2F;28121&amp;#x2F;they-write-right-stuff&lt;/a&gt;&lt;p&gt;&amp;gt; It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.&lt;p&gt;&amp;gt; The process isn’t even rocket science. Its standard practice in almost every engineering discipline except software engineering.&lt;p&gt;The problem is consequences. We had centuries of people dying in bridge collapses before we got our shit together and started prioritizing safety in civil engineering (i.e. engineers and managers going to prison if they don&amp;#x27;t).&lt;p&gt;The same will be true for software. As more people get harmed by thrown together software (e.g. mass panic in Hawaii, state psychological exploitation on social media), we&amp;#x27;ll start regulating it like other engineering fields.&lt;p&gt;As a former chemical engineer, I welcome this transition, but I realize it will likely also take centuries of hard lessons.</text></comment>