[PLUG] How do we know who to trust?

Ben Koenig techkoenig at gmail.com
Tue Oct 9 20:35:53 UTC 2018


Keith has a very good point that perfectly demonstrates the common
differences in the distros we use.

While the source code is the same, we all adhere to different ways of
reading, distributing, and documenting this code. Source packages are not
always stored in the same place, or downloaded from address.

bzip2 is a perfect example of this. A few months ago I noticed that the
official webpage for bzip2 had disappeared. The domain expired, and it is
now held by a new entity. bzip2 is still a huge part of the Linux platform,
however the official home of the code is now in question. Someone can throw
up a github repo and claim that they are preserving bzip2, but are they
really? Read the code and find out.

-Ben


On Mon, Oct 8, 2018 at 5:00 PM Keith Lofstrom <keithl at kl-ic.com> wrote:

> Trust but verify.  Enough eyes make all bugs shallow.
> ... and other proverbs.
>
> I just finished the not-very-interesting book "A Genius
> for Deception", about successful British efforts to fool
> the Germans during World Wars 1 and 2.   The message is
> that deception, making something appear different than it
> is, is much stronger than making something hard to see.
>
> An example was "dazzle paint" for ships.  Instead of camo,
> (attempting to make a ship blend into the seascape), paint
> it with swirling black and white stripes that make the
> ship appear to move in a different direction.  A submarine
> commander aiming a torpedo from a distance will miss more
> often.  The British employed abstract paint artists to
> design the patterns on model ships; cubism wins wars.
>
> ----
>
> This is germane to open source; variable names and
> subroutine titles do not specify what those objects do.
> Hiding exploits in machine code is difficult, hiding them
> in the source and the comments is easier.
>
> Scepticism improves security.  Sometimes you must decompile
> the binaries (yours or others) without knowledge of design
> intent, and see what they actually do.  Decades ago, in the
> dark days of closed source, I often decompiled/disassembled
> binaries, and often found flaws in the software design, or
> opportunities for improvement.
>
> A lot easier when the object code was 20 kilobytes rather
> than 200 megabytes, but the analysis tools are now more
> larger and more powerful as well.  So those become targets,
> too.
>
> The Unix/Linux philosophy of "little tools piped together"
> and the ease of "do-it-yourself" suggests that we can still
> combine little tools to make big powerful tools, one time
> ad hoc, and watch the text fly between them.  But we don't,
> and rely on huge development environments, which reduces
> effort, but concentrates vulnerabilities into a few large
> targets that can be attacked as groups with automation.
>
> The volunteer philosophy of "we should all contribute a
> little to our community" suggests that those of us who can
> should read little bits of code, so that all of us together
> read all of it in differently overlapping multiple passes.
>
> Those who can't read code anymore (like me) can write the
> documentation and draw the pretty pictures.  The quality
> of our shared output cannot exceed the quality of what
> we contribute as a cooperative volunteer community.
>
> Keith
>
> --
> Keith Lofstrom          keithl at keithl.com
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list