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

Scott Ferguson scott.ferguson.clug at gmail.com
Thu Jul 30 03:37:06 UTC 2015

On 30/07/15 02:43, James Ring wrote:
> On Tue, Jul 28, 2015 at 10:56 PM, Scott Ferguson
> <scott.ferguson.clug at gmail.com> wrote:
>> On 29/07/15 12:01, Steve Walsh wrote:
>>> On 07/29/2015 01:55 AM, Scott Ferguson wrote:
>>>> A list of indicators that may interest some list readers:-
>>>> http://spot.livejournal.com/308370.html?nojs=1
>>>> <snip>
>>> I can't believe he missed
>>> * uses 'wget --no-check-certificate' to fetch a script from a https
>>> site,
>> I can understand a site using a self-signed certificate (choice) - in
>> which case the link should lead to a page with instructions on how to
>> verify the certificate, and add it to the certificate store. Given that
>> free SSL certs are available which are signed by CAs already in the
>> default store - I can't understand why someone would be so stupid. I'd
>> be very reluctant to use their code.
>>> and pipes directly to /bin/bash [ +200 points of FAIL ]
>> Words fail me.
> If you trust the site

Could you expand on how 'you' determine trust please?

> and you get the bytes via SSL and the
> certificate checks out, how is this different from downloading and
> running some binary from, say, Debian archives?

* The debian packages are cryptographically signed.

apt checks the signatures of downloaded debian packages
man apt-secure:-

"apt contains code that does signature checking of the Release file for
all archives. This ensures that packages in the archive can't be
modified by people who have no access to the Release file signing key.

If a package comes from a archive without a signature, or with a
signature that apt does not have a key for, that package is considered
untrusted, and [sic attempting to] installing it will result in a big
warning.  apt-get will currently only warn for unsigned archives; future
releases might force all sources to be verified before downloading
packages from them."

The chain of trust from an apt archive to the end user is made up of
several steps.  apt-secure is the last step in this chain; trusting an
archive does not mean that you trust its packages not to contain
malicious code, but means that you trust the archive maintainer. It's
the archive maintainer's responsibility to ensure that the archive's
integrity is preserved."

I recommend you read the man file yourself so I can avoid re-inventing
the wheel.

* You can just download the package first and inspect it to see what it
will do:-

apt-get -d install $somepackage
dpkg -c /var/cache/apt/archives/$somepackage | more

* You can check the signature if you have debsig-verify and
debian-keyring installed:-

debsign-verify $path/$somepackage

* You can view the source of a debian package.

* You can build a debian package for yourself from the debian source.

* If the debian package has an upstream source you can patch that source
with the debian variations and build it yourself as a debian package -
or skip the debianisation patch and just build it yourself as a
non-debian package.

* In a growing number of instances you can do a reproducible
(deterministic) build of a debian package and prove that the version you
build from the debian source is identical to the binary available from
the debian repository:-

You can qualify your trust in a debian package, downloading and
installing some binary from some random site does not automatically give
you the same level of trust qualification.

Note that anyone can get a website can get an SSL certificate - it does
not automatically mean that the site is to be trusted, or that the
binary from that site is to be trusted (only that private key for the
certificates CSR resides on the same server).

> Regards,
> James
> .

I hope that helps

Kind regards

More information about the linux mailing list