Steven D'Aprano <st...@pearwood.info> posted 499aba3d.8040...@pearwood.info, excerpted below, on Wed, 18 Feb 2009 00:23:09 +1100:
> Overheard in the boardroom of Ford Motor Company: > > "Oh no, you can't blame our SUVs for their poor fuel economy or for > producing vast amounts of carbon dioxide, carbon monoxide, nitrous > oxide, sulphur dioxide and benzene. It's not the fault of the SUV, it's > the fault of the *engine*." > > *wink* Yah, yah. > I'm actually relieved. It sounds like it's not a deliberate decision to > change the permission, just a bug caused by (inadvertent?) reliance on a > standard invented when programmers were even more trusting and naive > than they are now. In other words, an ordinary security hole, not a sign > of moral degeneracy :) I've been looking around. pan used some gmime stuff, but also includes its own copy of uudeview code, apparently modified to be used by pan. (Such "internal" versions are normally quite discouraged by the community, because if there's a security vuln, it's much more difficult to ensure all packages shipping internal versions of the same code are updated than it is to update a single system-wide shared version. However, if the modifications are big enough, upstream isn't cooperative, and there aren't any easily substituted alternatives, it may be necessary. I don't know why Charles ships it internal but perhaps he had to modify it for use as a library instead of as the stand-alone apps the package normally ships as.) uudeview is a uudecode/uuencode compatible replacement that handles yenc also. I have the package installed separately here. Anyway, the uudeview command includes a command line option -m. Here's the manpage bit on it (paragraph quote): Ignore file mode. Uuencoded and xxencoded files have the original file permissions stored on the begin line. Unless this option is given, UUDeview will restore them without checking if they are sensible. With this option, the permissions are reset to a default of 0666. I see the implementation of that option still in the code shipped with pan, but don't know how it relates to whatever functions pan might call or include from that code. I don't claim to be a C/C++ coder so there are limits to how well I can read and parse/interpret source. I also see this in the POSIX Programmer's Manual (man section 1P) entry for uudecode (partial paragraph quote): The file access permission bits and contents for the file to be produced shall be contained in that data. The mode bits of the created file (other than standard output) shall be set from the file access permission bits contained in the data; that is, other attributes of the mode, including the file mode creation mask (see umask()), shall not affect the file being produced. OUCH! According to that, even letting umask affect it is a violation of the POSIX spec! OTOH, it does have a Linux implementation disclaimer saying Linux behavior may be different or the interface may not exist... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
