mail: Incorrect file permissions in 2.8.0

With this issue unresolved in the released 2.8.0 gem, the current version of the mail gem is unusable in setups requiring read-access to others (e.g. in cases where the gem is installed by a different user than the one running the application).

Could you possible release a new version of the mail gem to rubygems which fixes the file permissions and set all files to be readable by everyone, similar to all the other files in the gem?

Fixed in #1555. Please give 2.8.0.1.rc1 a try.

Hey @mikel , I believe this issue merits urgent attention and does not appear to be something that we can contribute to - file permissions in git seem to be correct, and this seems to be something related to how you cut releases that isn’t visible to anyone else to assist in fixing it. This was reported prior to 2.8.0 being released and it seems to have been reasonable justification to hold back that release, but it doesn’t seem to have stood out in the list of open issues enough for that to happen, which is why I’m trying to call some more direct attention to it here. Thanks for your help and your work on this project 😃

2.8.0.1 is released and works flawlessly for me.

Remember to remove your workarounds when upgrading 😉

This has unexpectedly killed the production systems of many critical and non-critical systems. This is a nasty bug that passes through CI and testing, so it really catches people off guard and it is not obvious to find the cause or implement the workaround - especially while being faced with a sudden barrage of health notification and customer complaints.

For those of us impacted by this, the damage is done and we know how to prevent further downtime. But others are potentially killing their production systems every minute this release is allowed to remain.

Even if this saves a single more production environment from being killed, it is worth yanking in my humble opinion. Even if there is a new release, it is still worth yanking at the risk of someone installing this version by accident.

Any updates on this?

+1 for yanking, this is breaking prod unexpectedly for all rails users and should be considered critical and yanked until a fixed version can be released.

Releasing a fixed version is no more difficult than yanking, as was discussed above. Everyone here agrees on the criticality, but that is worthless because none of us have the ability to cut a release. Someone who knows the maintainer personally needs to bring it to his attention.

Yes, let’s get this fixed. Thanks @eval

The really important question is imho: How can it be that such an important gem is so under-maintained that there is no new release within at least a week 😕

Because nobody is paying for it.

@ssunday The fact is that yanking would cause work for those who have already done the work to implement workarounds and now have 2.8.0 in their lockfiles. Yanking would cause more pain for those who have already lost time to this. A new release is trivial and far superior. If adding maintainers is necessary for the health of this project, that should be done.

Just dropping my vote for not yanking 2.8.0 - it’s not a security or legal issue and it works OK with the workarounds described above (for me it was a one-line change to my test Dockerfile, for example) and there are already downstream gems that depend on it. I’m thinking if someone has the power to yank 2.8.0 they also have the power to release 2.8.1, which seems to me like a better solution.

I don’t think a gem that requires work arounds to be functional should be allowed to be an active release, but that’s my opinion. Or if it does, there should be a notification on install or documentation besides this thread.

But +1 to the power to yank is also the power to release… which would be great 😓

Oh no, sorry for causing all that crossref spam 🫣 (I’ll try this workaround to avoid it in future.)

It’s unlikely to be much more work to re-release 2.8.0 with fixed permissions as 2.8.1

It looks like those who have opted to fix permissions locally have not encountered additional issues in 2.8.0, so this would the benefit of providing various code fixes.

I don’t see the point of yanking now.

Can 2.8.0 please be yanked, at least?

Sorry, I thougth that previous rc releases contained the bug and the 2.8.0 fixed this. I suppose that use the 2.7.1 version is the easy way to avoid this problem.

Sure, release 2.8.1, no arguments there, but I don’t see the point of keeping a broken release. Broken releases should be yanked, it is best practice.

My point is yanking the release appears to be the quickest immediate solution that should require the least amount of time. I appreciate @mikel has many priorities and finding the time to sit down to look at this can be challenging. While yanking the release can be done from a mobile phone while walking to the kitchen for a cup of coffee.

Afterwards, I agree, possibly looking at additional maintainers, or changes to the release process, fixing this for the next release, etc, etc can all be looked at, really in any order.

@benlangfeld Will do and I’d still encourage you to reflect on whether this gem version should be yanked or not. I maintain that it should be yanked.

@stell @benlangfeld Very easily. Running bundle update does not trigger the bug, so the developer has no idea this will kill production. Once a commit is done, the CI systems often run in isolated environments and install specific versions of Ruby for testing, so this passes through many CI systems including ours which uses github-actions.

