fpm 1.14.2 seems broken on RHEL8 / ruby <= 2.5.x

[schultetwin1]

Hi!

Installing fpm on ruby 2.5.x looks broken due to dotenv dependency. The upgrade from 2.7.6 to 2.8.0 of dotenv seems to be the problem as it uses the endless iterator syntax introduced in Ruby 2.6 https://bugs.ruby-lang.org/issues/12912

bash> fpm --help
Traceback (most recent call last):
	18: from /usr/local/bin/fpm:23:in `<main>'
	17: from /usr/local/bin/fpm:23:in `load'
	16: from /usr/local/share/gems/gems/fpm-1.14.2/bin/fpm:5:in `<top (required)>'
	15: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	14: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	13: from /usr/local/share/gems/gems/fpm-1.14.2/lib/fpm/command.rb:15:in `<top (required)>'
	12: from /usr/local/share/gems/gems/fpm-1.14.2/lib/fpm/command.rb:15:in `each'
	11: from /usr/local/share/gems/gems/fpm-1.14.2/lib/fpm/command.rb:18:in `block in <top (required)>'
	10: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 9: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 8: from /usr/local/share/gems/gems/fpm-1.14.2/lib/fpm/package/pleaserun.rb:6:in `<top (required)>'
	 7: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 6: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 5: from /usr/local/share/gems/gems/pleaserun-0.0.32/lib/pleaserun/cli.rb:8:in `<top (required)>'
	 4: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 3: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
	 2: from /usr/local/share/gems/gems/pleaserun-0.0.32/lib/pleaserun/platform/base.rb:1:in `<top (required)>'
	 1: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require': /usr/local/share/gems/gems/dotenv-2.8.0/lib/dotenv/parser.rb:87: syntax error, unexpected ']' (SyntaxError)
      !line.split[1..].all? { |var| @hash.member?(v...

My workaround was to pin the dotenv gem to 2.7.6

gem install --version 2.7.6 dotenv
gem install fpm
gem uninstall --version 2.8.0 dotenv

[nudgegoonies]

Same Problem with Debian 10 / buster and ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux-gnu]

[nudgegoonies]

dotenv dropped support for ruby 2.4, 2.5 and 2.6:
https://github.com/bkeepers/dotenv/releases/tag/v2.8.0

[therealplato]

dotenv 2.8.1 release has resolved this issue for me.
I was suprised to encounter it because I have pinned fpm 1.11.0 on ruby 2.5.0.
I was unaware that fpm 1.11.0 didn't pin its own dependencies.
Unpinned packaging code is a security risk.
Is @schultetwin1 's workaround the best available to pin fpm's dependencies?

[schultetwin1]

Yep, I just saw that dotenv's release resolved this issue for me as well. Based on the release notes that makes sense.

I'm going to close this issue as it's no longer a problem. @therealplato - Feel free to open a new issue about pinning dependencies!

[jordansissel]

Unpinned packaging code is a security risk

This is an overly broad statement and without specifics on a particular threat model, it's hard to respond in the context of fpm and its use cases.

That said, it's worth looking into why fpm often doesn't pin dependencies. Historically, there's been a conflict between "pin dependencies" and "works on multiple versions of ruby" because of changes exactly like the dotenv 2.8.0 change and highlighted in the dotenv issue reporting a similar issue. Another example is ffi which fpm depended on until recently -- there was no way easily depend on a specific version of ffi that worked for many ruby versions. Ultimately, I ended up removing the dependency on ffi to resolve this problem - #1795 because I couldn't find any other way.

I'm open to discussing pinning, ruby versions, etc on a new issue :)

[therealplato]

Thanks @jordansissel, I didn't mean to sound combative and I recognize that pinning introduces different security risks

[jordansissel]

I didn’t feel it was combative. It’s a complex problem sometimes with no easy answers. I’m glad for your input :)

…

On Wed, Jul 27, 2022, at 11:33 AM, Isaac Rogers wrote: Thanks @jordansissel <https://github.com/jordansissel>, I didn't mean to sound combative and I recognize that pinning introduces different security risks — Reply to this email directly, view it on GitHub <#1918 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2TTL74JYWP7ZYU7VSTVWF6HTANCNFSM54XVHQ3Q>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nudgegoonies]

With correct semantic versioning the breaking change in dotenv 2.8.0 must result in a 3.0.0 instead of 2.8.0.

But this also requires that fpm limits the dependencies to the same major version to not run into such conflicts. I don't know if ruby supports that and of course all transitive dependencies have to be conform to semantic versioning and limit their dependencies as well.

[jordansissel]

I filed a followup to find a way to help reduce risk of dotenv changes in the future: #1919