[clug] How you know your Free or Open Source Software Project is doomed to FAIL

Paul Harvey csirac2 at gmail.com
Thu Jul 30 05:40:30 UTC 2015

On 30 July 2015 at 14:15, Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:
>> Surely https, warts and all, allows for at least slightly better
>> hygiene than blind faith in your physical network and http.
> If slightly better hygiene is running hot water over the scalpel instead
> of giving it a "bit of a wipe on your sleeve" - I'm not going to let you
> operate on me :)

Great analogy! But if only production systems were maintained with
this level of hygiene. I think we all agree that untrusted input is
untrusted input, whether delivered over https or not.

I'm just a little sceptical of how many production systems really are
that "pure". Perhaps I've spent too much time in the devops crowd,
where distro packages are actively avoided in preference to
virtualenv, perlbrew, checkinstall, etc. Don't get me wrong, you can
validate your sources if you do those things, but how many really do -
at every critical step, for hundreds of dependencies! Especially when
the shortest path is often to just give up, and pull random docker
images built by someone else who themselves barely understand all the
moving parts they've configured and built (from who knows how or
where) on your behalf. Often with no communication on what validation
or security choices/assumptions have been made beyond a Dockerfile
which if you look carefully, has a "RUN curl | sh" line in it...

In the face of all this, given a choice of blind faith in code
delivered over http or https, at least https makes some attempt to
ensure that we really have fetched something from some host that
really is who it says it is. Even if the Georgiev et. al. paper
implies otherwise...

Perhaps fundamentally, the means we have available to us for verifying
software provenance just doesn't scale once you venture outside of the
core/standard packages. And even then... So I've always liked the idea
of application whitelisting, it's just a shame there's no open source
kernel modules for Linux to do it (one day, I'll find the time). It
seems as if all the distro packaging ecosystems have nearly all the
signatures and shasums lying around already, but then there are those
that would argue that whitelisting *all* binaries contained in
packages signed by package maintainers wouldn't be enough hygiene

I've been working on populating a graph database based on debian
package metadata (and eventually, other sources) to figure out and
perhaps visualize just how many "points of trust" there actually is in
all the installed software on a standard application server...

But now I'm ranting :)


More information about the linux mailing list