Duncan wrote:
So it doesn't look like I'm going to be made to eat some of those 250
lines now after all, tho only by virtue of the fact that it's not the pan
code that's doing it but the library. =:^)
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*
> It's just that pan doesn't
have code to undo what the library does by default, or to prevent it
doing it in the first place (say by altering the UUE perms to kill the
execute bits before feeding it to the decoder), either.
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 :)
--
Steven
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