In production, if the company standardised on a Ruby version, it can be a deb package instead of RBenv or RVM (ours is build with jemalloc which reduces ram usage), so in that situation, the bug is not triggerable until the code hits production.

With due respect, I am not asking for advice on how to redesign our production systems, I am asking for the gem version to be yanked as it kills build systems, can kill production systems, requires workarounds, etc - it should just not exist even if a new version is released.

@rgaufman I maintain that this is indicative of a serious bug in your pipeline. A robust deployment pipeline would not permit the propagation of this issue to a production system. While this bug should never have been shipped, it was and others will be, and your pipeline has to be resilient to this kind of negative external influence. Rejecting advice is all well and good, but I’d still encourage you to reflect on why that happened to you and not to others.

@stell @benlangfeld Very easily. Running bundle update does not trigger the bug, so the developer has no idea this will kill production. Once a commit is done, the CI systems often run in isolated environments and install specific versions of Ruby for testing, so this passes through many CI systems including ours which uses github-actions.

In production, if the company standardised on a Ruby version, it can be a deb package instead of RBenv or RVM (ours is build with jemalloc which reduces ram usage), so in that situation, the bug is not triggerable until the code hits production.

With due respect, I am not asking for advice on how to redesign our production systems, I am asking for the gem version to be yanked as it kills build systems, can kill production systems, requires workarounds, etc - it should just not exist even if a new version is released.

+1 for yanking, this is breaking prod unexpectedly for all rails users and should be considered critical and yanked until a fixed version can be released.

If you need to fix permissions after the installation, run find /usr/local/bundle/gems/mail-2.8.0.rc1/ -type f -perm 640 -exec chmod 644 {} \;. Adjust path to the gem if needed.

Also having issues, reverting to 2.7.1.

I also checked yesterday and I can confirm permissions are correct in the repository. It’s something on the release process that messed with it somehow.

Thank you very much for the new release. I still find it really interesting that rubygems and bundler do respect file permissions within packed gems. I really did not know that and wonder how much that feature is actively used in production.

@benlangfeld Will do and I’d still encourage you to reflect on whether this gem version should be yanked or not. I maintain that it should be yanked.

Dude, it doesn’t matter one ounce what you or I think about whether the gem should be yanked or not; we could debate that all day and it wouldn’t change anything. It matters who knows/works with @mikel and can bring to his attention the breadth of the impact of this issue and the urgency in correcting it, be that by way of him finding time to address it personally or by nominating additional maintainers who could take care of it.

This has unexpectedly killed the production systems of many critical and non-critical systems. This is a nasty bug that passes through CI and testing

@rgaufman How is that possibly true? That seems like a serious defect in your software delivery procedures. The consequences of this bug should be limited to failures to build new versions of your software; if you suffered more than that, you should look into software packaging best practices and I’d be happy to provide more specific advice in private if you want to reach out.

The really important question is imho: How can it be that such an important gem is so under-maintained that there is no new release within at least a week 😕

You can add this to your Gemfile to avoid the faulty release:

# FIXME:
# mail v2.8.0 shipped with faulty file permissions, see: https://github.com/mikel/mail/issues/1489.
# Remove the following line once a fixed release is available:
gem 'mail', '!= 2.8.0'

Assuming you are using mail as a dependency of rails. If you depend on mail explicitly, change the comment to remove the version specification instead of the whole line.

Despite the easy fix, I’d appreciate a proper release with fixed file permissions any time.

Yep, hundreds of people suffered similar problems because of this problem, but only two people in the world can fix it because the release process is not automated.

@seoanezonjic 2.8.0 was released in a broken state. We desperately need a 2.8.1 release with a fix because this keeps biting people, but that is not forthcoming.

Hello!

Somehow i avoid the problem by not using the “-T” flag for avoiding testing libraries, obviously is not an ideal solution but it might be a clue to help find the problem.

We ran into the same issue and I have trouble downgrading as it is a dependency for later versions of actionmailer.

According to https://rubygems.org/gems/actionmailer/versions/7.0.4 you should be to just type this is in your Gemfile:

gem 'rails', '~> 7.0.4'
  gem 'mail', '~> 2.7.1' # bug with mail 2.8.0 https://github.com/mikel/mail/issues/1489

And it should work.

We’ve also been bitten by this. We’ve downgraded to 2.7.1 for now. Another workaround was to fix the permissions ourselves within the docker container. A bit hacky, but works.