MS windows and gnupg

[Robert J. Hansen]

On 9/17/2011 3:51 AM, M.R. wrote:
> I agree with you to some extent. I also happen to believe there are
> ways of tamper-resistant distribution of binaries that require the
> trust in the application provider and no one else; at least not
> someone else in the distribution channel. In addition, the ability
> of an average end-user to inspect the source is long gone.

This is why we have code signing.  Solved problem.  (You can argue that
GnuPG should distribute Authenticode-signed Windows binaries, and there
might be some merit to that argument: but the existing setup of MD5
hashes and GnuPG signatures posted for releases serves the same purpose.)

> I firmly believe this is quite different cattle of fish from
> ~application distribution~.

App distribution should be as an installer package appropriate for the
OS in question, which GnuPG does via NSIS.  Again, I don't see the problem.

Code distribution should be as a build environment that can be used
without undue effort by a modestly skilled programmer.  Again, I don't
see the problem with Autotools: I've yet to meet a Windows C/C++
developer who was unable to get MinGW set up, especially since MinGW
moved to a much more convenient installer model.

> This situation calls for simple shell scripts and not makefiles.

Oh, *hell* no.  Forgive my visceral reaction there, but whenever anyone
suggests going back to the bad old days I get a case of the flaming,
fiery heebie-jeebies.

Quoting John Calcote's excellent Autotools book:

    "Originally, configuration scripts were hand-coded shell
     scripts designed to set variables based on platform-specific
     characteristics.  They also allowed users to configure
     package options before running make.  This approach worked
     well for decades, but as the number of Linux distributions
     and custom Unix systems grew, the variety of features and
     installation and configuration options exploded, so it became
     very difficult to write a decent portable configuration
     script.  In fact, it was much more difficult to write a
     portable configuration script than it was to write Makefiles
     for a new project. ...

     In the early 1990s it was apparent to many open-source
     developers that project configuration would become painful
     if something wasn't done to ease the burden of writing
     massive shell scripts to manage configuration options.  The
     number of GNU project packages had grown to hundreds, and
     maintaining consistency between their separate build systems
     had become more time consuming than simply maintaining the
     code for these projects.  These problems had to be solved."

John is a dinosaur, in the best possible sense of the word: he remembers
the bad old days of "simple shell scripts" driving builds, and he
remembers how they turned into complex, unportable messes.  This was one
of the major driving forces behind the development of modern build
systems.  Let's not turn back the clock on progress.