Dear Maintainer, apparently according to this comment https://lwn.net/Articles/1080157/ people using xsnow in the wrong room could end up getting beaten up, or losing their job. I am opening this bug since the original reporter did not, but I do not think Debian users who happen to live in a country ruled by a government I personally disapprove of should face such severe consequences. Best
Hi, thanks for your comment. I am surprised by the fact that my 'protestware' in the toy program xsnow causes such a fuzz. On one hand, the protestware is noticed, and that is exactly I was aiming for. On the other hand, people are concerned that the items shown by xsnow can cause problems for the users of the program. I understand, but if a user sees items that could cause problems for him/her it is very easy to halt the program, remove it and don't use it any more. I am sure there are a lot of programs and web sites who's behavior could have negative consequences for the user, and xsnow is only one of them. So, what to do? - Debian can decide to remove the program from the repo. That is no problem for me. - I could put a version to Debian, without the protestware. I will do that when something is settled. Again, xsnow is just a toy, nobody needs to use it. Regards, Willem
Hello, just to be clear, I've been using xsnow for a long time and I had noticed the flags months ago. I only decided to join the discussion after I read that comment on LWN. It is something that I hadn't considered at all. This idea didn't even apply for the offensive fortunes package, which contained a clear description; xsnow does't even declare that this exists and while it allows to configure every single element, this one is an exception. Unfortunately when someone notices it might be too late, if someone else notices at the same time? Websites are not part of Debian and out of scope in the discussion. Agreed, and I use it (in winter) but the problem if what happens if someone who doesn't read LWN decides to run it. Best
severity: 1141182 serious thanks Hello Bill, What technical info do you believe is missing exactly? It's quite trivial to reproduce. See attached screenshot. If we remove things that might hurt somebody's feelings, shouldn't we also remove things that might cause people to be beaten up? IMHO getting beaten up sounds much worse than having my feelings hurt for 3 seconds by a bad joke. Best Il giorno mer 1 lug 2026 alle ore 00:02 Bill Allombert <ballombe@debian.org> ha scritto:
Hi, I still believe that the scenery surprises are not harmful, but I also take in consideration: - many people are worried about xsnow's behavior - some people are spending time on this issue, e.g. I noticed that Slackware distributes a patched version - the surprise is causing much more of a stir than intended So I will create a new version of xsnow, without the offending surprises and make a RFS. It would be very nice if the new version could make it directly to stable. If that is possible, how should I proceed to accomplish that? Thanks all, Willem
Hello, please email me the .dsc file and I can sponsor the upload to unstable. For stable new versions are not accepted, just patches which need to go through the proposed update procedure https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable If you have a small patch I can upload it. Best
Hi, While I’m not a user of xsnow, I’d like to comment on the issue being discussed. In addition to what has already been indicated during the discussion by Salvo Tomaselli, I would like to draw attention to a few fundamentally important points. I personally consider this case serious and the bug release-critical. The main problem is that the xsnow package contains hidden, intentionally obfuscated behavior that depends on geo/locale conditions. This functionality is not described in the documentation (man page, README, etc.) and is not discoverable through typical review methods. Although the current payload appears “benign,” the implementation follows a structural pattern associated with malware and undermines the open-source trust model. The core problem is intentional concealment, not whether the current payload is harmful in a “typical” sense. The relevant logic is obfuscated and is not reflected in the documentation or typical interfaces. While Debian states that its priorities are its users (#4 Social Contract), which I would interpret in this case broadly, the observed behavior of xsnow does not align with that. Moreover, since I wrote above that I consider such behavior a problem, and since it is obfuscated (at least, its behavior is not obvious from variable names, etc.), I would consider it a violation of #3 Social Contract as well, broadly interpreted. A key point is the precedent: if an obfuscated, undocumented feature slips through unnoticed once, it can slip through again—and we cannot know what payload it might contain next time. So, this case breaks trust. Also, the issue can be considered in the context of Debian’s Diversity Statement. While the statement primarily documents development, I suggest we interpret it more broadly as documenting Debian’s attitude toward its users. That is, Debian does not discriminate against users based on their language, geographical place in the world, nationality, or anything else. Here, however, xsnow treats its users differently based on their system’s locale. I’d like to stress that, while the xsnow maintainer and developer intentionally introduced the discussed behavior, their messages in the bug report indicate they are willing to cooperate and fix the issue. I consider that appropriate and worthy of trust. Moreover, I’m CC’ing the Community Team and Debian Leader because I’d like them to consider the issue and comment on it. We have Debian documents and policies that cover Debian members’ behavior regarding abusing, insulting, and so on. However, we definitely lack documents and policies concerning (sometimes benign) obfuscated behavior that can break trust in open source and the Debian community as a whole. I would suggest we may need to extend the Diversity Statement and/or add a new policy document, which would, of course, require further discussion. Regards, Lev
To Salvo Tomaselli: The location of the dsc file of the new version: https://mentors.debian.net/debian/pool/main/x/xsnow/xsnow_3.9.3-1.dsc The stable version needs only the deletion of one line. I can create a patch, but I need to know which file to patch. Please help me out. Willem
I see that xsnow 1:3.9.3-1 is marked for autoremoval from testing, but the offending code (xsnow: xsnow can cause users to get a beating) has been removed in this version. What can I do to prevent autoremoval?
Source: xsnow Source-Version: 1:3.9.3-1 Usually this is done by adding the text "(Closes: #1141182)" into the debian/changelog entry. This gets picked up by dpkg-buildpackage and then the archive software. Chris
If the many users support the author and want the new behaviour to stay then surely a description of the behaviour would be a better fix? If some software showed US flags based on location and the date of independence day then that would surely be fine. VLC shows a Christmas hat, undocumented? Te idea that documenting behaviour somehow prevents any threat of "—and we cannot know what payload it might contain next time" is completely false and has no standing. Analysing the open source code is how you deal with that. The idea that this discriminates on locale because a user will get a beating raises a question. Surely it is discriminating on the fact that a society is being extremely violent without good reason. The very reason of the objection of this bug report, in the first place. Giving someone a beating for their opinion or even someone elses opinion is outright wrong and should have no bearing on any discussion. I don't see why the author of this software is having his hand forced here against his will due to politics especially when most of us agree with the authors position.