4 ms·

It was Xscreensaver, written by JWZ. He was pissed that debian distributed old versions, so he put in a timebomb that would make it stop working on a certain da

It was Xscreensaver, written by JWZ. He was pissed that debian distributed old versions, so he put in a timebomb that would make it stop working on a certain date. I kinda forget the details, but still I wouldn't consider this malware, it's not something you would worry about trying to exfiltrate credentials, run a cryptominer, open a backdoor shell, etc. It just disables itself with a taunting message, harmless really. Another famous case was when debian patched OpenSSL to fix an uninitialized-memory compiler warning, way back 20 years ago, and other than PID this was the only entropy mixed in before generating keys at the time, so there was a couple months when only 65535 different ssh keys could be generated on such systems, and it's pretty easy and fast to just check them all. Still today (or until very recently) there was a special check to reject usage of such set of weak keys that were generated in those ill-fated 2 months. Still, really nothing like malware. Just a huge security bug. Those happen occasionally (e.g. heartbleed, not debian specific ofc). So like 2 notable cases of less-than-optimal software prepared for users by the debian project? But not malware.

eesmith 3y ago
> he put in a timebomb that would make it stop working on a certain date I wrote 'some Debian developers have characterized [it] as having a "timebomb"'. because I do not agree with that assessment. It did not actually stop working on a certain date. It displayed a warning dialog box on the screen saver lock screen saying the package was out of date. Here is the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 Here is the relevant code: https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2bbe6e852e17989135d762d/driver/demo-Gtk.c#L5295 https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2... Nothing there about no longer working. (If "stop working on a certain date" makes something a time bomb, then expired certifications are certainly in Debian, like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 linking to https://bugs.chromium.org/p/chromium/issues/detail?id=664177 https://bugs.chromium.org/p/chromium/issues/detail?id=664177 "the [Certificate Transparency] information has a built-in build-time bomb of 10 weeks".) Okay, "time bombs" are not malware. Got it. My main point remains, Linux distributions handle far fewer packages than PyPI. "Debian comes with over 59000 packages" says https://www.debian.org/intro/about https://www.debian.org/intro/about and PyPI has 455,474 projects says https://pypi.org/ https://pypi.org/. Can Debian developers handle 7x more packages? Almost certainly not. They couldn't even handle my software. If a package maintainer already can't detect a "time bomb" with a huge warning message in the code, then why should I believe they are able to detect more subtle malware, especially with a 7x higher maintenance load? I write specialist software with only a few thousand users world-wide. Do you really think each of the distros will have the people who are able to review and integrate my code into the distro at the same level as they do xscreensaver? More realistically, they will reject my package as being out of scope, leaving me ... back at PyPI.
- ploxiln 3y ago
  ... or leaving you at GitHub (or GitLab, or SourceHut). You can pip install a git repo directly, and specify tag, or a hosted release tarball. If only the ~ 10k most used python packages were available from pypi, and the more niche ones had to be more directly referenced from their own repos or websites, I'd be fine with that. I'm accustomed to that for C libraries, distros provide the most common/core few thousand of them, the rest you can get yourself, it's doable. Minimize your dependencies, its better engineering anyway.
  - eesmith 3y ago
    Does the lack of comment about "time bomb" mean anything regarding your misapprehension that the xscreensaver code made the program stop working on a certain date? I meant 'PyPI' as synecdoche, yes, for a large number of alternatives which cannot meaningfully be described as "reinventing Linux distributions". Those three quoted words were bscphil's claim. My counter-claim is we are not, and further, the approach Linux distributions use is not able to handle what people already use PyPI for. > and the more niche ones had to be more directly referenced from their own repos or websites These are still not "reinventing Linux distributions". > If only the ~ 10k most used python packages were available from pypi, and the more niche ones had to be more directly referenced from their own repos or websites How do you determine the top ~10K if some 450K packages are distributed across a variety of platforms? If a package leaves the top-10K, is it removed? How much breakage will that cause? Or, once it reaches the 10K level, does it stays on PyPI forever? Why do you think this will result in reducing the amount of malware? Seems to me it opens the attack surface, and makes it harder for anti-malware scanners to get a good oversight of the large portion of what people use. > distros provide the most common/core few thousand of them Are you sure you aren't agreeing with me? The Linux distros are already unable to manage the packages in my field. That's why "reinventing Linux distributions" will not work, if forced to scale up 7x and handle niche area. That's why people use other methods, like PyPI and Anaconda, to handle what the distros cannot.

