Closes#794: using these flags at the same time results in undefined
behavior - the final ordering is not guaranteed as --unique breaks
sorting due to passing the contents through a set.
NOTE: I added a newline before and after the mutex group to be
consistent with other usages of mutex groups (e.g.,
check_builtin_literals.py) in this repo.
As stated in the documentation: `Note that this hook WILL remove blank lines`
Previously this hook would always add blank a blank line.
With this fix, if the file is empty, a newline will not be added, and multpline blanklines in a file will be removed.
Fixes#935
There was already a guard preventing the check-executables-have-shebangs
hook from raising false positives on win32 by looking up the Git file
mode rather than relying on the file mode in the file system. Git already
automatically probes the file system for executable bit support. Leverage
Git's core.fileMode config variable to prevent false positives on all
file systems that don't track executable bits.
`git lfs status` only outputs status for files that are pending some git-lfs related operation.
For usage with --enforce-all, we need the list of all files that are tracked, which can be
achived by `git lfs ls-files`.
Fixes: https://github.com/pre-commit/pre-commit-hooks/issues/560
'OpenVPN Static key V1' label is often used by OpenVPN for providing hardening
security with additional HMAC signatures to the SSL/TLS handshake packets. They
are shared secrets and should be kept private.
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
As described by RFC7468 and RFC5958, keys that are encoded using the "ENCRYPTED
PRIVATE KEY" label are described as private key information and therefore can
contain secrets, even though encrypted.
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
The --enforce-all option when provided ensures that all files passed
on the command line are checked against the size limit. Default
behaviour remains unchanged.
On Windows, all files are "executable".
Therefore, to know if a file is supposed to be executed,
we check how its attributes were recorded by git:
we run a `git ls-files` command in a subprocess.
By default, this command outputs information
on multiple lines (file and their data separated by newlines).
When a file contains an unusual character,
the character is escaped with an integer sequence
(such as `\303\261`), and git wraps the whole filename
in double-quotes because of the backslashes.
It breaks the current code because we try to open
the filename containing the double-quotes:
it doesn't exist, of course.
Instead of trying to fix this special case by removing
the double-quotes, and breaking other cases
(a double-quote is a valid filename character on Linux),
we tell git to separate each item with the null character `\0`
instead of a new line `\n`, with the option `-z`.
With this option, git doesn't escape unusual characters
with integer sequence, so the output is fixed, and we
parse it by splitting on `\0` instead of `\n`.
Fixes#508.
Luis Pérez