Bug 1625674 - certain repos prevent dnf bash completion, making the command stuck
Summary: certain repos prevent dnf bash completion, making the command stuck
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1648686 1674432 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-05 13:56 UTC by Kamil Páral
Modified: 2019-11-27 18:08 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 18:08:17 UTC
Type: Bug


Attachments (Terms of Use)

Description Kamil Páral 2018-09-05 13:56:34 UTC
Description of problem:
When trying to use bash completion as a standard user, the command always freezes for me and I have to kill it with Ctrl+C. I debugged it and found the cause. It's related to certain third-party repos I have installed.

My example command is "dnf install bzfla[TAB]". I used "set -x" in terminal first and then tried to complete the command. It showed executing this command:

+++ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C

When I execute it manually, it shows this:

$ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C
Is this ok [y/N]:

Aha, so it's actually waiting for input! It shouldn't do that. If I reply:

$ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C
Is this ok [y/N]: n
bzflag-maps-sample-2.4.14-2.fc29.noarch
bzflag-2.4.14-2.fc29.x86_64

I get the results.

Looking in the source code, the request comes from `def userconfirm()` called by `class CliKeyImport` inside /usr/lib/python3.7/site-packages/dnf/cli/output.py .

After more debugging, it's related to my /etc/yum.repos.d/atom.repo with this contents:

[Atom]
name=Atom Editor
baseurl=https://packagecloud.io/AtomEditor/atom/el/7/$basearch
enabled=1
gpgcheck=0
repo_gpgcheck=1
gpgkey=https://packagecloud.io/AtomEditor/atom/gpgkey

When I disable it, my problems go away, dnf now autocompletes. 

Another solution is to edit  and add "--assumeno" into `_dnf_show_packages()` in /usr/share/bash-completion/completions/dnf. That's probably the right thing to do and it should be there by default.

The weird thing is, I already accepted the key as root for that repo, so it's clearly not considering that key. I also ran "dnf repolist" as the standard user and it asked for key confirmation once more (I'm not sure whether this is correct, when root already accepted that key), but I confirmed it once more (subsequent repolist runs don't ask for further confirmation). But dnf autocompletion still gets stuck! So it's ignoring both root keys and user keys, and that's probably yet another bug. If this is only fixed by adding "--assumeno" as mentioned above, I guess it wouldn't still autocomplete packages from that Atom repo. There is probably one more bug to resolve in there, regarding confirmed keys for a repo.


Version-Release number of selected component (if applicable):
dnf-3.3.0-2.fc29.noarch

How reproducible:
always, I think

Steps to Reproduce:
1. add the repo above
2. run `dnf install packag[TAB]`

Comment 1 Jeff Shee 2018-11-12 09:03:33 UTC
Having a same bug, sudo dnf install firefox[TAB], freeze.

Comment 2 Kamil Páral 2018-11-12 09:30:35 UTC
Yes, still present with dnf-4.0.4-2.fc29.noarch

Comment 3 Simon 2018-11-26 09:59:57 UTC
I had this problem, after running 

`/usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install lyn -d 0 -C` (please note the removal of `-q` ) 
i get this error message:
```
Google Cloud SDK
1.7 kB/s | 1.8 kB     00:01
Importing GPG key 0xA7317B0F:
 Userid     : "Google Cloud Packages Automatic Signing Key <gc-team@google.com>"
 Fingerprint: D0BC 747F D8CA F711 7500 D6FA 3746 C208 A731 7B0F
 From       : https://packages.cloud.google.com/yum/doc/yum-key.gpg
Is this ok [y/N]: y
```
I guess that it is a bug that auto-complete hangs rather than ignoring updates or exit with an error but the actual problem seems to be with one or more repos.

I do NOT have this problem if i use `sudo -u` and then run `rpm install lynx<TAB>`.
It seems as if this file `/var/cache/dnf/google-cloud-sdk-2367166c9fd8d791/pubring/trustdb.gpg` is only readable by root. I guess that this is an issue in googles packaging for RPM.
It works for normal users after running
`sudo chmod +r /var/cache/dnf/google-cloud-sdk-2367166c9fd8d791/pubring/trustdb.gpg` but since i am not quite sure of DNFs security model I can not recommend this solution (it might be OK i just dont know so i can't recommend it)

Comment 4 Simon 2018-11-26 10:05:34 UTC
Addendum: If I had read the Original Post more carefully I would have realized that it was due to GPG errors on some repos but at least I figured out that it was some kind of permissions problem (in my case).

Comment 5 Prasanna V. Loganathar 2018-12-01 21:03:48 UTC
This has been the case for me as well since Fedora 28. This is a rather frustrating bug depriving me of package name completion. Happens every time with `dnf install *<TAB>`

Comment 6 Kostya Vasilyev 2018-12-07 21:35:46 UTC
Same problem here since Fedora 29 (clean install).

My custom repos do not include Atom, but I do have some.

Comment 7 Kostya Vasilyev 2018-12-07 21:43:34 UTC
Thank you Simon for the tip about permissions on GPG files.

In my case it was

$ sudo find /var/cache/dnf/ -name "*.gpg"
/var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gp

$ ls -l /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg
-rw-------. 1 root root 1200 Nov  2 14:04 /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg

Aha!

chmod go+r $ ls -l /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg

and the problem went away.

Open H264 is included in base Fedora 29 install as far as I remember.

It's the only repository on my machine (in /etc/yum.repos.d) which has "repo_gpgcheck=1" (all the others have "...=0").

So maybe that's a workaround until the bugs are fixed, setting repo_gpgcheck=0.

In terms of fixing I think there are two takeaways here:

1 - If the gpg file's permissions are controlled by the repository itself - then they need to be fixed there, should I be filing a separate bug?

But most likely the .gpg file is created by dnf?

2 - If the gpg file is not readable, can dnf autocompletion be made to not hang like this?

Comment 8 Prasanna V. Loganathar 2018-12-09 23:54:13 UTC
The above comment hits the nail on the head. But doesn't quite cover all the files. 

```
$ sudo find /var/cache/dnf/ -iname "*.gpg" -exec ls -l {} \;
-rw-------. 1 root root 1200 Nov  3 16:27 /var/cache/dnf/fedora-cisco-openh264-debuginfo-faf9c4e066239216/pubring/trustdb.gpg
-rw-------. 1 root root 1200 Nov  1 00:12 /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg
```

That's the default repos with fedora with incorrect perms. So, running this should fix it up.

`sudo find /var/cache/dnf/ -iname "*.gpg" -exec chmod go+r {} \;`


And I also agree that if the gpg file is not readable `dnf` autocomplete should still work with the ones it can read, while displaying a warning on stderr which files aren't readable.

Comment 9 Kostya Vasilyev 2019-04-25 16:37:56 UTC
> while displaying a warning on stderr which files aren't readable

Please "no" on this one. A repo with gpg enabled should "just work".

Comment 10 Tom Seewald 2019-07-29 04:29:25 UTC
This bug is still present in Fedora 30, with dnf-0:4.2.5-2.fc30.

Comment 11 Jan Beran 2019-08-16 11:57:58 UTC
*** Bug 1648686 has been marked as a duplicate of this bug. ***

Comment 12 Jan Beran 2019-08-16 12:46:04 UTC
*** Bug 1674432 has been marked as a duplicate of this bug. ***

Comment 13 gutsmv 2019-10-20 03:23:43 UTC
One fast workaround I found is:
-Symlinking /usr/bin/dnf to /usr/bin/yum (as Fedora doesn't have yum installed by default).
-Then use the yum command instead.
Works in CentOS 8, RHEL 8 and Fedora 31 Beta with Sat 19 Oct 2019 "non testing" updates.

This is more than likely a bash-completion related problem with how the dnf completions are written, rather than permissions with new repos.

Comment 14 Ben Cotton 2019-10-31 18:43:19 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Kamil Páral 2019-11-01 08:41:10 UTC
I still have the same extra repo in comment 0, and I have root-only readable cache files:
$ ll /var/cache/dnf/Atom-e10748eea27cca31/pubring/trustdb.gpg
-rw-------. 1 root root 1.2k Aug 21  2018 /var/cache/dnf/Atom-e10748eea27cca31/pubring/trustdb.gpg

But the package name completion now works for me. Perhaps it was fixed recently?

dnf-4.2.11-2.fc30.noarch

Comment 16 Ben Cotton 2019-11-27 18:08:17 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.