Fedora 25 upgrade: doesn't install key for package updates, what's going on?












0















Fedora 24 pops up this lovely GUI-triggered update to Fedora 25 (using gnome-software). The instructions for upgrading Fedora workstation simply list the steps to click through in the GUI. Good job!



When I went to install some software, I was surprised to find this prompt/warning:



$ sudo dnf upgrade
...
warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
Importing GPG key 0xFDB19C98:
Userid : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Is this ok [y/N]:


Does this mean automatic updates (notifications) are silently failing unless I manually install something and accept the key??










share|improve this question



























    0















    Fedora 24 pops up this lovely GUI-triggered update to Fedora 25 (using gnome-software). The instructions for upgrading Fedora workstation simply list the steps to click through in the GUI. Good job!



    When I went to install some software, I was surprised to find this prompt/warning:



    $ sudo dnf upgrade
    ...
    warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
    Importing GPG key 0xFDB19C98:
    Userid : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
    Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
    From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
    Is this ok [y/N]:


    Does this mean automatic updates (notifications) are silently failing unless I manually install something and accept the key??










    share|improve this question

























      0












      0








      0








      Fedora 24 pops up this lovely GUI-triggered update to Fedora 25 (using gnome-software). The instructions for upgrading Fedora workstation simply list the steps to click through in the GUI. Good job!



      When I went to install some software, I was surprised to find this prompt/warning:



      $ sudo dnf upgrade
      ...
      warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
      Importing GPG key 0xFDB19C98:
      Userid : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
      Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
      From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
      Is this ok [y/N]:


      Does this mean automatic updates (notifications) are silently failing unless I manually install something and accept the key??










      share|improve this question














      Fedora 24 pops up this lovely GUI-triggered update to Fedora 25 (using gnome-software). The instructions for upgrading Fedora workstation simply list the steps to click through in the GUI. Good job!



      When I went to install some software, I was surprised to find this prompt/warning:



      $ sudo dnf upgrade
      ...
      warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
      Importing GPG key 0xFDB19C98:
      Userid : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
      Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
      From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
      Is this ok [y/N]:


      Does this mean automatic updates (notifications) are silently failing unless I manually install something and accept the key??







      fedora upgrade dnf software-updates






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 20 '16 at 14:40









      sourcejedisourcejedi

      23.2k437102




      23.2k437102






















          1 Answer
          1






          active

          oldest

          votes


















          3














          Actually this is fine. I might even argue it is the best way to do it :-).



          The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.



          You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.



          This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.



          You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.



          Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).



          The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).



          I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.



          EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).



          Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.






          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f331668%2ffedora-25-upgrade-doesnt-install-key-for-package-updates-whats-going-on%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3














            Actually this is fine. I might even argue it is the best way to do it :-).



            The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.



            You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.



            This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.



            You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.



            Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).



            The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).



            I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.



            EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).



            Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.






            share|improve this answer






























              3














              Actually this is fine. I might even argue it is the best way to do it :-).



              The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.



              You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.



              This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.



              You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.



              Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).



              The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).



              I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.



              EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).



              Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.






              share|improve this answer




























                3












                3








                3







                Actually this is fine. I might even argue it is the best way to do it :-).



                The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.



                You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.



                This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.



                You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.



                Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).



                The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).



                I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.



                EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).



                Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.






                share|improve this answer















                Actually this is fine. I might even argue it is the best way to do it :-).



                The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.



                You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.



                This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.



                You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.



                Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).



                The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).



                I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.



                EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).



                Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 8 at 16:38

























                answered Dec 20 '16 at 14:40









                sourcejedisourcejedi

                23.2k437102




                23.2k437102






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f331668%2ffedora-25-upgrade-doesnt-install-key-for-package-updates-whats-going-on%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    How to make a Squid Proxy server?

                    Is this a new Fibonacci Identity?

                    19世紀