Page MenuHome GnuPG

Kleopatra: Wrong update suggestion from 5.0.0 to 4.4.0
Testing, HighPublic

Description

Kleopatra gpg4win-5.0.0-beta190 suggests to update to 4.4.0.

Note: I don't get the message automatically on start as @ebo did.

Details

Version
gpg4win-5.0.0-beta190

Event Timeline

timegrid created this object with edit policy "Contributor (Project)".

The problem here is that the version number in kleopatra is still 4.0.0-something, which is then compared to 4.4.0.

werner triaged this task as High priority.
werner added a subscriber: werner.

This should compare the gpg4win version number:

$ wget -qO- versions.gnupg.org/swdb.lst | grep ^gpg4win_ver
gpg4win_ver 4.4.1

dirmngr has an API for this. Obviously kleopatra uses its own version number and not the gpg4win version number.

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Do I understand correctly that this bug is then automatically done/fixed?

Do I understand correctly that this bug is then automatically done/fixed?

It depends on how the version comparison works. We may have to change the code to extract the version number (e.g. 5.0.0) from the version string.

This is all done by gpgconf like here:

$ gpgconf --query-swdb gpg4win 5.0.0
gpg4win:5.0.0:n:3.1.16:0:20211201T085054:20211206T213257:3.1.16:20210611T000000:0::

First, gpgconf doesn't help with parsing a version string like gpg4win-5.0.0-beta190 which is what I was talking about. Once we have extracted "gpg4win" and "5.0.0" we could use gpgconf. ...if it worked as documented in the man page. I don't understand this:

$ gpgconf --query-swdb gpg4win 4.3.0
gpg4win:4.3.0:-::32849:::::::

$ gpgconf --query-swdb gpg4win 4.4.0
gpg4win:4.4.0:-::32849:::::::

$ gpgconf --query-swdb gpg4win 4.4.1
gpg4win:4.4.1:-::32849:::::::

Since Gpg4win 4.4.1 is the latest released version I would have expected
gpg4win:4.3.0:u:...
gpg4win:4.4.0:u:...
and
gpg4win:4.4.1:c:...

Hmm, not even your command line works here:

$ gpgconf --query-swdb gpg4win 5.0.0
gpg4win:5.0.0:-::32849:::::::

$ $ gpgconf --version
gpgconf (GnuPG) 2.5.6

I didn't find a swdb file in my ~/.gnupg. I suspect that dirmngr either didn't try to download it or failed to download it. gpgconf --verbose ... doesn't help.

Update:
Explicitly running

$ gpg-connect-agent --dirmngr "loadswdb --force" /bye

fixes the problem, but man gpgconf says

--query-swdb package_name [version_string]
      Returns  the current version for package_name and if version_string is given also an indicator on whether an update is
      available.  The actual file with the software version is automatically downloaded and  checked  by  dirmngr.   dirmngr
      uses a thresholds to avoid download the file too often and it does this by default only if it can be done via Tor.  To
      force an update of that file this command can be used:

Looks like I missed/misread "and it does this by default only if it can be done via Tor."

Kleopatra explicitly runs gpg-connect-agent --dirmngr "loadswdb --force" /bye if an update check is forced by the user, but not if Kleopatra checks automatically. I think I'm still missing something.

By the way, Kleopatra uses GpgME::SwdbResult::query() which I expect to do what you propose.

The version file is locally cached and updated from time to time unless that feature is disabled.
An update can be forced using

$ gpg-connect-agent --dirmngr 'loadswdb --force' /bye

Here is a sample run from my machine:

$ gpgconf --query-swdb gpg4win 4.4.0
gpg4win:4.4.0:u:4.4.1:0:20250521T162016:20250530T091501:4.4.1:20250521T000000:0::
$ gpgconf --query-swdb gpg4win 4.4.1
gpg4win:4.4.1:c:4.4.1:0:20250521T162016:20250530T091501:4.4.1:20250521T000000:0::
$ gpgconf --query-swdb gpg4win 4.4.2
gpg4win:4.4.2:n:4.4.1:0:20250521T162016:20250530T091501:4.4.1:20250521T000000:0::

Thus 4.4.0 requires an update ('u'), 4.4.1 is current ('c'), and an 4.4.2 would be newer ('n').

BTW, if you append a beta string the thing works as well. Thus with an development version for 4.4.2 we would get a 'newer' state:

$ gpgconf --query-swdb gpg4win 4.4.2-beta123
gpg4win:4.4.2-beta123:n:4.4.1:0:20250521T162016:20250530T091501:4.4.1:20250521T000000:0::

I forgot to mention that gpgrt has an API to compare version numbers in the same way gpgconf and all gnupg components do it; this should be somewhat similar to sort -V

/* Compare arbitrary version strings.  For the standard m.n.o version
 * numbering scheme a LEVEL of 3 is suitable; see the manual.  */
int gpgrt_cmp_version (const char *a, const char *b, int level);
ikloecker changed the task status from Open to Testing.Fri, May 30, 11:30 AM
ikloecker moved this task from Backlog to WIP on the gpd5x board.

Do I understand correctly that this bug is then automatically done/fixed?

It depends on how the version comparison works. We may have to change the code to extract the version number (e.g. 5.0.0) from the version string.

From a brief look at the regular expression it should work out-of-the-box with the changes made for T7666: Kleopatra: Rework versioning.

Running "Check for updates" in Gpg4win with the changes made for T7666: Kleopatra: Rework versioning I get a window with title

Up to date - Kleopatra

and text

No update found in the available version database.

i.e. it seems to work. -> Setting the ticket to Testing.

I think the text is confusing and should be improved. -> T7669: Kleopatra: Change result message of update check

I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"