Salt: pkrepo.manage does not detect keyid options changes

Created on 5 Dec 2013  路  14Comments  路  Source: saltstack/salt

Steps to reproduce:

  • Write a state without GPG keys informations
nginx_repo:
  pkgrepo.managed:
    - humanname: Nginx repository
    - name: deb http://nginx.org/packages/debian/ wheezy nginx
    - dist: wheezy
    - file: /etc/apt/sources.list.d/nginx.list
    - require_in:
      - pkg: nginx

This state will succeed. Adding a nginx pkg.installed state will correctly fail as no key is present.

  • Change your state to add GPG key infos:
nginx_repo:
  pkgrepo.managed:
    - humanname: Nginx repository
    - name: deb http://nginx.org/packages/debian/ wheezy nginx
    - dist: wheezy
    - file: /etc/apt/sources.list.d/nginx.list
    - keyid: 7BD9BF62
    - keyserver: keyserver.ubuntu.com
    - require_in:
      - pkg: nginx

salt-call state.highstate will report:

[INFO    ] Executing state pkgrepo.managed for deb http://nginx.org/packages/debian/ wheezy nginx
[INFO    ] Package repo 'deb http://nginx.org/packages/debian/ wheezy nginx' already configured

And no key will be added. I'm not sure this should be considered a bug though?

This was tested using salt version 0.17.2.

Bug Confirmed P4 Platform State Module severity-medium

All 14 comments

Erm, as far as I can detect your two sample states are exactly the same. Was the first not supposed to have keyid and similar args?

Indeed that was a copy/paste mistake, I edited the description.

This is still unfixed 18 months later. Pkgrepo.managed does not verify keyserver/keyid if the sources.list.d file is correct.

I ran into this because of a transient problem with a keys.gnupg.net mirror. Once the sources.list entry was correct, it never again tried to retrieve the keys.

Is it a big problem to check whether the GPG key is imported independently of the state of the repo file? I would really like to see this fixed.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

Maybe that bot should be taught to check for labels like 'High Severity'...

Thank you for updating this issue. It is no longer marked as stale.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

AFAIK this is still relevant?

Thank you for updating this issue. It is no longer marked as stale.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

Thank you for updating this issue. It is no longer marked as stale.

AFAICT this is a duplicate of #4438 and thus should have been closed with #53537.

duplicate and fixed with #53537 closing

Was this page helpful?
0 / 5 - 0 ratings