4.0.0rc2

[michael-s-molina]

Hello Superset Community,

Superset 4.0.0 RC2 is up for testing. Check the Testing a Release Candidate (RC) section of our Release Process for information on how to test and report issues with the release candidate.

The release notes:
https://github.com/apache/superset/tree/master/RELEASING/release-notes-4-0

The release candidate:
https://dist.apache.org/repos/dist/dev/superset/4.0.0rc2/

The Git tag for the release:
https://github.com/apache/superset/tree/4.0.0rc2

The change log for the release:
https://github.com/apache/superset/blob/4.0.0rc2/CHANGELOG/4.0.0.md

The instructions for updating to the release:
https://github.com/apache/superset/blob/4.0.0rc2/UPDATING.md

Public keys are available at:
https://www.apache.org/dist/superset/KEYS

Thanks,
The Apache Superset Team

[sadpandajoe]

Still seeing this issue in rc2: #27500. Not urgent enough to downvote the release.

[michael-s-molina]

Agreed. Not a release blocker.

[nigzak]

Hi

you should include in V4 the following security updates:

• chore: update redis to >= 4.6.0 #27250 update redis dependency
  
• chore: upgrade setuptools/pip in Dockerfile #27405 update setuptools, based on update superset 3.1.0/3.1.1 dependency "setuptools 58.1.0" #26991
  
• certifi package should be updated, 2023.5.7 is outdated and has a high finding, latest is certifi 2024.2.2
  

/////
The following findings (high or critical) can NOT be fixed as of now (02.04.2024) in V4 because of ...
/////

• Debian Expat: no fix yet
  
• PIP: no fix yet
  
• Selenium: planned with V5, includes breaking changes
  

[thinkh]

Got it. Thanks for the clarification.

[nigzak]

Hint: the screenshots and comments are based on the actual dockerhub image 4.0.0RC2 - I made this comment because it is not part of RC2 and I wanted to avoid that already fixed things (or possible easy fixable things) are (again) missed in a first V4 RC3/stable release.
I would not have put this here if it would be updated already in RC2 - because of this I waited for next RC release and checked this (and not in "older" RC1).
I did not want to highlight some special updates somewhere in Superset V2/V3 with this - I only wanted to ensure it is also fixed in a next V4 version.
If there is a process that it is fixed in a V4.0 stable - all the better :)

[michael-s-molina]

@nigzak Now I understood. Sorry for the confusion 😄.

Major releases are time-based as you can see in our release process. That means that some fixes/features might miss the cut and will need to wait for the next release. This is a trade off of having a constant cadence of releases.

[nigzak]

Hi @michael-s-molina

thanks for your explanation.
Sadly this again means that I am not allowed to use a V4.0.0 because the security scans in other systems (JFROG, AWS, ...) are partly marking things even worse to "critical" than in my screenshot - and I am not allowed to deploy things with "high" or "critical" official without long (often senseless) discussions ...
This is also a reason why I cannot migrate as example to Superset 3.1.1 and I must stay on 3.0.x and have to wait for a next update (3.1.x has an additional critical CVE for which I made the pull request and wait for a next stable release).

I know that this might make sense for some reasons in your process to avoid that you on each iteration have to do many additional works and tests (and more).
Still it might (?) would make sense for CVEs (I am not talking about feature changes) to still include this in iterations - if there are no breaking changes (?) - but for sure that might be a big change to the process and I don't know all of your dependencies which might break it so I can only talk from my side about this ...
At least you have currently not a "critical" CVE marked by docker scout as you see in my screenshots - but as written up that is only one database source for CVEs and each system marks it slightly different (higher/lower)

At least for me that confirms that I sadly never ever can use a x.0.0 version ...
I hope at least that the done fixes then are re-integrated automatically in the x.0.1 versions (?)

[michael-s-molina]

Hi @nigzak. These are valid concerns. @dpgaspar is the one leading the efforts regarding CVEs so I suggest pairing up with him to see if we can mitigate some of the issues you are raising. In terms of releases, every security fix that is merged to master is always included in a patch/minor/major release depending on the changes. In other words, as long as you resolve the issues on master, they will eventually end up in a release. What we cannot do is block the releases until we resolve all possible third-party CVEs.

[sadpandajoe]

Just tried to do a migration and ran into this error. Not a blocker for us since most of our workspaces have been updated but others may run into this problem.

#27885

[michael-s-molina]

Issue closed. Check this comment for more context.