git-secret init fails if using BusyBox version of mktemp

[imperfect-fourth]

What are the steps to reproduce this issue?

1. Requires BusyBox version of mktemp instead of GNU
2. git secret init

What happens?

Fails with error message mktemp: invalid argument

What were you expecting to happen?

To successfully initialize git secret

Any other comments?

BusyBox version of mktemp requires <template> to end in 'XXXXXX' instead of 'XXX' in the case of GNU. More information: pires/docker-elasticsearch#56 (comment)

What versions of software are you using?

Operating system: (uname -a) Linux 083a40661ac3 4.4.0-142-generic #168-Ubuntu SMP Wed Jan 16 21:00:45 UTC 2019 x86_64 Linux

git-secret path: (which git-secret) /usr/local/bin/git-secret

git-secret version: (git secret --version) 0.2.5

git version: (git --version) 2.20.1

Shell type and version: ($SHELL --version) GNU bash, version 4.4.19(1)-release (x86_64-alpine-linux-musl)

gpg version: (gpg --version) 2.2.12

[joshrabinowitz]

Hello, @Divi09112

Can you please re-test with the current master branch of git-secret and let us know the results? There have been changes to how we use mktemp.

If you do still see failures, can you paste the results of

    SECRETS_VERBOSE=1 git secret init

That will show some info about where git-secret is failing. If you don't see errors, let us know that too please so we can close this issue.

Also, can you provide steps how we would test git-secret using busybox? I installed 'busybox' on my ubuntu test system, and ran 'busybox bash' and then 'make test', but I couldn't replicate your issue - it seemed like the test was using the normal unix tools instead of the busybox versions.

[imperfect-fourth]

In the current master branch mktemp uses 'XXXXX' (5 Xs), so it doesn't work.
Here is the output of SECRETS_VERBOSE=1 git secret init

mktemp: Invalid argument
/usr/local/bin/git-secret: line 321: : No such file or directory
git-secret: cleaning up:```

For testing with busybox you can use docker [Busybox](https://hub.docker.com/_/busybox/).

[joshrabinowitz]

I see, thank you @Divi09112 . I've worked up a fix for this issue at #479 #480 .