python3Packages.apache-airflow: 2.5.0 -> 2.5.1 #214565
Conversation
…better while you'd think `allowAliases = false` would do this job for us, some still seem to slip through. deduplicate packages with the same outpath before checking for multiple results. avoid use of `assert` for raising failures as python considers these statements omittable.
|
I just stumbled upon this PR while trying to update Apache Airflow to 2.5.2 since it was bumped to 2.5.1 in 067b77f For reference my attempt for 2.5.1 -> 2.5.2: LeSuisse@9d210dc |
|
https://www.openwall.com/lists/oss-security/2023/05/08/2 IMO: No maintainer feedback for months, let's mark it insecure and drop it a few months down the road. |
|
Didn't see this before, happy to take a look. |
|
It looks like @risicle has already done some work on this. It's blocked by the fact that flask-appbuilder doesn't work with flask-sqlalchemy >= 3, which has already been upgraded in nixpkgs. There is a draft PR but it hasn't been progressed since last year. I've filed dpgaspar/Flask-AppBuilder#2038 to try to move it along. One option would be to add separate versions of these dependencies within apache-airflow, similar to what we do for home-assistant. Since airflow is often used as a standalone server process this might be to too terrible. |
Where do we do what exactly for Home Assistant? Home Assistant is in a different boat, since it uses |
I was referring to this: Airflow is both an application and a python package, and it's feasible to use it as a standalone app without necessarily having the module importable in a larger package set (e.g. people can use shell command tasks, and run a separate python interpreter from them if they want). So my suggestion is to mark apache-airflow as broken in pythonPackages, add 'local' dependencies for flask-appbuilder et al. (if feasible without a huge amount of work), so that pkgs.apache-airflow can be made to work. Then hopefully the dependency issue resolves over time and we can remove the hacks and re-enable the python package. Let me know if that makes sense. It's obviously far from ideal! |
|
IMO the airflow package should be moved out of the python package set. All packages that require it as a library can then live inside its own python package set instead. The idea for home-assistant was this: diff --git a/pkgs/servers/home-assistant/default.nix b/pkgs/servers/home-assistant/default.nix
index c31862f59d1a..13fc0d523855 100644
--- a/pkgs/servers/home-assistant/default.nix
+++ b/pkgs/servers/home-assistant/default.nix
@@ -300,6 +300,7 @@ let
# internal python packages only consumed by home-assistant itself
home-assistant-frontend = self.callPackage ./frontend.nix { };
home-assistant-intents = self.callPackage ./intents.nix { };
+ homeassistant = super.toPythonPackage home-assistant { };
})
]; |
|
Hopefully superseded by #231944 |
|
Superseded by #235081. |
Description of changes
https://nvd.nist.gov/vuln/detail/CVE-2023-22884
This is an attempted security-bump of a currently-broken package - it can't sensibly be merged yet. That said, this can be tested by temporarily reverting commits 46a2dfc and 6d10040.
This should be properly fixed once flask-appbuilder adds support for flask-sqlalchemy >= 3 (see dpgaspar/Flask-AppBuilder#1940 for some possible movement), but in the meantime I'm going to turn my attention to the stable branch...
Note the minor changes I made to the
update-providers.pyscript here. More details on this in the commit comment.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes