PTBatcher creates insecure temporary files

I could try to fix it but there are IMHO two ways how to fix it: first is to maintain spool in home directory as you've suggested. The other one is to use mktemp() to create spool in temp with random name.

Which one should be preferred?

Not being a developer my proposed solution is very simple: look how it's done in hugin itself and copy that to PTBatcher.
(But off course: I don't know how to implement it)

I have not toyed with the batch processor yet, though intuitively I would say do it in the home directory.

As a user I want to be able to quit the application / restart the system and pick up the spool from where it was interrupted. Not sure if a random entry can be retrieved. A predictable location in the user's home directory allows just for this and is safe enough.

That sounds reasonable. Note that I've never used PTBatcher.

Anyway, I've done small patch. What do you think about it?
It moves ~ptbt and ~ptbs to home directory and renames them to .ptbt and .ptbs to hide them automatically on unix-like systems.
It seems that it works, but I've not tested it a lot.

The file PTBatcher.diff was added: Proposed patch

The patch looks ok to me. Though I have no idea what the roles are of the various files: ~ptbt0 ~ptbt1 ~ptbs0 ~ptbs1

It seems that ~ptbt* are containing informations about the queue. I've no idea what is the purpose of ~ptbs* files.

I think ~ptbt files are used the same way as are makefiles in temp used by hugin when stitching not saved project. But these files are created always, not depending if queue was saved or not.

I've been thinking about using temp dir with some random name, because it suits better to current practice in hugin (to create random temporary file if project is not saved).

But using random file name brings more problems because it will need process to communicate more to be able pass temp file name from Hugin to the PTBatcher. Also adding new projects to the queue would be at least problematic. I think using random filename is too complicated to be worthy doing it.

As it's security problem which in my opinion should be fixed as soon as possible (definitely before 0.8 goes out), I suggest putting my previous patch into the trunk, but I'd like to see if someone tested it on other platforms (Windows and Mac OS) before commiting it. I don't want to break something which already works.

Wow, this was much more serious than I would ever have imagined so I've decided to commit proposed patch.

When PTBatcher was started from another user it started with queue run by another user. If file mask was not correctly set, it was even possible to control that queue. If file permissions were correct, PTBatcher report many error messages to user that files with specified index doesn't exist.

If second user removed these data from his queue and added them back with the same settings it was easily possible to break queue which was run by another user as it was easily possible to create the same output files which would first PTBatcher create later. After some more experimenting I could say that it was pretty easy to break stitching for another user running PTBatcher queue. I've also been able to rewrite existing files created by other user.

Using home directory fixes all these problems except from the problem that other user could create files with the same prefix and break queues which has specified the same prefix, but at least it's not so easy to find out which prefix is set for projects not yet running.

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).