SystemSh0cker/gocsaf
1
0
Fork 0
mirror of https://github.com/gocsaf/csaf.git synced 2025-12-22 05:40:11 +01:00
Code Issues Releases Activity Actions

Document that client-passphrase option is experimental

Browse source 
* Label the option experimental and limited at all places.
 * Point to the downloader documentation as single point to write more.
 * Add more hints on how the old PEM block encryption is experimental
   and why it often shall not be used.
---------

Co-authored-by: JanHoefelmeyer <hoefelmeyer.jan@gmail.com>
Co-authored-by: Bernhard Reiter <bernhard@intevation.de>
This commit is contained in:
Sascha L. Teichmann 2023-08-18 11:24:39 +02:00 • committed by GitHub
parent 79fbc2bcd8
commit a153906d03
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
8 changed files with 22 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/csaf_downloader.md
View file

@ -12,7 +12,7 @@ Application Options:
--ignoresigcheck Ignore signature check results, just warn on mismatch
--client-cert=CERT-FILE TLS client certificate file (PEM encoded data)
--client-key=KEY-FILE TLS client private key file (PEM encoded data)
--client-passphrase=PASSPHRASE Optional passphrase for the client certificate
--client-passphrase=PASSPHRASE Optional passphrase for the client cert (limited, experimental, see doc)
--version Display version of the binary
-v, --verbose Verbose output
-r, --rate= The average upper limit of https operations per second (defaults to
@ -113,4 +113,18 @@ In the config file this has to be noted as:
ignorepattern = [".*white.*", ".*red.*"]
```
#### beware of client cert passphrase
The `client-passphrase` option implements a legacy private
key protection mechanism based on RFC 1423, see
[DecryptPEMBlock](https://pkg.go.dev/crypto/x509@go1.20.6#DecryptPEMBlock).
Thus it considered experimental and most likely to be removed
in a future release. Please only use this option, if you fully understand
the security implications!
Note that for fully automated processes, it usually not make sense
to protect the client certificate's private key with a passphrase.
Because the passphrase has to be accessible to the process anyway to run
unattented. In this situation the processing environment should be secured
properly instead.
[^1]: Accepted syntax is described [here](https://github.com/google/re2/wiki/Syntax).