eesmith 3y ago

> he put in a timebomb that would make it stop working on a certain date I wrote 'some Debian developers have characterized [it] as having a "timebomb"'. because I do not agree with that assessment. It did not actually stop working on a certain date. It displayed a warning dialog box on the screen saver lock screen saying the package was out of date. Here is the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 Here is the relevant code: https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2bbe6e852e17989135d762d/driver/demo-Gtk.c#L5295 https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2... Nothing there about no longer working. (If "stop working on a certain date" makes something a time bomb, then expired certifications are certainly in Debian, like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 linking to https://bugs.chromium.org/p/chromium/issues/detail?id=664177 https://bugs.chromium.org/p/chromium/issues/detail?id=664177 "the [Certificate Transparency] information has a built-in build-time bomb of 10 weeks".) Okay, "time bombs" are not malware. Got it. My main point remains, Linux distributions handle far fewer packages than PyPI. "Debian comes with over 59000 packages" says https://www.debian.org/intro/about https://www.debian.org/intro/about and PyPI has 455,474 projects says https://pypi.org/ https://pypi.org/. Can Debian developers handle 7x more packages? Almost certainly not. They couldn't even handle my software. If a package maintainer already can't detect a "time bomb" with a huge warning message in the code, then why should I believe they are able to detect more subtle malware, especially with a 7x higher maintenance load? I write specialist software with only a few thousand users world-wide. Do you really think each of the distros will have the people who are able to review and integrate my code into the distro at the same level as they do xscreensaver? More realistically, they will reject my package as being out of scope, leaving me ... back at PyPI.

ploxiln 3y ago
... or leaving you at GitHub (or GitLab, or SourceHut). You can pip install a git repo directly, and specify tag, or a hosted release tarball. If only the ~ 10k most used python packages were available from pypi, and the more niche ones had to be more directly referenced from their own repos or websites, I'd be fine with that. I'm accustomed to that for C libraries, distros provide the most common/core few thousand of them, the rest you can get yourself, it's doable. Minimize your dependencies, its better engineering anyway.
- eesmith 3y ago
  Does the lack of comment about "time bomb" mean anything regarding your misapprehension that the xscreensaver code made the program stop working on a certain date? I meant 'PyPI' as synecdoche, yes, for a large number of alternatives which cannot meaningfully be described as "reinventing Linux distributions". Those three quoted words were bscphil's claim. My counter-claim is we are not, and further, the approach Linux distributions use is not able to handle what people already use PyPI for. > and the more niche ones had to be more directly referenced from their own repos or websites These are still not "reinventing Linux distributions". > If only the ~ 10k most used python packages were available from pypi, and the more niche ones had to be more directly referenced from their own repos or websites How do you determine the top ~10K if some 450K packages are distributed across a variety of platforms? If a package leaves the top-10K, is it removed? How much breakage will that cause? Or, once it reaches the 10K level, does it stays on PyPI forever? Why do you think this will result in reducing the amount of malware? Seems to me it opens the attack surface, and makes it harder for anti-malware scanners to get a good oversight of the large portion of what people use. > distros provide the most common/core few thousand of them Are you sure you aren't agreeing with me? The Linux distros are already unable to manage the packages in my field. That's why "reinventing Linux distributions" will not work, if forced to scale up 7x and handle niche area. That's why people use other methods, like PyPI and Anaconda, to handle what the distros cannot.