Read the password from stdin if desired

[steve-pexip]

Use the common convention: "-" means to use stdin

[steve-pexip]

We've been using osslsigncode for some time, and it's awesome to be able to sign Windows stuff without having to touch Windows. :-)

We're using automation to do the signing, so a clean way to pass the password is useful. We don't want to supply it on the command line where another process might be able to see it, and we don't want to write it to a file on disk that might be captured. So we're using this change to use stdin.

[steve-pexip]

Hi folks,

Any comments on this please?

[mtrojnar]

I'm not a big fan of security through obscurity. If an attacker can access all files on disk regardless of file permissions, the same attacker can also replace osslsigncode.exe with her own executable dumping its standard input to the console or a file.

[steve-pexip]

This does protect against an unprivileged attacker watching for command lines using ps etc., though. That's the point.

Openssl includes support for this kind of thing (with even more complex options), as listed in openssl-passphrase-options(1). I didn't go as far as that with this PR, but if you'd prefer something compatible I could work that way too?

[mtrojnar]

In this scenario, the protection stems solely from the permissions set on the private key file. Encrypting the private key with a passphrase, when stored on the same device, merely introduces complexity without enhancing security.

[steve-pexip]

So we have a setup with the following:

• some private keys in an HSM
• some private keys in files
• none of the passphrases for those keys are ever stored on the same machine - they're supplied to a supervising process at runtime and never stored, then passed through to the signing calls as needed

It's better to have an option not to expose passphrases here, surely that's obvious?

[mtrojnar]

surely that's obvious?

Argumentum ad populum. Yeah...

To clarify, when I mentioned "stored on the same device," I did not mean "stored on the same disk." Instead, I referred to the ability to retrieve it in plain text from the same machine. My initial statement could have been more precise.

[steve-pexip]

So you're seriously arguing that having a password inside the memory space of a process is equivalent to having it visible to anything/anybody else on the machine running ps?

[mtrojnar]

So you're seriously arguing that having a password inside the memory space of a process is equivalent to having it visible to anything/anybody else on the machine running ps?

No, my argument is that such a password does not enhance the security of a private key file, rendering it not sensitive to confidentiality concerns (thus, not warranting protection). I believe I've already made this point, haven't I?

However, I am open to being persuaded regarding the credentials for HSM access.

[steve-pexip]

Our threat model includes the possibility of an attacker stealing the machine, at which point the private key files on the disk and the HSM in the machine are a problem. We're therefore trying to limit the exposure of the credentials for all of these. If you don't see value in that, then I don't think it's worth us discussing any further.

[mtrojnar]

Our threat model includes the possibility of an attacker stealing the machine,

That's a valid attack scenario here. I'll consider it.

If you don't see value in that, then I don't think it's worth us discussing any further.

To foster a productive dialogue, it's important for all of us to approach our discussions with respect and civility. Being impolite can detract from our collective goal of constructive engagement.

[steve-pexip]

Apologies if that came across as impolite. I'm just trying to be pragmatic - if we have such different ideas about the importance of passphrase security then we're probably not likely to get anywhere.

[mtrojnar]

Could you also update the usage() function to indicate the new feature?

[steve-pexip]

Added extra text - I hope that's the kind of thing you're looking for.