Builds that pass variables in an encrypted file have started failing without any changes to the repo. I’ve seen this for both xenial py2 and bionic py3 builds. Any idea what might be going on?
This is quite curious. The first failure occurred 6 days ago, and failures continue to this day, but there have been 2 successes since the first failure https://travis-ci.org/Gluejar/regluit/builds/653163733 https://travis-ci.org/Gluejar/regluit/builds/654668678. I cannot reason how this might happen.
If you restart one of these successes, does it fail now?
Have tried restarting the build, just tried this one again https://travis-ci.org/Gluejar/regluit/builds/654746203 master branch has not been touched in 18 days!
Successes are on 18.04.3, failures are on 16.04.6 and 18.04.4.
Googling suggests that this happens if there is a breaking change between OpenSSL versions used to encrypt and the one used to decrypt:
I must also note that
aes-256-cbc doesn’t seem to be a documented
Hmm. That is rather disconcerting. We’ll look into it more. Thanks for bringing this to our attention.
It is. Otherwise
openssl would not tell you it’s a “bad decrypt”.
OpenSSL command help text
$ openssl version OpenSSL 1.1.1d 10 Sep 2019 $ openssl aes-256-cbc --help Usage: aes-256-cbc [options] Valid options are: -help Display this summary -ciphers List ciphers -in infile Input file -out outfile Output file -pass val Passphrase source -e Encrypt -d Decrypt -p Print the iv/key -P Print the iv/key and exit -v Verbose output -nopad Disable standard block padding -salt Use salt in the KDF (default) -nosalt Do not use salt in the KDF -debug Print debug info -a Base64 encode/decode, depending on encryption flag -base64 Same as option -a -A Used with -[base64|a] to specify base64 buffer as a single line -bufsize val Buffer size -k val Passphrase -kfile infile Read passphrase from file -K val Raw key, in hex -S val Salt, in hex -iv val IV in hex -md val Use specified digest to create a key from the passphrase -iter +int Specify the iteration count and force use of PBKDF2 -pbkdf2 Use password-based key derivation function 2 -none Don't encrypt -* Any supported cipher -rand val Load the file(s) into the random number generator -writerand outfile Write random data to the specified file -engine val Use engine, possibly a hardware device
If it helps, openssl on the encrypt side is “OpenSSL 1.0.2q 20 Nov 2018”
The encrypted file on the Master branch has been unchanged in since Apr 10, 2019.
Is it possible to re-encrypt the file with a newer version of OpenSSL?
openssl installs on the mac break things, I’ve found. I’ll try this, but it would be disturbing if version updates make file un-decryptable!
Encrypting another file later will overwrite the secure variable, rendering the old file unusable.
does this mean that I can’t have different encrypted files on two branches?
OK, that’s the cause! I can get around the problem for now by using the same encrypted file in both branches. Please escalate the PR.
OK, maybe not. Now I have the exact same encrypted file on two different branches. it’s passing on the py2/xenial branch and failing on the py3/bionic branch.
Has been fixed as per https://github.com/travis-ci/travis.rb/issues/627#issuecomment-610472411
I believe we pushed a fix recently #678.
As per Custom deployment - Problem with SFTP key and cURL: "curl failed to verify the legitimacy of the server" - #13 by aleks-rodriguez, it looks like this problem resurfaces if one is using the same decryption key variables multiple times:
$ openssl aes-zss-cbc -K Sencrypted_9886as3a028f_key -1v Sencrypted_9806a53a028f_1v -in ssh-pair.enc -out ssh-pair -d <...> $ openssl aes-zss-cbc -K Sencrypted_9886asaad28f_key -iv Sencrypted_9806a533d28f_iv -in id_rsa.enc -out id_rsa -d bad decrypt
In this case, make sure to use the exact command, including variable names, that
travis encrypt-file gave you.
travis encrypt-file actually gave you identical variable names, this means you’re using a very outdated version of the
travis gem – which you should have received a warning about.)