Heinrich Müller posted on Thu, 10 Nov 2011 08:43:44 +0000 as excerpted: > Btw, there's a gui option for the certificates now. Edit->Edit SSL > Certificates
I just updated for the first time since Nov 1. At b2069b3c8b680, everything seems to work fine with gmane at least, in ssl mode. It was nice getting the cert prompt, and later, checking the gui option you mention above. I did have an initial cert-setup hiccup, however, with pan segfaulting when I tried to accept the cert, but that was arguably my fault. The rest is a discussion of that and a resulting request. Background: Back some years ago, there was some discussion over an arguable security issue with pan at the time. If someone posted an attachment with the executable bit set (at least some encoding forms record and transfer standard Unix permission bits), pan was saving the attachment with the executable bit set as well. If a user then browsed the save dir and clicked on that attachment, some file managers would see the executable bit set and try to execute the file, no questions asked. Obviously that's the same sort of malware vector that has gotten MS and MS users into so much trouble over the years. The eventual result was a patch, now in pan mainline for some time, that stripped the executable bit. However, IIRC, that patch got dropped somewhere along the line, leaving users unprotected once again, before being added again. (Still background:) Meanwhile, I pointed out that umask was designed to prevent just this sort of issue, and confirmed with my own testing that a umask of 0137 did indeed have the desired effect. I added a umask 0137 line to the pan-wrapper scripts I already used (mainly in ordered to have several separate pan data and config dirs, as I've explained many times, but once I had the wrapper scripts, adding things such as this was easy! ), and posted the umask workaround to the pan list. I suppose a number of people ended up with wrapper scripts and an exe-bit-stripping umask back then, but over the years, they've probably bitrotted and I doubt many are using wrapper scripts, especially with exe-bit-stripping umasks in them, today. However, I DID feel a bit vindicated when someone pointed out that the patch had been dropped somewhere along the line, leaving users unprotected again, since I still had that umask set, thus confirming the wisdom of that old security saying, "defense in depth!" As a result, I was always protected. Now the problem: As I'm sure you know, the executable bit has a rather different meaning on directories than it does on files. As long as pan is using the same old directories it has used for years, with the executable/enter bit set, so it can access what's inside, no problems. BUT, twice recently I've been bit by this umask problem, first when pan created the encoding-cache dir and the umask killed the executable/enter bit on it, and now, when pan created the ssl_certs dir. In the first case, I just got a mystifying error when pan couldn't do the encoding it expected. With ssl_certs, however, it REALLY expects to be able to access the dir in ordered to save the new certificate, and segfaults when it can't! OK, so this is partly my problem due to the umask that I have pan inheriting when it starts. There's an old saying, if it hurts when you bang your head against the wall, quit banging! But I /like/ my "defense in depth", and anyway, after a bit of confusion with the encoding-cache thing as I had long ago forgotten about the umask thing, I'm aware of the issue now, and immediately suspected the umask issue when pan started segfaulting trying to install a certificate. ** So, my idea is this: Create a new create-dir function wrapper, that checks the permissions mode after creating the dir, and either spits out a nicely worded error explaining the problem if it's not executable, or simply corrects it, setting u+x (don't touch group and other perms, tho, as that's not normally necessary and the user may have a reason for masking them). Then simply replace all calls to create-dir (or more likely, open with create if it doesn't exist) with calls to this function that checks for sane permissions after dir creation, and either warns or changes them (your call, I'd prefer a warning and let the user handle it, but I recognize that my viewpoint tends to favor security over usability at times, still, a nice warning beats a segfault for usability any time!) accordingly. For all I know, there's already a gtk or whatever library function that does this, since it would seem to be a reasonable candidate for a library given the number of apps that could use it, but I'm not a coder, so won't know for sure. But even creating the wrapper function should be reasonably easy compared to some of the stuff you've been working on, and I'd guess the replacement could be pretty much global search and replace, once you have the wrapper function created and tested. Of course, the simpler solution would be to simply check for a failure status on the call to save the certificate, and deal with that. That'd still be a good idea, but it seems to me that fixing the umask permissions issue for all pan directory open-with-create calls at once, should be easy enough, using the wrapper-function approach, and that'd cure a lot of yes, I'll admit, corner cases, but it'd cure a lot of them, all at once. Sound like fun? =:^) -- 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-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
