Description of problem: Anaconda exception handler propose to report a bug and include various details. It include, among other things, full kickstart data, including LUKS passphrase in plain text. Version-Release number of selected component (if applicable): anaconda-25.20.9 How reproducible: Every time when installation fails. Steps to Reproduce: 1. Start installation, choose to encrypt the disk, set LUKS passphrase 2. Have something that cause installation fail (for example broken media) 3. Scroll through bug report details to the kickstart data Actual results: LUKS passphrase is visible in plain text, on the screen, and is proposed to be included in actual bug report Expected results: LUKS passphrase is obfuscated or removed (like later in /root/anaconda-ks.cfg - see #868519) Additional info: This was originally reported for Qubes OS 4.0, which use anaconda from Fedora 25: https://groups.google.com/d/msgid/qubes-users/d18652f0-d300-4b92-99c0-a0ecedd93d11%40googlegroups.com According to the anaconda repository state as of today, it also apply to the most recent version.
Can you specify in more detail where exactly does the plaintext LUKS passphrase show up ? In the traceback file or somewhere else ? Also do I understand it correctly you see the plaintext of the passphrase you have interactively entered in the GUI, not a LUKS passphrase set via kickstart ?
(In reply to Martin Kolman from comment #1) > Can you specify in more detail where exactly does the plaintext LUKS > passphrase show up ? In the traceback file or somewhere else ? Yes, in the traceback. As part of _intf.data - where full kickstart data is included: _intf: GraphicalUserInterface instance, containing members: _intf._isFinal: True _intf._actions: Skipped _intf._ui: None _intf.data: #version=DEVEL #System authorization information auth --enableshadow --passalgo=sha512 (...) autopart --encrypted --passphrase="verystrongpass" --type=thinp (...) > Also do I understand it correctly you see the plaintext of the passphrase > you have interactively entered in the GUI, not a LUKS passphrase set via > kickstart ? Yes, entered interactively.
(In reply to Marek Marczykowski from comment #2) > (In reply to Martin Kolman from comment #1) > > Can you specify in more detail where exactly does the plaintext LUKS > > passphrase show up ? In the traceback file or somewhere else ? > > Yes, in the traceback. As part of _intf.data - where full kickstart data is > included: > > _intf: GraphicalUserInterface instance, containing members: > _intf._isFinal: True > _intf._actions: Skipped > _intf._ui: None > _intf.data: #version=DEVEL > #System authorization information > auth --enableshadow --passalgo=sha512 > (...) > autopart --encrypted --passphrase="verystrongpass" --type=thinp > (...) > > > Also do I understand it correctly you see the plaintext of the passphrase > > you have interactively entered in the GUI, not a LUKS passphrase set via > > kickstart ? > > Yes, entered interactively. Thanks - that look like a bug in the traceback filtering code. IIRC there should be filters in place to both remove unnecessarily verbose stuff and sensitive items like the LUKS passphrase.
There is some filtering in pyanaconda/exception.py initExceptionHandling(), but it applies to whole attributes - here, the passphrase is part of _intf.data attribute which is reported as a whole string. The easiest fix would be excluding _intf.data entirely, but that would also make bug reports slightly less informative...
(In reply to Marek Marczykowski from comment #4) > There is some filtering in pyanaconda/exception.py initExceptionHandling(), > but it applies to whole attributes - here, the passphrase is part of > _intf.data attribute which is reported as a whole string. > The easiest fix would be excluding _intf.data entirely, but that would also > make bug reports slightly less informative... Let's do that for now: https://github.com/rhinstaller/anaconda/pull/1263
Should be fixed once anaconda-28.13-1 hits the Rawhide compose. :)
The fix should be part of the current Rawhide nightly composes. Could you verify all is fine now ? :)
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Looks fine.
Based on the comment 9 I'm closing this issue.