Unable to Install Decidim due to a bug in a dependency (seven_zip_ruby)

[Ph0tonic]

Hi,
I am currently unable to install the latest version of Decidim due to a bug with one of its dependencies (seven_zip_ruby), see :

• Native gem compilation tries to mkdir in my ruby install dir masamitsu-murase/seven_zip_ruby#42

Despite the PR created more than one year ago, no solution has been made available :

• Locate SO_TARGET_DIR with gem rather than system masamitsu-murase/seven_zip_ruby#43

Furthermore, this lib hasn't been updated for 3.5 years.

This issue is blocking installations on non-admin systems.
I identified a fork which has been updated and has fixed this library :

• https://github.com/fontist/seven_zip_ruby

Could it be an option to migrate to this new library or another one ? I noticed that the idea of changing this library had already been discussed a while back here: #8516
Thanks so much for your work !

[Ph0tonic]

Hi,
I can provide a PR if you think it's a good idea @andreslucena and @alecslupu

[andreslucena]

Thanks for bringing this up @Ph0tonic

To bring you some context, we're using this gem for this feature: http://github.com/decidim/decidim/tree/develop/decidim-core/app/services/decidim/download_your_data_exporter.rb - Basically it's adding a password protected zip file

In #8516 we mentioned:

seven_zip_ruby

Used to encrypt and password protect specific files in Decidim. There are no better maintained alternatives available that provide strong encryption for zip files. There has been some discussion for Rubyzip to incorporate AES encryption in that library but there is no recent activity regarding that. Keep an eye on the related discussion for Rubyzip or implement AES encryption to Rubyzip (search for “AES” from the repository pull requests).

The problem is that there are two kind of encryption in zip files:

• ZipCrypto: well supported, but it's broken (as in the security is really bad)
• AES-256: less supported, but more secure

We've chosen the more secure option.

Ideally we could migrate to rubyzip, as it's more supported, but they don't offer AES support. There's an open PR but it seems like it doesn't have much activity: rubyzip/rubyzip#179

Finally, to propose some ways of fixing this and have a better discussion, these is what I come up with:

1. To find another alternative that supports AES
2. To finish Add support for reading ZIP files utilising AES encryption rubyzip/rubyzip#179 - it could be a bit difficult as we should study how to implement this
3. To relax the security here, but also explaining to the participants when downloading their data that the security is (basically) in-existent and that they should delete their files after seeing them or something along those lines.

I'll bring this up in the next @decidim/product meeting explaining the problem to see which solution we will implement, but if there's another alternative that I'm missing, please share it 😄

[Ph0tonic]

Hi,
Thank you very much for your answer. I understand and fully agree with the security choice made. Regarding your proposition, I have a forth option which could be considered.
I identified a fork of the used library which has implemented the fix:

• https://github.com/fontist/seven_zip_ruby

Maybe we could in a first step switch to this dependency to unblock the situation and then take some time to implement one of the other alternative which might take some time.

[ahukkanen]

I agree this is a problem deploying Decidim to any PaaS service and also an inconvenience with fully owned machines that do not have user-specific Rubies installed (need to do some manual chown/chmod before deployments when installing new Ruby versions).

I have posted a suggestion about an alternative approach to the data exports to MetaDecidim:
https://meta.decidim.org/processes/roadmap/f/122/proposals/17635

With this, the exported document wouldn't need to be encrypted at the client side as it would be served through the user session which is already authenticated with their login credentials. And we could control from the Decidim service side what would be required to download those files, e.g. requiring the user to enter their password to download this file (if it is seen necessary).

Of course, this is much more work than the current approach, but I believe seven_zip_ruby needs to be switched anyways if it is no longer receiving updates. A short-term solution might be to switch to the mentioned fork (seven-zip @ RubyGems) but it seems they also haven't released the latest versions to RubyGems anymore. They mention this in the project README:

The last version published at rubygems.org is 1.4.2 Should you need the latest version please install it from this repo

[andreslucena]

I identified a fork of the used library which has implemented the fix

I don't like using a fork that doesn't have at least a bit of community behind, as it may be abandoned in sometime from now or could have security issues

With this, the exported document wouldn't need to be encrypted at the client side as it would be served through the user session which is already authenticated with their login credentials.

On this case the original idea was protecting from accessing the data export through the email (so, with the proposal from @ahukkanen that would be solved), but also protection in the local machine (like in public/shared computers and things like that).

I think that with the current state of the gems (without AES support) what we could do:

1. Implement the ZipCrypto from rubyzip - so at least there's something
2. Explain to the participants when downloading their data that the security is (basically) in-existent and that they should delete their files after seeing them or something along those lines

These two could be implemented as fixes so they can be backported and solve this bug.

Then for next versions (aka features, so they can't be backported):

a. Keep track if/when rubyzip implements AES sometime
b. In the future, to also implement the Metadecidim proposal 17635

[Ph0tonic]

I identified a fork of the used library which has implemented the fix

I don't like using a fork that doesn't have at least a bit of community behind, as it may be abandoned in sometime from now or could have security issues

I understand your point but both repo have basically no community, so maybe we should choose the one which is not buggy between the 2. And it would allow for a first fix which wouldn't take too much effort.