Encrypt failed: data too large for key size

[nijel]

When trying to encrypt larger variable (Keen.io access token), I get this error:

    OpenSSL::PKey::RSAError: data too large for key size
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/client/repository.rb:16:in `public_encrypt'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/client/repository.rb:16:in `encrypt'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/client/repository.rb:72:in `encrypt'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/cli/encrypt.rb:39:in `block in run'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/cli/encrypt.rb:39:in `map'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/cli/encrypt.rb:39:in `run'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/cli/command.rb:198:in `execute'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/lib/travis/cli.rb:64:in `run'
        from /usr/lib64/ruby/gems/2.0.0/gems/travis-1.7.0/bin/travis:18:in `<top (required)>'
        from /usr/bin/travis2.0:23:in `load'
        from /usr/bin/travis2.0:23:in `<main>'

[rkh]

Yes, we should probably display a better error.

Consider using travis env set or travis encrypt-file instead.

[mixonic]

@rkh is travis env set encrypted?

[rkh]

Yes, but server side (the unencrypted value will be sent over an encrypted
connection to our API).

On Thu, Dec 11, 2014 at 9:29 PM, Matthew Beale notifications@github.com
wrote:

@rkh https://github.com/rkh is travis env set encrypted?

—
Reply to this email directly or view it on GitHub
#221 (comment).

[rkh]

That is, unless you mark the value as public.

On Fri, Dec 12, 2014 at 11:24 AM, Konstantin Haase <
konstantin.mailinglists@gmail.com> wrote:

Yes, but server side (the unencrypted value will be sent over an encrypted
connection to our API).

On Thu, Dec 11, 2014 at 9:29 PM, Matthew Beale notifications@github.com
wrote:

@rkh https://github.com/rkh is travis env set encrypted?

—
Reply to this email directly or view it on GitHub
#221 (comment)
.

[webknjaz]

@rkh I think it might be a good idea to implement encryption to larger values. Another example might be 4096-bit SSH RSA key which we might want to store securely in .travis.yml rather than putting it into the web UI. Since you already have server-side code to do this, it shouldn't be hard to copy that into the client, right?

[jaraco]

I've also encountered this issue attempting to install a PyPI token as an environment variable. The token is 173 characters. Then add TWINE_USERNAME="" and you're at 189 characters, which Travis rejects.

It seems 118 is the magic number that's too long.

keyring master $ echo @('x'*118) | travis encrypt -r jaraco/keyring                                                                          
data too large - consider using travis encrypt-file or travis env set
keyring master $ echo @('x'*117) | travis encrypt -r jaraco/keyring                                                                          
Please add the following to your .travis.yml file:

  secure: "lMj0ITa1ycnrciRtS4RwJuq2XYNMmxgtyULrdRbPx2IzkZuJOcbhMcir3mjATJpZQCjPotmJKmrvjK5/YJhF8GTcAPwNANqyRM1Tg2VIPsp0jGNRqdtsP1/J5cs2Orm7SFQkrGJCDHnRt1v7LCucjpviAqiPuxUkFumSeOwBsIw="

Pro Tip: You can add it automatically by running with --add.

What's really got me stumped, however, is that I've been able to encrypt this token in the past (as late as this morning).

In fact, I just ran the same routine on setuptools again and it worked fine. It seems that the jaraco/keyring project has a shorter limit. Indeed, setuptools' is allowed 501 characters:

setuptools master $ echo @('x'*501) | travis encrypt -r pypa/setuptools                                                                      
Please add the following to your .travis.yml file:

  secure: "mqiebVbRqqhLABgEObCnlu+Z/PX2kA7zCgbhsqDGgF9PrLIQQZbE3d5w4LFMUxglbGey0Qrr6DzVwwuDfK1cvioV40GgLT1ovHV0t6G68COS0YQF6p4NkgCII/e5Vo5AemyhbkxcqVXTLAaCHrI3ZvVL1c33H/RO3A2lAO0nOjQmesxDJFGXF8Pn4n8vYqP9jsYHbEdqEeo2+JbTTMO17fRJX5RfuL0aqBxDKnfKGMad5WkOoM1hEmBth3m/LWNV72Q8FPDyiwKYJYAnGFLPmmeDGl6dqIHXAk/aMkO7RrEf7Yb51N/2gbApgxlRxJZDQA5uwcVkNr3y45YWAhApjEkLUrFqkMJlpyjfmR3Cktq3eyynba0lUZOuFzydamcW/yQqoBq7Ih1u7Voto8n8gLWCXsTkaJJcngMW+wvsgu2sbnAL6YKSgq3IXAcP+KhPPEewCIJyA8FD+6jrVZCkR7toSWAf2bq9S8S3WJHnXaA9ZfQUbXOibE1Lu2TXilJR1Efxq+YeEmAS1DybEC/auyArwHJPeVJxoQOMw5aMXQVZpJt65snU2qJYtYXOpNnnqEWWeZXCiJ4/PMrjDtJfWnDyilOo+D/FDYiU5TVRSIWmAg2aFFNIJ04q0uuk+sF+agVF5EvXP5r1odp1UVkfTjmH5YuI+YxVVf4awkwK7LQ="

Pro Tip: You can add it automatically by running with --add.
setuptools master $ echo @('x'*502) | travis encrypt -r pypa/setuptools                                                                      
data too large - consider using travis encrypt-file or travis env set

It feels like Travis is a little capricious about the allowed lengths for these variables. Maybe it's key length (512 or 128) minus 11 bytes for something? Given that PyPI tokens are a very common usage of encrypted variables, is there another option? I don't think env set works for projects that use DPL. Also, I'd like to restrict the exposure of this token to the deploy step (which is particularly constrained to tagged commits).

[jaraco]

FYI, I was able to use env set (env copy actually to avoid exposing the password in the command line parameters), so I'll probably just stick with that. Would still like an explanation why encrypted payloads are limited to arbitrary lengths and differ for env vars as for committed blobs.

[jaraco]

I don't think env set works for projects that use DPL.

I confirmed that the minimum config for a pypi deployment includes an explicit password, so setting it in the environment doesn't help.

Can you re-open this issue and address it please?

[webknjaz]

@jaraco it's just poorly documented. It actually has an env var fallback: https://github.com/travis-ci/dpl/blob/v1.10.12/lib/dpl/provider/pypi.rb#L12. The env var is PYPI_PASSWORD.

[jaraco]

It would also be nice if someone would investigate what is the supported length for encrypted values in config. It seems to vary by project, and it would be nice if someone could provide a workaround for projects that seem to have gotten the short straw (for encryption keys).

[webknjaz]

I'm almost sure that it's .org vs .com difference

[jaraco]

I’m highly skeptical that Travis-ci.com is implicated. I believe I use Travis-CI.org exclusively. Is there any evidence that supports that proposition? More importantly, does the reported difference above between setuptools and keyring support or refute that proposition?

[webknjaz]

Yes, I have a number of projects where I've encrypted big strings (including PyPI API tokens) and it works with .com. Also, I think I saw somebody from Travis CI posted somewhere that .com has a limit of 4096. But this was around the time
they started the migration so I was watching a lot of stuff being an early adopter.

[jaraco]

The fact that setuptools is on travis-ci.org and works with the larger key dispells the notion that travis-ci.com is the key differentiator. I suspect instead that the key size was updated at some point and any project that was created before that point will have the smaller key. I also suspect that deleting and re-creating the project in Travis would allow it to have a larger key. This change would also, however, require losing the history. It would be nice if the Travis team could provide a means to reset the encryption key such that these older projects could get a 4096-bit key.

[webknjaz]

Hey @svenfuchs, WDYT?

[hugovk]

Reported to the Travis CI Community:

• https://travis-ci.community/t/travis-encrypt-data-too-large-for-pypi-tokens-with-older-repos/5792

Would be great to get a fix for this.

It's also happening to (old) projects that have been migrated from travis-ci.org to travis-ci.com (SethMMorton/natsort#106 (comment)), so I recommend not migrating any projects.

[and-semakin]

Confirm the issue. I can encrypt a PyPI token in my fork, but can't do that in the original old repo.