gpg doesn't fail on target file existing when decrypting

[Doug Barton]

Andrew Flerchinger wrote:
> On Mon, Mar 16, 2009 at 5:17 PM, Doug Barton <dougb at dougbarton.us> wrote:
>> Andrew Flerchinger wrote:
>>> Yes, I do see that behavior. The primary difference is that I never want
>>> it to prompt me for anything, since I'm writing a headless wrapper.
>> What you're suggesting isn't "safe" in any case. What I would do in
>> your situation is the following:
>>
>> 1. Use mktemp to safely create a new, unique file
>> 2. Send the decryption output to that file
>> 3. Test if the "real" file exists, and if so unlink it
>> 4. mv $newfile $realfilename
>>
>>
>> hth,
>>
>> Doug
> 
> You're right, I could do that to make my work-around act atomic. Or
> are you saying that even the functional encrypt behavior isn't "safe?"

For typical command line use by a real person I think it's just fine.
If I were doing a script that used gpg in an unattended fashion I'd do
the same thing for encrypt as I suggested for decrypt above.

> I'm assuming that's essentially what gpg is already doing.

Don't assume. Test. Depending on what you're using it for (and in what
environment) the bar is much, much higher for programs (including
scripts) that run in an automated environment than for those that run
with real human interaction. Not that humans always make the right
choices by any stretch.

> I guess I'm still trying to determine the reason for the inconsistent
> behavior between encryption and decryption functions.

You're approaching this problem from the standpoint of unattended
usage, which is not how the current command line behavior was intended.


Doug