Simon Joseffson <si...@joseffson.org> wrote:
If the justification for those modifications are disagreement with upstream about how GnuPG should behave with regard to the wire protocol, it becomes even more clear to me that we are talking about a fork.
The disagreements are not so much about which wire formats should be supported, just which ones should be generated by default. Patching over upstream defaults is common practice for most Linux distros.
What is GnuPG? Upstreams GnuPG or Debian's GnuPG or Fedora's GnuPG or Hooty's GnuPG? This situation is bad both for Debian and GnuPG, and to the wider PGP eco-system.
I’m sympathetic in principle, however the current status in practice is that we already have “Debian’s GnuPG, “Fedora’s GnuPG” etc, and the immediate goal of FreePG is to reduce this number, so that users who install one distribution’s GnuPG can be reasonably confident that it will behave the same as another distribution’s. If it was practical to ship unmodified, or barely modified, upstream then distributions would already be doing it, and FreePG would not exist.
I do realise that this sounds like a “now we have 14 competing standards” scenario, but there are enough distros seriously considering alignment with FreePG that I believe the effort is useful on balance.
If there is commitment to provide long-term support for FreePG, how about uploading that as a separate package in Debian?
To be clear, FreePG requires no more support than the various distros are already providing for their existing patch sets, and FreePG has no support staff other than those downstream packagers who are already providing that support on a voluntary basis. However, we hope that having a single set of patches will allow distro packagers to share that support burden.
And also please upload verbatim upstream GnuPG separately. This allows user choice.
I agree that users should be empowered, however providing multiple install packages may not be the most sustainable way of doing so. It may be that the same outcome can be achieved through configuration options rather than separate binaries.
—- Andrew Gallagher
