[pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options

[Christoph Biedl]

Werner Koch wrote...

> On Sun, 14 Mar 2021 14:32, Christoph Biedl said:
> 
> > Point is, the legacy file ~/.gnupg/options is still being used in
> > surprisingly many applications, also in documentation:
> 
> Then please file a bug against such documentation.  And maybe even
> against any application which read the option filre directly, that is
> without using gpgconf.

If Debian were not rather late in the freeze for Bullseye, I would
already have started the according procedure (Mass Bug Filing). But
given the release progress, this will not succeed in time.

For *after* the release, everything will be possible. My intent is to
keep impact for the current release low.

> >     https://codesearch.debian.net/search?q=.gnupg%2Foptions&literal=1
> 
> Look at the code shown tehre: Almost everywhere it is used as a fallback
> from gpg.conf.

Still some places do, or point to the wrong location. Also there might be
other programs that rely on the legacy location.

"Turning things off permanently is surprisingly difficult."

> > In Debian, revert that commit, and emit a deprecation warning if the
> > legacy file is parsed.
> 
> Sysadmins will kill you if you do that.  The global conf file has been a
> long standing request from many parties.  It comes very hadny for large
> installations because it can be used to enforce options on users.  That
> is why I took the trouble to actually backported this from master.

No doubt about the benefits of the new concept. However, sysadmins of
Debian systems could not benefit from that (yet), so I feel safe. Still
there are a lot of reasons why reverting is a bad idea, I will not
follow that approach.

> Supporting the legacy option file would be a Bad Idea.  In particular
> for a new major release it should be not a problem to add release notes
> mention that after 18 years the deprecated legacy option file is not
> anymore supported.

While it was deprecated a long time ago, until very recently users had
little chance to know about this, and therefore no reason to adopt. So
this comes as a surprise, and as a short-time and massive change, as
seen in this bug report. I really want to avoid users' workflows will
break galore, possibly without even being really noticed.


The best solution would have been to start emitting deprecating warnings
at some point in the past. But past cannot be changed.

My preferred solution was to restore the old behaviour for a limited
time, i.e. parsing the legacy config file, plus emitting that warning.
This will give everybody a chance to adjust their configuration.

Second in preference was to only emit that warning, without processing
the file.

Providing a warning in the release notes and other places is very easy
to do. But from experience I doubt this reaches the majority of affected
users in time. Which is why I except to create havoc if this was the
only reaction to this change.

    Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20210315/79a4a58c/attachment.sig>