[Pan-users] Re: ANNOUNCE: pan-attach and pan-attach-kd, version 0.0.2006.10.07.0

[Duncan]

"Jack Cuyler"
<address@hidden> posted
address@hidden, excerpted below, on  Sun, 08 Oct 2006 19:13:43
+0000:

> +TMP=${TMP:-/tmp}
> +TEMPFILE=${TMP}/panpost.$(date +%Y%m%d%H%M%S%N)

OK, I'm looking at this in a bit more depth now, and like it except that
I'm not satisfied with the safety of the bit above.  For
reference, see "Safely Creating Temporary Files in Shell Scripts"
http://www.linuxsecurity.com/content/view/115462/151/

FWIW, I just now did the research on that myself.  I knew there was an
issue and had basically flagged it in my head as something to look into
before I ever started creating tmpfiles in public scripts.  Now that I
actually have a use for the info and should therefore retain it better, a
bit of googling to the rescue, as I expected. =8^)

Given that the sig should be reasonably small, I'll probably implement the
solution covered in section 3.1 of the above document -- don't use a
tmpfile for the sig at all, instead copying it to an environmental
variable.

Not that I had to explain it as I could have just implemented it. 
However, this is a learning experience for me, and since you were nice
enough to provide the patch with the sed commands so I don't have to
slough thru figuring out sed well enough to do it myself, I thought I'd
pass the tip on safe tmpfile creation back. =8^)

FWIW, a guy named Bruno Gnecco mailed me another suggestion as well.  By
quoting the ATFILE in the following lines (original version without your
patch) as shown, the path can be made space-safe.  I /think/ it should
actually be single-quotes, thus avoiding shell-expansion of any other
strange characters, which should make it safe for them at the same time. 
However, I've not (yet) tested either way and he had presumably tested the
double-quoted way, so...

117: while [ ! -r "${ATFILE}" ]; do
126: uuenview -${ENCODE} "${ATFILE}" >> ${BODYFILE}

I expect to have a rollup release with both of those and a bit more proper
license implementation (likely either including the text of the GPL as
comments, since it's a single file distributed, which seems to be the FSF
recommendation tho I haven't researched that in depth for scripts yet --
but that's a bunch of text which would double the size, thus why I
consider the GPL somewhat unappropriate for a script -- or perhaps switch
to CC Attribution/share-alike) soon.  I wanted to do it last week but last
week ended up being a mad week, so skipped it.

Having whet my appetite with this, I'm thinking more and more seriously
about trying for a newspost front-end as well.  Now /that/ would be
something quite useful, given how far out of date the existing KDE/GNOME
front-ends for it are, and that it would likely be of interest to more
than just pan users.  It's possible it could get distribution attention,
so getting stuff like license issues figured out with pan-attach-kd is
probably a useful practice run. =8^)  (Hmm... maybe I should actually
check to see if there's already a project of the same nature around first.
<g>)

-- 
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