Bug#880877: reportbug: leak user private information in the SMTP log
Package: reportbug
Version: 7.10.3+deb11u1
Followup-For: Bug #880877
X-Debbugs-Cc: debbug.880877@sideload.33mail.com
>> When reportbug is used as a direct SMTP client , reporting user
>> hostname , ip and username are leaked to the BTS.
>
> well, that's how mail transport systems work
Different MTAs work differently.
Regarding the hostname, that is a configurable parameter in
postfix. It can be whatever the user sets it to.
Regarding IP, all MTAs inherently know the IP but some
privacy-respecting MTAs strip out the IP to protect the sender’s
privacy from the recipient. This is crtically important when email is
not merely going to the inbox of an individual but rather being
published to the world. It’s reckless to expose that sensitive
information.
The MTA is one place where this leak can be addressed, but it’s not
the only place. IIUC, bugs are processed by procmail, which means a
procmail recipe also has the opportunity to strip out the sender’s IP
address.
>> Such information leak is not expected (and undesirable). That
>> information is passes under Message-ID (hash-reportbug@users-fqdn)
>> and in the Received: from section.
>
> this is generated by a standard python function
>
> reportbug/submit.py: message['Message-ID'] =
> email.utils.make_msgid('reportbug')
While it’s interesting to know that a standard lib fails to give the
user control over what elements are used for the composition of the
msg id, this does not excuse the leaking of sensitive info. Use of
that library call is optional. IIRC, the RFC does not dictate what
info appears in a msg id, only that the msg id is sufficiently random
so as to facilitate uniqueness and avoid duplicating another msg id.
> this is all expected.
Certainly not. It’s expected that a mainstream project like Debian be
on the ball about safeguarding sensitive info. IP address & other
unique IDs can go in the logs if Debian needs the info for abuse
control, but it’s embarrassing that a reputable distro would publish
that info for the world.
> what i think your report is missing is a concrete solution to address
> whatever you think it wrong. if you cant provide anything, i'm afraid i'm
> going to close this report, as i dont think any action is warranted.
This is a bug report, not a PR request. Bug reports do not need a PR
request to justify their existence.
-- System Information:
Debian Release: 11.4
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-16-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: