Conversation
Without the change build fails as:
audit_wrap.c:5010:15: error: invalid use of flexible array member
5010 | arg1->buf = (char [])(char *)memcpy(malloc((size)*sizeof(char)), (const char *)(arg2), sizeof(char)*(size));
| ^
Signed-off-by: Anders Kaseorg <[email protected]>
Co-authored-by: Guillaume Girol <[email protected]>
powerdns: fix 32-bit builds against glibc
https://savannah.gnu.org/forum/forum.php?forum_id=10157 https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=dc9740df61e575e8c3148b7bd3c147a81ea00c7c Fixes: CVE-2022-1271
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
CVE-2022-0891 CVE-2022-0865 CVE-2022-0924 CVE-2022-0907 CVE-2022-0909 CVE-2022-0908 (cherry picked from commit 748dfdd from PR #165872)
vcunat
requested review from
FRidh,
jonringer,
stigtsp and
zakame
as code owners
github-actions
bot
added
the
6.topic: python
|
I somehow chose the changes by hand, selecting all corresponding PRs with "security" label and then passing through all the merges in The powerdns commit got left in |
|
#166335 should probably go in |
...into staging-next
ofborg
bot
added
10.rebuild-darwin-stdenv
|
TL;DR: so that pycurl problem should be resolved now, both on master and also in a better way here on staging-next. |
Hi @vcunat, just to clarify. The idea is to merge this before the scheduled breaking changes freeze of staging/staging-next on April 17 and then open a new staging-next cycle with the pending staging commits from this cycle? |
|
April 17 is the first time restrictions apply for changes merging to staging(-next) branch. Commits that are there now certainly will reach 22.05. (Well of course, it can happen that some of them will be found out to cause too much trouble and reverted, as usual.) The release schedule itself even plans for two week-long staging(-next) iterations, though historically we typically struggled to make them that fast, so that part might happen a bit differently than planned. |
14 participants
I made this iteration a bit special, focused on security fixes and important bugfixes. And perhaps some other changes that have very low breaking potential. The purpose is to try making this iteration very fast, without requiring human work to progress, so that we don't block some notable problems:
workflow docs: https://nixos.org/manual/nixpkgs/unstable/#submitting-changes-commit-policy
constitutents: https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
jobset: https://hydra.nixos.org/jobset/nixpkgs/staging-next
Previous staging-next: #165406