Expired keys cause tasks to be in changed state

[Christian Kotte]

A message should be displayed that the key is already expired.

I have this in the debug log:

...
import new keys from keyserver
fingerprint [13EBBDBEDE7A12775DFDB1BABB572E0E2D182910] already installed
comparing trust [0] and [1]
update trust level to [1]
...

After running gpg --refresh-keys --keyserver keyserver.ubuntu.com, the tasks are in ok state.

[Rinck H. Sonnenberg]

I'm going to need a little more to figure out what is going wrong here. Scanning through the code, there are checks in place to verify if a key has expired or not, so when and how does this occur? If you could provide some sample playbook and a sample key (just one you generate for this purpose) that could help me figure out what is going on

[Christian Kotte]

Unfortunately, I already refreshed my keys. I don't know how to import an already expired key. Probably would need to download an old key and then check if it can be refreshed. Then you can re-create this "issue".

You can see the validity with gpg --list-keys:

# gpg --list-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
pub   rsa4096/0xBB572E0E2D182910 2009-08-25 [SC] [expires: 2024-07-01]
      Key fingerprint = 13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910
uid                   [ unknown] Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sub   rsa2048/0x2C44695DB9F6043D 2019-02-23 [S] [expires: 2024-07-01]

You will see something like this:

# gpg --list-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
pub   rsa4096/0xBB572E0E2D182910 2009-08-25 [SC] [expired]
....

In the debug log you will see this for the task:

....
comparing trust [0] and [1]
update trust level to [1]
....

The task is then always in changed state until you refresh the key manually.

There should be a message in the debug log so you know the key is expired. Then you will understand why the task is in changed state all the time.

[Christian Kotte]

Variables:

- key_fingerprint: 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
      keyserver: keyserver.ubuntu.com
      description: "Gentoo Linux Release Engineering <[e-mail]> (stage tarball/ISO download verification)"

Task:

- name: Import public keys
  tags: user
  gpg_key:
    fpr: "{{ item.key_fingerprint }}"
    keyserver: "{{ item.keyserver }}"
  become: true
  become_user: "{{ user.name }}"
  with_items: "{{ gnupg.public_keys }}"
  loop_control:
    label: "{{ item.description }}"

[Rinck H. Sonnenberg]

I see your point but not sure if this needs fixing? The module attempts to fix the trust level of your key because it is not at the level you have defined in your ansible task. The problem is it will never get there either, because the key has expired. I think the real fix would be to update your keys? A notification would be nice, but I don't consider that a must have for the module to work correctly.