Bug#1016009: reportbug: Paranoid mode shows base64 instead of human readible text
Package: reportbug
Version: 7.10.3+deb11u1
Followup-For: Bug #1016009
X-Debbugs-Cc: debbug.reportbug@sideload.33mail.com
Control: tags 1016009 + a11y
You have misunderstood the purpose of the --paranoid option. The
purpose of this option is to enable users to mitigate data leaks by
checking the information being sent for publication. Hiding the
payload works contrary to this purpose and undermines the user’s
request. By hiding the msg payload in an encoded container you /block/
users from verifying what information is being transmitted for
/publication/.
The status quo is dangerous as it ensures that only highly motivated
users will actually go though the decoding hoops.
The current behavior is also ableist as it hinders anyone using a
screen reader & it also needlessly imposes a higher level of
competency on users to recognize the base64 text and convert it.
> If they are not interested in this then they don't need to use the
> option. The option is deliberately named "--paranoid" and disabled by
> default.
The current behavior only serves users who are interested in the
metadata, and disservices users who are interested in reviewing /all/
information being transmitted. Base 64-encoded text is not
reviewable. A user who wants to fully review the payload currently
must copy-paste encoded text into another file, one screenfull at a
time, taking care not to miss any lines or duplicate any lines, filter
out the whitespace, and separately filter the text through an external
tool. It’s impossible for non-GUI users to do this and absurdly
tedious and impractical for GUI users.
> If you want to check the human-readable message text before
> submission, there are already menu entries to print the message to
> stdout or view it in a pager. You don't need the --paranoid option
> for this.
Those options are only available prior to final processing by
reportbug. Reportbug does further manipulation to the bug report
/after/ the user submits (e.g. like adding a msg ID header). While
it’s likely that the final stage of processing only affects headers &
not the encoded portion, it’s unreasonable to expect users to trust
that. And trust is an understatement because unless the user actually
reads the source code, they can only speculate that the payload body
would not be altered in the final processing step.
Please reopen this ticket.
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reportbug depends on:
ii apt 2.2.4
ii python3 3.9.2-3
ii python3-reportbug 7.10.3+deb11u1
ii sensible-utils 0.0.14
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail <none>
pn debconf-utils <none>
pn debsums <none>
pn dlocate <none>
ii emacs-bin-common 1:27.1+1-3.1
ii file 1:5.39-3
ii gnupg 2.2.27-2+deb11u2
ii postfix [mail-transport-agent] 3.5.13-0+deb11u1
ii python3-urwid 2.1.2-1
pn reportbug-gtk <none>
ii xdg-utils 1.1.3-4.1
Versions of packages python3-reportbug depends on:
ii apt 2.2.4
ii file 1:5.39-3
ii python3 3.9.2-3
ii python3-apt 2.2.1
ii python3-debian 0.1.39
ii python3-debianbts 3.1.0
ii python3-requests 2.25.1+dfsg-2
ii sensible-utils 0.0.14
python3-reportbug suggests no packages.
-- no debconf information
Reply to: