Page MenuHome GnuPG
Create Task
Maniphest T7200

Trustdb not updated on import of extended certificate
Testing, NormalPublic
Actions

Description

If you have an expired certificate in your keybox/keyring and import the extended pubkey the trustdb is not updated.

This is an issue in real life: it was reported (for VSD 3.2.0) that the TrustedKey of an organization expired, then extended and the extended certificate was imported by the employees. But still that certificate and all certificated signed by that key were shown as "not certified".
F5 does not help.

Currently one has to import and certify a new key as a workaround to update the trustdb or explicitly update it on the command line with gpg --check-trustdb.

Can we automatically update the trustdb on import of new signatures, too, and not only for a new key import as in T6399: Missing trustdb check on import of certificate?

To clarify: If one does set a new Trusted Key, pressing F5 helps to mark the certificates signed by it as certified. But this has no effect in the here described case if a Trusted Key has expired and its extended certificate is imported.

Details

Version
Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35), VSD 3.2.3, gpg4win 4.3.1

Revisions and Commits

rG GnuPG
rG8b4ad616de6c gpg: Exclude expired trusted keys from the key validation process.
rGceec31751cc0 gpg: Validate the trustdb after the import of a trusted key.
rG19f2f00bfd30 gpg: Exclude expired trusted keys from the key validation process.
rGa0aea092647c gpg: Validate the trustdb after the import of a trusted key.
rG23d4e7f0a796 gpg: Validate the trustdb after the import of a trusted key.
rG79ab52ff42e8 gpg: Exclude expired trusted keys from the key validation process.

Related Objects

Event Timeline

• ebo created this task.Jul 12 2024, 11:31 AM
• ebo updated the task description. (Show Details)Jul 16 2024, 10:29 AM
• ebo updated the task description. (Show Details)Jul 17 2024, 11:02 AM
• aheinecke added subscribers: • werner, • aheinecke.Jul 22 2024, 5:04 PM

The problem here is that Kleopatra could do that of course, e.g. after importing a file. But this has to be done by the GnuPG system to handle all the automatic cases etc.
I leave this up for triage, since I am not sure if this is a bug, or a feature request. @ebo I believe you said to me that you tested this with keyboxd? As my answer would have been that keyboxd would be required for a proper solution to this.

• ebo added a comment.Jul 23 2024, 9:16 AM

As it was a fresh install of a gpg4win test version I used: yes, common.conf was not only supposed to be there, it is and keyboxd.exe is shown in the task manager.
But I think it not only needs to be solved for keyboxd, as our VSD customers don't have that.

I would settle for a button if we can not / will not do the update automatically for VSD versions.

• werner added a comment.Jul 23 2024, 2:56 PM

iirc, we once disabled the trustdb check because it was run for each imported certificate which took long and was superfluous die to changes introduced by the next certificates. GPGME has a "no-auto-check-trustdb" flag to allow for this.
See T6261

• werner triaged this task as Normal priority.Jul 23 2024, 2:57 PM
• werner added a project: kleopatra.
• werner added a project: Bug Report.
• aheinecke added a comment.Jul 23 2024, 4:17 PM

The only change i remember and can find regarding that, is, that for the initial keylisting we disabled the check using the context flag T6261: Kleopatra / QGPGME: Use --no-auto-check-trustdb for initial keylisting since we suspected that this had something to do with reports that the initial keylisting either locked up or was very slow. At the least the goal was that by no auto check trustdb on the initial keylisting it would make it behave more consistently from start to start. But I am pretty sure that you told at least me, that Kleopatra should not try to explicitly do trustdb checks and try to manage that since gnupg takes care of this internally.

• ikloecker raised the priority of this task from Normal to Needs Triage.Wed, Sep 18, 3:05 PM
• ikloecker removed a project: kleopatra.
• ikloecker added a subscriber: • ikloecker.

I don't see how Kleopatra is responsible for updating the trustdb. As Andre correctly commented, Kleopatra sets "no-auto-check-trustdb" only for the initial key listing.

Removing project kleopatra and setting back to Needs Triage to trigger a re-evaluation.

• werner added a comment.Wed, Sep 18, 6:23 PM

How does Kleo's key listing after an import work? Does it do a full listing or just updates the imported keys? Keep in mind that the import merely sets a flag in the trudtdb to be evaluated by the next key listing.

• ikloecker added a comment.Wed, Sep 18, 8:48 PM

Kleopatra does a full key listing after an import (triggered by the file system watcher noticing changes in GNUPGHOME). In general, Kleopatra always does full key listings.

• werner added a comment.Thu, Sep 19, 8:58 AM

Does the file system watcher catch that keyboxd changes its database file below public-keys.d ?

• ikloecker added a comment.Thu, Sep 19, 10:23 AM

It's possible that the file system watcher does not yet support keyboxd. (Ideally, keyboxd would report changes via assuan to processes listening for changes. The file system watcher is obviously just a workaround.)

In any case: The problem was reported for VSD 3.2.0 which doesn't have keyboxd.

• ebo updated the task description. (Show Details)Thu, Sep 19, 10:59 AM
• ebo changed Version from Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35) to Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35), VSD 3.2.3.
• ikloecker added a comment.Thu, Sep 19, 12:18 PM

I'm unable to reproduce the problem with Kleopatra master (Qt 6) and GnuPG 2.4.

For the setup: I created two keys C(ertified) and T(rusted), certified C with T, exported T (as T-before-expiration), expired T (with --quick-set-expire FPR seconds=10), exported T (as T-expired), unexpired T (with Kleopatra and default expiration), exported T (as T-extended-expiration). Then I deleted C and T.

For the test:

  1. I added "trusted-key <FPR of T>" to gpg.conf.
  2. Import public key C (with kleopatra command line). -> C is shown as "not certified".
  3. Import T-before-expiration (with kleopatra command line). -> C is shown as "certified".

Audit log:

gpg: key 2DEF4BDD7D546267: 1 signature not checked due to a missing key
gpg: key 2DEF4BDD7D546267 marked as ultimately trusted
gpg: key 2DEF4BDD7D546267: public key "T7200 Trusted Key <t7200-trusted-key@example.net>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:  81  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 81u
gpg: depth: 1  valid:   5  signed:   0  trust: 5-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-11-02
  1. Import T-expired (with kleopatra command line). -> C is shown as "not certified".

Audit log:

gpg: key 2DEF4BDD7D546267: 1 signature not checked due to a missing key
gpg: key 2DEF4BDD7D546267: "T7200 Trusted Key <t7200-trusted-key@example.net>" 1 new signature
gpg: Total number processed: 1
gpg:         new signatures: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:  81  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 81u
gpg: depth: 1  valid:   4  signed:   0  trust: 4-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-11-02
  1. Import T-extended-expiration (with kleopatra command line). -> C is shown as "certified".

Audit log:

gpg: key 2DEF4BDD7D546267: 1 signature not checked due to a missing key
gpg: key 2DEF4BDD7D546267: "T7200 Trusted Key <t7200-trusted-key@example.net>" 2 new signatures
gpg: Total number processed: 1
gpg:         new signatures: 2
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:  81  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 81u
gpg: depth: 1  valid:   5  signed:   0  trust: 5-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-11-02

In particular, we see in the Audit logs that gpg updated the trustdb after each import.

Either I'm testing this wrong. Or the problem doesn't occur with gpg 2.4 on Linux.

• werner added a comment.Thu, Sep 19, 1:03 PM

The import code related to the trust management did not change since 2018. Thus I doubt it depends on the version.

Might it be that the original report was wrong. I recently had a support case where the updated key was only locally signed (lsign - the Kleopatra default) and thus things didn't changed after import.

• ebo added a comment.EditedFri, Sep 20, 8:23 AM

@werner: I reproduced this before creating the ticket… With a VSD version and a Gpg4win Testversion. I'll add Audit Logs.

• ebo added a comment.Fri, Sep 20, 10:01 AM

ok, the following is with Gpg4win 4.3.1.

I've got several certificates in the keyring which are certified by Ted. The Ted certificate is expired but it is set in gpg.conf as trusted-key.
For good measure I did a gpg --check-trustdb before importing the extended Ted certificate.

Ted is shown as "expired". All keys certified by Ted are shown as "not certified".

Import Ted-extended: -> Ted is shown as "certified", All keys certified by Ted: "not certified".
Audit log:

gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: pub  rsa3072/C5D6C919005F36A4 2023-03-08  Ted Tester <Ted.Tester@demo.gnupg.com>
gpg: Schlüssel C5D6C919005F36A4: "Ted Tester <Ted.Tester@demo.gnupg.com>" 1 neue Signatur
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                         neue Signaturen: 1
gpg: keydb: handles=0 locks=0 parse=3 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=8 cached=6 good=6 bad=0
gpg: objcache: keys=2/2/0 chains=381,1..1 buckets=383/20 attic=254
gpg: objcache: uids=1/1/0 chains=106,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

As you see, no update of trustdb.
Seems we have a different behavior on Linux and Windows there.

Doing gpg --check-trustdb manually results in the keys-certified-by Ted to be shown as certified, of course.

C:\Users\g10code.WIN-TEST3>gpg --check-trustdb
gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: 12 Schlüssel bislang bearbeitet (7 Validity Zähler gelöscht)
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Tiefe: 0  gültig:   5  signiert:   7  Vertrauen: 0-, 0q, 0n, 0m, 0f, 5u
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Tiefe: 1  gültig:   6  signiert:   1  Vertrauen: 6-, 0q, 0n, 0m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2027-04-11
gpg: keydb: handles=0 locks=0 parse=44 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=141 cached=113 good=113 bad=0
gpg: objcache: keys=13/13/0 chains=370,1..1 buckets=383/20 attic=243
gpg: objcache: uids=6/6/0 chains=101,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

When I delete the Trusted Key certificate Ted, the certificates signed by it are displayed immediately as "not certified", though.

Then importing the expired Ted-certificate, Audit log:

gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: pub  rsa3072/C5D6C919005F36A4 2023-03-08  Ted Tester <Ted.Tester@demo.gnupg.com>
gpg: verwende Vertrauensmodell pgp
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet
gpg: Schlüssel C5D6C919005F36A4: Öffentlicher Schlüssel "Ted Tester <Ted.Tester@demo.gnupg.com>" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1
gpg: 12 Schlüssel bislang bearbeitet (6 Validity Zähler gelöscht)
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Tiefe: 0  gültig:   5  signiert:   2  Vertrauen: 0-, 0q, 0n, 0m, 0f, 5u
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Tiefe: 1  gültig:   2  signiert:   0  Vertrauen: 2-, 0q, 0n, 0m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2027-04-11
gpg: keydb: handles=0 locks=0 parse=53 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=138 cached=109 good=109 bad=0
gpg: objcache: keys=11/11/0 chains=372,1..1 buckets=383/20 attic=245
gpg: objcache: uids=5/5/0 chains=102,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

Shows the certificates signed by Ted as "certified" again.
Because I forgot to run the trustdb-check manually beforehand…

Running it now manually again results in those certificates shown as "not certified", as expected:

C:\Users\g10code.WIN-TEST3>gpg --check-trustdb
gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: 12 Schlüssel bislang bearbeitet (11 Validity Zähler gelöscht)
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Tiefe: 0  gültig:   5  signiert:   2  Vertrauen: 0-, 0q, 0n, 0m, 0f, 5u
gpg: Hinweis: Signaturschlüssel C2577F23F8E93418 ist am 2023-03-09 11:00:00 verfallen
gpg: Hinweis: Signaturschlüssel C5D6C919005F36A4 ist am 2024-07-05 21:58:59 verfallen
gpg: Tiefe: 1  gültig:   2  signiert:   0  Vertrauen: 2-, 0q, 0n, 0m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2027-04-11
gpg: keydb: handles=0 locks=0 parse=51 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=132 cached=105 good=105 bad=0
gpg: objcache: keys=11/11/0 chains=372,1..1 buckets=383/20 attic=245
gpg: objcache: uids=5/5/0 chains=102,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
• ebo changed Version from Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35), VSD 3.2.3 to Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35), VSD 3.2.3, gpg4win 4.3.1.Fri, Sep 20, 10:02 AM
• ebo added projects: gnupg22, vsd33.Fri, Sep 20, 11:22 AM

The issue is the same on import on the command line. So it's a gpg issue.

• ebo triaged this task as Normal priority.Fri, Sep 20, 11:24 AM
• ebo added a comment.Fri, Sep 20, 11:39 AM

And I can replicate it with the Appimage for VSD 3.2.2, too.

• ikloecker added a comment.Fri, Sep 20, 3:43 PM

The test with Gpg4win 4.3.1 (using GnuPG 2.4) seems to indicate that:

  1. gpg didn't update the trustdb automatically after importing the extended trusted certificate.
  2. gpg updated the trustdb automatically after deleting and re-importing the expired trusted certificate, but Kleopatra still showed the certificates signed by the trusted certificate as "certified". This could be a bug in the trustdb calculation (note the log message "Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet" which could indicate that gpg treats the key as valid although it's expired). On the other hand, my test with GnuPG 2.4 on Linux doesn't reproduce this problem.

This doesn't really make sense to me unless the trustdb handling behaves very differently on Linux and on Windows.

• werner added a commit: rG79ab52ff42e8: gpg: Exclude expired trusted keys from the key validation process..Wed, Sep 25, 3:15 PM
• werner added a commit: rG23d4e7f0a796: gpg: Validate the trustdb after the import of a trusted key..
• werner added a commit: rGa0aea092647c: gpg: Validate the trustdb after the import of a trusted key..Wed, Sep 25, 3:24 PM
• werner added a commit: rG19f2f00bfd30: gpg: Exclude expired trusted keys from the key validation process..
• werner added a commit: rGceec31751cc0: gpg: Validate the trustdb after the import of a trusted key..
• werner added a commit: rG8b4ad616de6c: gpg: Exclude expired trusted keys from the key validation process..
• werner changed the task status from Open to Testing.Wed, Sep 25, 3:26 PM
• werner moved this task from Backlog to QA on the gnupg22 board.

I guess this is now fixed for all branches.

• werner moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Wed, Sep 25, 3:26 PM
• werner moved this task from Backlog to QA on the vsd33 board.
• werner mentioned this in T7255: Release GnuPG 2.2.45.Tue, Oct 1, 1:59 PM
• ebo added a comment.Fri, Oct 4, 4:16 PM

works for VS-Desktop-3.2.94.2-Beta (Beta for VSD 3.2.4)

• ebo added a project: vsd32.Fri, Oct 4, 4:17 PM
• ebo moved this task from Backlog to vsd-3.2.4 on the vsd32 board.
• ebo moved this task from QA to gnupg-2.2.45 on the gnupg22 board.
• ebo edited projects, added gnupg22 (gnupg-2.2.45); removed gnupg22.