Package: reportbug Version: 7.10.3+deb11u1 Followup-For: Bug #880877 X-Debbugs-Cc: debbug.880...@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