Those of us who frequent Reddit probably noticed a minor scare w.r.t. the `stardict` package, which was noticed uploading arbitrary clipboard contents to remote servers over unencrypted HTTP connections. [1] [7] This appears to have been sparked by a bug report against stardict [2] and a subsequent thread on the topic on the debian-users mailing list [2]. The bug report itself is closed and the issue fixed in Trixie, but I don't think the issue with Stardict is fully dealt with. The issue itself, for those who don't know, is that Stardict watches all X selection buffers, and attempts to do a dictionary lookup on their contents. This means that any time the user: * selects any text in most (all?) applications, * copies text to the clipboard, or * otherwise changes one of the selection contents (i.e. using `xclip -selection XA_SECONDARY`), StarDict will immediately do a dictionary lookup for whatever happens to be selected. This is all well and good, looking things up from a dictionary when they are selected sounds like a useful feature. In its default configuration, Stardict > Home > Preferences > Network > Net Dict shows an unchecked "Enable network dictionaries" checkbox, which indicates to me that no network connections will be made as part of these dictionary lookups. This settings page also says rather prominently, "Warning: Requests to remote StarDict server [sic] are sent over the network in an unencrypted form. Do not enable this if you are translating sensitive documents." So not only is Net Dict not enabled, I'm also warned to not enable it. Thus I should reasonably expect that my clipboard contents will not be sent over the network unencrypted. Unfortunately this is not the case. The following steps reproduce the clipboard leak on Debian 13 and Debian 12 (but thankfully not on Sid now that the bug is fixed there): * Install Stardict (`sudo apt install stardict`) * Install Wireshark (`sudo apt install wireshark`) * Run Wireshark (`sudo wireshark`, then capture traffic from the `any` interface) * Run Stardict (`stardict`) * Select some text in any window (for instance, select the words "If the query word" in the Stardict window) * See a dictionary popup that shows info being loaded from a remote dictionary * Go to Wireshark, and find HTTP connections that were made when you selected the word * See that there are GET requests for two web URLs with the words "If the query word" embedded This is the bug described in [3]. The main reason this is an issue is because people frequently have highly sensitive data going through their clipboard. For instance, anyone who uses KeePassXC will have their passwords leaked to the aforementioned servers over unencrypted HTTP if they use the "Copy password to clipboard" button rather than the KeePassXC browser extension. If I create a new password entry in KeePassXC with a dummy randomly generated password, then click the "Copy password to clipboard" button while Stardict is running, I immediately see a network-based dictionary lookup for the password occur, which I think is bad for obvious reasons. As explained above, Stardict doesn't just sniff the clipboard - any text the user selects, copies, or otherwise puts through one of the X selections ends up forwarded to the previously mentioned websites as a dictionary lookup query. Thankfully Stardict is rather overt about what it's doing, given that it shows the website name in the lookup popup it creates. But this is still very bad IMO, mainly because Stardict doesn't do nearly a good enough job of telling the user this is going to happen *before* it happens. The welcome text displayed upon opening Stardict claims that "After selected [sic] some text, clicking the middle mouse button on the main window's Definition area or on the notification area icon will look up that word." The Preferences menu, as described earlier, explicitly says that Net Dict is disabled. It's difficult to argue that a user would reasonably know that their clipboard contents are going to be sent unencrypted to a server they probably don't trust until it's already happened. If a user installs and launches Stardict, then goes to log into their email before doing anything else, and ends up copying their password to the clipboard in the process, their email password just went out unencrypted over the network, and now said user gets to change their email password and probably the passwords for all accounts bound to that email. Most of the above is just context and pointing out that this is a problem in all stable releases of Debian. Arguably this can just be fixed in those releases also. The core issue I want to point out in this email is that this is not the first time Stardict has been leaking things to the network. * In 2009 a bug report was made [4] warning that "Enable net dict" was enabled by default, resulting in arbitrary clipboard data being uploaded. This was fixed in stardict 3.0.1-5. * In 2011 the issue resurfaced, this time due to a remote dictionary plugin, resulting in another bug report [5]. This was closed without resolution. * In 2015 someone else noticed the issue from 2011 and re-reported it [6]. This was then closed in 2020 because Stardict was removed from Debian unstable for some reason. * In December 2021 someone noticed Stardict was back in Debian Sid, and re-opened the bug report from 2015 asking that someone try to reproduce it with the latest Stardict. The bug did still exist, and was fixed in August 6, 2025, in stardict 3.0.7+git20220909+dfsg-7. * While the previous bug report was still simmering, the latest one appeared on August 4, 2025 [2]. This was fixed promptly, on August 11, 2025, in stardict 3.0.7+git20220909+dfsg-8. * And finally today, I'm here to raise awareness that it is still happening on both Bookform and Trixie. It appears Stardict has a pretty long track record of uploading arbitrary text selections and clipboard contents to untrusted third party servers over unencrypted connections. I personally don't believe this is the result of malicious behavior from upstream or the package maintainers, but... I don't know how to stress strongly enough that uploading end-user passwords to random servers - anyone's servers - is absolutely not acceptable. I use KeePassXC every day and constantly have passwords going through my clipboard. I know individuals who store their passwords in a text file on their computer, who have their passwords going through their clipboard frequently also. I sometimes end up with financial data (card numbers) being selected for one reason or another, which would be enough to make Stardict send those in cleartext over the network. This is profoundly unsafe. Even if a user was fully aware that Stardict acted like this and chose to use it anyway, they could forget it was still running before trying to log into an account, and only notice it was still running when they saw the dictionary popup, at which point the password is already leaked. If a user intentionally configures this and shoots themselves in the foot with it, that's their problem, but if it's the default configuration, that's hard to argue. On top of this, looking through the linked bug reports, oftentimes individuals have remarked that fixing these bugs appears to be difficult (apparently setting Stardict's default configuration is hard). If Stardict's default configuration is highly unsafe (as argued above), it's hard to fix, and the difficulties in fixing it have resulted in these issues being mostly unsolved for years, I don't think it's wise to believe this issue is going to be solved for good, at least not in the near future. Even if it is fixed in Forky for now, it seems likely to me it will resurface in the future and be similarly hard to fix (probably whenever upstream introduces another network-based dictionary plugin that is enabled by default, which has a good chance of happening if upstream picks up development again as seemingly dormant projects oftentimes do). The Debian Policy manual states in section 2.2.1: > In addition, the packages in main > ... > * must not be so buggy that we refuse to support them... I would argue Stardict is this buggy. The maintainers may not be willfully refusing to support the application, but the state of the application is the same as if the maintainer(s) refused to support it for many years. The bugs also show that the maintainers may not fully realize the severity of the issue, as bug reports that have their severity reasonably set to "grave" or "serious", are being set to severity "normal" or "wishlist". Given that the program is effectively acting as an info stealer unless explicitly configured otherwise, this is baffling to me. IMO, Stardict could reasonably live on in contrib, if a warning of some sort is put on it that the user *must* double-check their configuration before using their computer after launching Stardict, to ensure clipboard contents and text selections will not be sent over the network. But I don't think Stardict is suitable for inclusion in Debian's main archive, in any existing or future stable release of Debian. I'd like to request the FTP masters to consider whether moving Stardict to contrib and adding something along the lines of an apt news snippet is warranted given the above context. (In case the security team or other Debian developers are interested in giving feedback, I also sent this to the security team and debian-devel list.) -- Aaron p.s.: I intentionally redacted the names of the websites linked to by the dictionary plugin, since GMail rejected my email the first time I tried to send it, and I'm guessing one of those sites being referenced triggered some spam rejection thing. [1] https://www.reddit.com/r/linux/comments/1mipw7q/stardict_plugins_on_debian_13_leak_selected_x11/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110370 [3] https://lists.debian.org/debian-user/2025/08/msg00075.html [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613236 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 [7] https://lwn.net/Articles/1032732/
Attachment:
pgpmdFWUFRwM3.pgp
Description: OpenPGP digital signature