Bug 2172891

Summary: reporter-bugzilla does not emit Prompt signals for passwords anymore
Product: [Fedora] Fedora Reporter: Marius Vollmer <mvollmer>
Component: libreportAssignee: Michal Srb <msrb>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 38CC: abrt-devel-list, abrt-sig, mgrabovs, michal.toman, mpitt, msrb
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: CockpitTest
Fixed In Version: libreport-2.17.8-1.fc38 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-03-15 00:16:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marius Vollmer 2023-02-23 12:35:41 UTC
Description of problem:

The org.freedesktop.reportd service used to emit a Prompt signal on a Task object that runs reporter-bugzilla when a password was required. This no longer happens and the Task gets stuck waiting for input that nobody will provide.

Version-Release number of selected component (if applicable):
libreport-plugin-bugzilla-2.17.6-2.fc38.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run the TestJournal-testAbrtReport test of the Cockpit CI suite.  I can try to provide more concrete steps if necessary.

Actual results:
Cockpit receives these Progress signals during the test but no Prompt signal
PROGRESS /usr/lib64/python3.11/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
PROGRESS   passwd = fallback_getpass(prompt, stream)
PROGRESS Warning: Password input may be echoed.

Expected results:
With libreport-plugin-bugzilla-2.17.4-1.fc37.x86_64 on Fedora 37, Cockpit sees two Prompt signals and no Progress signals:

PROMPT 4  (ASK_PASSWORD)
PROMPT 1  (ASK_YES_NO)

Comment 1 Marius Vollmer 2023-02-23 12:52:39 UTC
I see that /usr/bin/reporter-bugzilla is now a Python program that just calls getpass, while it used to be a C program that uses libreport_ask_password.  The latter presumably does the right thing to cause reportd to emit the expected Prompt signal.

Did someone accidentally replace the C version of reporter-bugzilla with the Python version? :)

Comment 2 Michal Srb 2023-02-23 14:22:46 UTC
This wasn't by accident -- Python version was the default implementation in Rawhide since August 2022 :)

This looks like a regression, we will take a look. Thanks for the bug report!

Comment 3 Michal Srb 2023-02-27 07:13:31 UTC
> 1. Run the TestJournal-testAbrtReport test of the Cockpit CI suite.  I can try to provide more concrete steps if necessary.

It would be really helpful -- could you please share those more concrete steps? . I think the fix should be trivial, but I am kinda surprised that nobody hit this problem up until now.

Thanks!

Comment 4 Marius Vollmer 2023-02-27 08:26:33 UTC
> but I am kinda surprised that nobody hit this problem up until now.

I would expect this test case to hit it: https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting  Is that something you can try easily?

I'll see if I can come up with a way to reproduce this in the CLI, via busctl etc.

Comment 5 Marius Vollmer 2023-02-27 08:39:16 UTC
(In reply to Marius Vollmer from comment #4)
> > but I am kinda surprised that nobody hit this problem up until now.
> 
> I would expect this test case to hit it:
> https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting

Or some variation of it. I am not familiar with these tests...

Comment 6 Michal Srb 2023-02-27 08:44:33 UTC
> I would expect this test case to hit it: https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting  Is that something you can try easily?

It doesn't. It uses a completely different path. In your case, you're trying to use ABRT via DBus/reportd. Which is definitely rare.

If we come up with a scratch build in Koji, would it be possible for you to test it in your CI?

Comment 7 Michal Srb 2023-02-27 10:04:40 UTC
Actually, even better: do you, by any chance, have a tmt plan that we could run ourselves? :)

Comment 8 Marius Vollmer 2023-02-27 10:22:42 UTC
Created attachment 1946688 [details]
Reproducer

Comment 9 Marius Vollmer 2023-02-27 10:24:07 UTC
(In reply to Michal Srb from comment #6)
> In your case, you're trying to use ABRT via DBus/reportd. Which is definitely rare.

Oh, I wasn't aware that this is rare. Should Cockpit move to a different API?

I have attached a little Python program that reproduces the bug for me.

Comment 10 Martin Pitt 2023-03-03 04:20:15 UTC
(In reply to Michal Srb from comment #7)
> Actually, even better: do you, by any chance, have a tmt plan that we could
> run ourselves? :)

Not right now, but this bug report triggered me to work on it. See https://github.com/cockpit-project/cockpit/pull/18437 . That is just hilariously uncooperative -- installing ABRT packages into a running TMT machine without a reboot just simply refuses to pick up a crash. In our own CI (where the cockpit ABRT tests run), it is pre-installed into our test VMs, and after a reboot it works. With a local `tmt run` in a VM it also works, just not in the TF EC2 instances. Perhaps you have an idea what goes wrong there.

Comment 11 Martin Pitt 2023-03-03 05:50:49 UTC
Michal: OK, I got the PR working. On Fedora 37, both tests pass: https://artifacts.dev.testing-farm.io/29329487-59b5-4d43-ba60-9da57062af84/

On F38 and F39 the TestJournal.testAbrtReport test fails due to this bug: https://artifacts.dev.testing-farm.io/f60ae1a8-ce74-4499-a67d-bba3f545f4c1/ . The other test TestJournal.testAbrtSegv passes.

So once that PR lands (hopefully today), you should be able to trigger the "basic" plan of cockpit's TMT tests.

Comment 12 Michal Srb 2023-03-03 06:09:01 UTC
Thank you both! :)

I think I have a fix here: https://github.com/abrt/libreport/pull/781 -- I used the reproducer from Marius to verify that libreport should be doing the right thing now.

Once the team reviews the pull request, I will let packit to push an update to Fedora. So hopefully it will land later today.

Comment 13 Fedora Update System 2023-03-03 10:36:31 UTC
FEDORA-2023-b5eeeb9670 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b5eeeb9670

Comment 14 Marius Vollmer 2023-03-03 19:01:06 UTC
(In reply to Michal Srb from comment #12)
> Thank you both! :)
> 
> I think I have a fix here: https://github.com/abrt/libreport/pull/781 -- I
> used the reproducer from Marius to verify that libreport should be doing the
> right thing now.
> 
> Once the team reviews the pull request, I will let packit to push an update
> to Fedora. So hopefully it will land later today.

https://github.com/abrt/libreport/pull/781 makes our TestJournal.testAbrtReport pass.  Thanks!

Comment 15 Fedora Update System 2023-03-04 02:34:42 UTC
FEDORA-2023-b5eeeb9670 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b5eeeb9670

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2023-03-15 00:16:38 UTC
FEDORA-2023-b5eeeb9670 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.