bug#37556: gpg "-unknown" version string

bug#37556: gpg "-unknown" version string

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

Package: emacs
Version: 27.0.50
X-Debbugs-Cc: larsi@gnus.org



This is related to bug# 35629.

This commit

   commit 42ba6200af10c00c72ac13912d6fb42a7af88058
   Author: Lars Ingebrigtsen <larsi@gnus.org>
   Date:   2019-08-26 08:02:31 +0200

       Allow finding gpg2 binaries when gpg2 has an "unknown" version string

       * lisp/epg-config.el (epg-find-configuration): Allow finding a
       usable configuration even if the version string looks like "gpg
       (GnuPG) 2.2.15-unknown" (bug#35629).

fixes one function, but there are other uses of version-related functions
in epg, for example

(defun epg-required-version-p (protocol required-version)
  "Verify a sufficient version of GnuPG for specific protocol.
PROTOCOL is symbol, either `OpenPGP' or `CMS'.  REQUIRED-VERSION
is a string containing the required version number.  Return
non-nil if that version or higher is installed."
  (let ((version (cdr (assq 'version (epg-find-configuration protocol)))))
    (and (stringp version)
         (version<= required-version version))))

which calls epg-find-configuration (which is protected by the above
change), and then version<= (which fails).

This makes epg-tests.el fail on my gpg, from MSYS2:

$ gpg --version
gpg (GnuPG) 2.2.17-unknown
libgcrypt 1.8.4

Fixing this with another let binding around `version<=' is trivial, but it
is a kludge.

I think it makes more sense just adding "-unknown" to the formats
recognized by default with version-regexp-alist.

(Note: after working around this bug, epg tests still fail for me, but for
unrelated reasons.)

[-- Attachment #2: Type: text/html, Size: 2107 bytes --]

bug#37556: gpg "-unknown" version string

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> I think it makes more sense just adding "-unknown" to the formats
> recognized by default with version-regexp-alist.

Hm...  I guess that would make sense, but might there be other
ramifications?  All callers to version-to-list may get other data back
than they are used to?

I don't know much about how that function is used in general, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37556: gpg "-unknown" version string

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 07:34:45 +0200
> Cc: 37556@debbugs.gnu.org
> 
> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> > I think it makes more sense just adding "-unknown" to the formats
> > recognized by default with version-regexp-alist.
> 
> Hm...  I guess that would make sense, but might there be other
> ramifications?  All callers to version-to-list may get other data back
> than they are used to?

"-unknown" is unusual in version strings, IME.  If this is somehow
related to gpg, maybe we should chop that before we invoke the
version-comparison functions, in gpg-related Lisp files only?

bug#37556: gpg "-unknown" version string

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Mon, Sep 30, 2019 at 9:17 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> "-unknown" is unusual in version strings, IME.

Yes, but, why would that be a problem? It's not like we're going to find a
lot of strings 1.2.3-unknown that aren't really version numbers, are we?

> If this is somehow
> related to gpg, maybe we should chop that before we invoke the
> version-comparison functions, in gpg-related Lisp files only?

Chopping would mean that 2.2.17 and 2.2.17-unknown are equal, but currently
2.2.17-unknown (in epg) is less than 2.2.17.

Certainly the problem can be fixed by wrapping more code with (let
((version-regexp-alist (cons ...)) ...). It's just that it seems a bit
kludgy to me. But whatever, not really a big issue.

[-- Attachment #2: Type: text/html, Size: 975 bytes --]

bug#37556: gpg "-unknown" version string

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 30 Sep 2019 09:49:06 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 37556@debbugs.gnu.org
> 
> Chopping would mean that 2.2.17 and 2.2.17-unknown are equal, but currently 2.2.17-unknown (in epg) is less
> than 2.2.17.

You are saying that -unknown is in this case the same as -alpha.  My
problem is how to be sure this is the case everywhere where -unknown
could be used.

bug#37556: gpg "-unknown" version string

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Mon, Sep 30, 2019 at 10:46 AM Eli Zaretskii <eliz@gnu.org> wrote:

> You are saying that -unknown is in this case the same as -alpha.

In fact, Lars gave it priority -4, so like a snapshot.

> My problem is how to be sure this is the case everywhere where -unknown
> could be used.

True, but if -unknown is really uncommon, we can deal with the problems as
they are reported (if ever).

[-- Attachment #2: Type: text/html, Size: 572 bytes --]

bug#37556: gpg "-unknown" version string

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Sep 30, 2019 at 10:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> You are saying that -unknown is in this case the same as -alpha.
>
> In fact, Lars gave it priority -4, so like a snapshot.
>
>> My problem is how to be sure this is the case everywhere where -unknown
>> could be used.
>
> True, but if -unknown is really uncommon, we can deal with the problems as
> they are reported (if ever).

Looking at the code, just keeping this in epg* is really awkward,
because we compare the version strings afterwards (in other contexts)
with version<=, which will then fail.

So I think this patch is needed to fix the epg problem.  But I'm not
confident that it won't change behaviour for other users of these
version functions.

On the other hand, we have been adding to this alist over the years
without anything blowing up (that I know of), so perhaps it is safe-ish?
If it turns out to be a problem, it's easy enough to back out (but then
I don't really know how to fix the original epg problem in a sensible
manner).

diff --git a/lisp/subr.el b/lisp/subr.el
index 45b99a82d2..efe530cd54 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -5285,6 +5285,8 @@ version-regexp-alist
     ("^[-._+]$"                                           . -4)
     ;; treat "1.2.3-CVS" as snapshot release
     ("^[-._+ ]?\\(cvs\\|git\\|bzr\\|svn\\|hg\\|darcs\\)$" . -4)
+    ;; treat "-unknown" the same as snapshots.
+    ("^[-._+ ]?unknown$"                                  . -4)
     ("^[-._+ ]?alpha$"                                    . -3)
     ("^[-._+ ]?beta$"                                     . -2)
     ("^[-._+ ]?\\(pre\\|rc\\)$"                           . -1))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37556: gpg "-unknown" version string

[Noam Postavsky]

Juanma Barranquero <lekktu@gmail.com> writes:

>> If this is somehow related to gpg, maybe we should chop that before
>> we invoke the version-comparison functions, in gpg-related Lisp files
>> only?
>
> Chopping would mean that 2.2.17 and 2.2.17-unknown are equal, but currently
> 2.2.17-unknown (in epg) is less than 2.2.17.

I don't understand why making -unknown equivalent to a lesser version
makes sense.  Shouldn't 2.2.17 and 2.2.17-unknown in fact be equal?

bug#37556: gpg "-unknown" version string

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>>> If this is somehow related to gpg, maybe we should chop that before
>>> we invoke the version-comparison functions, in gpg-related Lisp files
>>> only?
>>
>> Chopping would mean that 2.2.17 and 2.2.17-unknown are equal, but currently
>> 2.2.17-unknown (in epg) is less than 2.2.17.
>
> I don't understand why making -unknown equivalent to a lesser version
> makes sense.  Shouldn't 2.2.17 and 2.2.17-unknown in fact be equal?

Should they?  2.2.17-pre and 2.2.17-alpha should be less than 2.2.17,
but how do we know that -unknown isn't something -alpha-ish?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37556: gpg "-unknown" version string

[Noam Postavsky]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I don't understand why making -unknown equivalent to a lesser version
>> makes sense.  Shouldn't 2.2.17 and 2.2.17-unknown in fact be equal?
>
> Should they?  2.2.17-pre and 2.2.17-alpha should be less than 2.2.17,
> but how do we know that -unknown isn't something -alpha-ish?

It's "unknown", so it could be something opposite-of-alpha-ish too,
right?  On average, 0 seems right.

bug#37556: gpg "-unknown" version string

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> I don't understand why making -unknown equivalent to a lesser version
>>> makes sense.  Shouldn't 2.2.17 and 2.2.17-unknown in fact be equal?
>>
>> Should they?  2.2.17-pre and 2.2.17-alpha should be less than 2.2.17,
>> but how do we know that -unknown isn't something -alpha-ish?
>
> It's "unknown", so it could be something opposite-of-alpha-ish too,
> right?  On average, 0 seems right.

That's possible.  Does anybody know how usual these -unknown things are,
and why they exist?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37556: gpg "-unknown" version string

[Kazuhiro Ito]

> >>> I don't understand why making -unknown equivalent to a lesser version
> >>> makes sense.  Shouldn't 2.2.17 and 2.2.17-unknown in fact be equal?
> >>
> >> Should they?  2.2.17-pre and 2.2.17-alpha should be less than 2.2.17,
> >> but how do we know that -unknown isn't something -alpha-ish?
> >
> > It's "unknown", so it could be something opposite-of-alpha-ish too,
> > right?  On average, 0 seems right.
> 
> That's possible.  Does anybody know how usual these -unknown things are,
> and why they exist?

I don't know "why", but I described when the suffix was added in the
past post.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35629#11

> GnuPG's autogen.sh makes "-unknown" suffix version configure script if
> source code directory doesn't have .git directory.

If you have the repository, autogen.sh can set an apropriate revision
number.  I guess "-unknown" version means "unknown version" literally,
because they couldn't decide the source code revision without
repository.

-- 
Kazuhiro Ito

bug#37556: gpg "-unknown" version string

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> This commit
>
>    commit 42ba6200af10c00c72ac13912d6fb42a7af88058
>    Author: Lars Ingebrigtsen <larsi@gnus.org>
>    Date:   2019-08-26 08:02:31 +0200
>
>        Allow finding gpg2 binaries when gpg2 has an "unknown" version string
>
>        * lisp/epg-config.el (epg-find-configuration): Allow finding a
>        usable configuration even if the version string looks like "gpg
>        (GnuPG) 2.2.15-unknown" (bug#35629).
>
> fixes one function, but there are other uses of version-related
> functions in epg, for example

I've now reverted this patch, and pushed the more general
version-regexp-alist patch.  I rated -unknown as -alpha -- there was
some discussion about whether that's best, but no conclusion was
reached, really.  It can be tweaked later if that's problematic.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37556: gpg "-unknown" version string

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Sun, Oct 13, 2019 at 5:01 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I've now reverted this patch, and pushed the more general
> version-regexp-alist patch.  I rated -unknown as -alpha -- there was
> some discussion about whether that's best, but no conclusion was
> reached, really.  It can be tweaked later if that's problematic.

Thanks. Closing this bug.

[-- Attachment #2: Type: text/html, Size: 500 bytes --]