| ▲ | fweimer a day ago |
| Well, OpenOffice wouldn't print on Tuesdays: “
What a fascinating bug!! My wife has complained that open office will never print on Tuesdays!?! Then she demonstrated it. Sure enough, won't print on Tuesday. Other applications print. I think this is the same bug. Here is my guess: Print to a postscript file. Observe the line:
%%CreationDate: (Tue Mar 3 19:47:42 2009) Change "Tue" to anything else:
%%CreationDate: (XTue Mar 3 19:47:42 2009) Save the file and it prints. Tools like evince work because they simply omit the "CreationDate" tag to begin with. Now something odd happens when my cups script (I am using the Brother MFC420CN) copies the file to a temp file. Some of the code is rearranged, not sure how or why, but it uses a command called "file" to identify the file as "PostScript". This check would work on the original file you printed, but by the time it runs the check on the temp file, it misidentifies. Normally it would return: PostScript document text conforming at level 3.0
But there is another check that happens before the PostScript check. If it finds "Tue" at the fourth byte of the file, it identifies it as: Jan 22 14:32:44 MET 1991\011Erlang JAM file - version 4.2
So it's not a problem w/ openoffice.org, cups, or the brother printer drivers. It is a bug in the `file` utility, and documented at https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619.
”https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161... |
|
| ▲ | h1bslop a day ago | parent | next [-] |
| these types of bugs are epic. often due to people trying to mix and match date and int math |
|
| ▲ | redbell a day ago | parent | prev | next [-] |
| This was one of the funniest humor stories in software history. You can find some submissions about the topic here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... |
|
| ▲ | askvictor a day ago | parent | prev | next [-] |
| But "Tue" is not at the fourth byte of the file in your example |
|
| ▲ | TacticalCoder a day ago | parent | prev | next [-] |
| > It is a bug in the `file` utility OK but although I love the file utility, why does OpenOffice and/or CUPS rely on it to... print a file that ends with the .ps extension? It's kinda begging for troubles. |
| |
| ▲ | SpaceNoodled a day ago | parent | next [-] | | Assuming file type by name rather than by contents opens a whole 'nother can of worms. | | |
| ▲ | Sprocklem 20 hours ago | parent | next [-] | | I can't figure out why anyone would need to detect the file type at all. Surely there should be some way for that to be passed into cups (and forwarded on, as necessary) out of band, by the program that created or opened the file and knows what its type is. | |
| ▲ | merb a day ago | parent | prev | next [-] | | Tbf magic bytes are also not that helpful here | |
| ▲ | yrjrjjrjjtjjr a day ago | parent | prev [-] | | Content injection vulnerability is bad, and that's the core of what sniffing does. Failing randomly like in this case is mild in comparison. Like I get that sometimes you have to do what you have to do, but sniffing should be a last resort. | | |
| ▲ | Someone a day ago | parent [-] | | Why would a tool that runs any program sent to it on a device it doesn’t know about be that concerned about being sent an invalid program? An attacker might send a file that orders for millions of dollars of pizzas, using the fax hardware built into the printer (I’m not sure you can buy postscript printers that can fax today, but you can buy printers that can fax even today) | | |
| ▲ | M95D 5 hours ago | parent | next [-] | | That's not how a printer with a fax/modem works. If the printer endpoint of the USB device receives a file that orders millions of pizzas, it will print the file (or print a PS error, or print the plaintext contents of the file), not order pizzas. If the user mistakenly "prints" to the fax device, the file will be printed at the destination fax machine, at the number the user typed, not the number in the file, and it will print, not order pizzas (unless the pizzeria accepts fax orders, which would be a prank, not an attack). | | |
| ▲ | Someone 2 hours ago | parent [-] | | > That's not how a printer with a fax/modem works. It is how at least one of them works, and how I assumed all of them work. http://www.whoopis.com/howtos/laserwriter16-600/LaserWriter_...: “FaxOptions Dictionary This dictionary contains parameters that direct fax transmissions from a PostScript language program. Refer to “Fax Parameters” on page 29 for further information about FaxOptions defaults and the keys found in this dictionary” Google tells me this is what you needed in your PostScript file to send a fax: <<
/OutputDevice /Fax
/FaxOptions <<
/DialCallee (555-0199)
>>
>> setpagedevice
And I don’t think Apple was unique in having fax support in their PostScript. https://web.mit.edu/PostScript/Adobe/Documents/5001.DSC_Spec... mentions faxing, too (but doesn’t appear to say how to accomplish it) |
| |
| ▲ | yrjrjjrjjtjjr 15 hours ago | parent | prev [-] | | I'm having trouble understanding your question in the context of the discussion, so I will talk about the topic generally instead. Imagine a server allows you to upload images. It has a system designed for images only. It will behave unpredictably maybe even dangerously with another file. The server checks that the file ends with .jpg. it checks that the file is a valid jpeg. All clear. Upload allowed. But 5 steps later some tool looks at the image file and notices it's a valid zip file (creating files with multiple valid interpretations is something people have succeeded in doing it's not always so hard). It runs this check before the image check. The next step in the processing chain wants an image but it has been told it's dealing with a zip file. So it unzips the file to see if it contains an image. But it was a zip bomb. The server goes down. |
|
|
| |
| ▲ | pseudohadamard 15 hours ago | parent | prev [-] | | CUPS depends on, and is a dependency for, half the OS for some reason. At least under Ubuntu, if you've got a machine you're planning to decommission, try: `sudo apt purge libcups*` NB, don't do this on a system you're planning to keep operational, this will autoremove half the OS if allowed to run. |
|
|
| ▲ | glitchc a day ago | parent | prev | next [-] |
| Thank you for sharing such a brilliant bug. |
|
| ▲ | ssl-3 a day ago | parent | prev | next [-] |
| That's really neat. But now, I really want to know why my office suite needs to tell my printer what day of the week it is. If the printer is smart enough to make use of that kind of information, then isn't it also smart enough to sort that out on its own? If so, then it seems superfluous. |
| |
| ▲ | arcfour a day ago | parent | next [-] | | Doesn't seem to me like it is telling the printer what day of the week it is because the printer needs to know so much as it is generating a PostScript file for the printer to use and is adding the creation date as either a convention or requirement of the format, and not the printer. | | |
| ▲ | gpvos a day ago | parent | next [-] | | Not a requirement, but indeed more of a convention or at least a possibility. Postscript files can be postprocessed or read by humans, and then this kind of metadata can be useful. | |
| ▲ | ssl-3 a day ago | parent | prev | next [-] | | Other things were reported to successfully be printed on Tuesdays, so that inclusion (or at least, this form of it) is empirically unnecessary. And the whole CreationDate field is optional in PostScript[1], anyway. [1]: https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf | | |
| ▲ | notatoad a day ago | parent [-] | | >so that inclusion empirically unnecessary this seems like a post-rationalization. when an app generates a file to send to another service, it's usually a good practice to timestamp that. unless you're severely bandwidth-constrained, putting a timestamp in your protocol almost always solves more problems than it creates. "we shouldn't include a timestamp because it might at some point trigger a date-math bug" is just not how software gets built. | | |
| ▲ | adrianN a day ago | parent [-] | | Maybe we should think about building software in a way that only adds stuff that is truly necessary. | | |
| ▲ | swsieber a day ago | parent | next [-] | | I have. I don't like it. I'd rather have the ability to debug, redundant checks, etc. than only what's truly necessary. | |
| ▲ | notatoad a day ago | parent | prev [-] | | if this bug was caused by a lack of a datestamp instead of the inclusion of one, you'd be here leaving comments about how silly it was they didn't include something as standard and widely useful as a datestamp, and that of course that was necessary. | | |
| ▲ | M95D 5 hours ago | parent [-] | | A datestamp is a privacy risk. If it's optional, don't include it. If it's not optional, it's a spec bug! It should be optional. Or even better, removed entirely. |
|
|
|
| |
| ▲ | bombcar a day ago | parent | prev [-] | | Exactly, it was using the file utility to determine what it was so it could print it correctly (by processing it if needed to a format the printer understood) and there was a bug in that. | | |
| ▲ | bitwize a day ago | parent [-] | | This is one of those "VLC is slow to start because of a bug in Windows" things. It's VLC's responsibility to ensure their program runs properly on the OS people actually have. It's LibreOffice's responsibility to ensure that their files print on Tuesday irrespective of bugs in CUPS (which ships with the Mac). | | |
|
| |
| ▲ | olalonde a day ago | parent | prev [-] | | Can be useful to distinguish when a print job was submitted from when it was actually received by the printer. That distinction matters when printers go offline and jobs get queued. | | |
| ▲ | ssl-3 a day ago | parent [-] | | Is it possible or practical to examine a printer's internal queue for jobs that might include this (completely optional) CreationDate field? If not, then: I'm not sure that the distinction means anything. :) | | |
| ▲ | olalonde a day ago | parent [-] | | Yes. Many printers have a web interface where you can see active jobs, job history, timestamps, and document information. Some even have a physical control panel that lets you inspect this information directly from a touchscreen. | | |
| ▲ | ssl-3 a day ago | parent [-] | | Right. But none of that comes from the CreationDate field of a postscript job. | | |
| ▲ | olalonde 19 hours ago | parent | next [-] | | Seems you learned a lot about printers since asking your question. By the way, it's mentioned in a number of printer manuals, so it's definitely used, e.g.: https://www.scribd.com/document/899003124/Magicolor-2200-use... | | |
| ▲ | ssl-3 4 hours ago | parent [-] | | Which part of that manual relates to a CreationDate field within a postscript print job? I'm not seeing it. |
| |
| ▲ | arcfour 20 hours ago | parent | prev [-] | | Are you sure? I would be more surprised if it did not come from there, if the field was present at all. You're already processing the PostScript... Might as well use the metadata. | | |
| ▲ | ssl-3 19 hours ago | parent [-] | | I'm sure that every print queue I've ever used didn't appear to care a lick about the content beyond acceptance. It's a buffer, not a processor. |
|
|
|
|
|
|
|
| ▲ | k0morebi a day ago | parent | prev | next [-] |
| This is up there with the "wifi only works when it's raining" story |
|
| ▲ | cyberpunk a day ago | parent | prev | next [-] |
| I miss Joe Armstrong. |
|
| ▲ | ivanche a day ago | parent | prev | next [-] |
| Sure, Ubuntu bug from 2008 (!) exposed in an abandoned project must be super relevant for LibreOffice in 2026. |
| |
| ▲ | arcfour a day ago | parent | next [-] | | I think it was intended to be a humorous anecdote playing off of the original joke, and not an indictment of LibreOffice or any other OSS. | |
| ▲ | colejohnson66 a day ago | parent | prev [-] | | LibreOffice is based on OpenOffice. OP was also (almost certainly) being tongue-in-cheek. |
|
|
| ▲ | monegator a day ago | parent | prev [-] |
| reminds me of the "email fails over 500 miles" bug lol |
| |
