February 2026 - Wine-GitLab

Re: [PATCH v3 0/6] MR10183: msxml/tests: Extend PI test with newlines. - approved
by Alexandre Julliard (＠julliard) Feb. 25, 2026

Feb. 25, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10183

1 0

[PATCH 0/3] MR10189: kernel32, ntdll: Fix some test failures related to NtQueryDirectoryFile().
by Elizabeth Figura (＠zfigura) Feb. 25, 2026

Feb. 25, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10189

2 1

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 18:54:58 2026 +0000, Paul Gofman wrote: > > I don't really understand why we're doing this in the first place. The > documentation often claims things that are wrong especially as related > to edge cases. If there's not a foreseeable case where RtlGenRandom() > could fail (and I don't think memory exhaustion counts as foreseeable > either) then I don't think it's worth touching. > Yeah. And I honestly don't see how even memory exhaustion is a bad case > here, there is no new allocations on the way. And if page in for > previously allocated buffer space fails the process will be OOM killed > without our abort. There is actually one real thing in that place: > int fd = open( "/dev/urandom", O_RDONLY ); That can fail due to fd exhaustion. But instead of asserting we'd probably be better off caching the fd, file open takes time while getting random values may happen often in some cases (and get_random is used very early for the first time, to fill process cookie). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130526

1 0

[PATCH v3 0/1] MR10187: bcryptprimitives: Ensure ProcessPrng fills the whole buffer
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

[`ProcessPrng`](https://learn.microsoft.com/en-us/windows/win32/seccng/processprng) takes a `SIZE_T` argument for its length whereas [`RtlGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom) takes a `ULONG`, which may be smaller. -- v3: bcryptprimitives: Ensure ProcessPrng fills the whole buffer https://gitlab.winehq.org/wine/wine/-/merge_requests/10187

2 1

[PATCH 0/2] MR10188: msxml/tests: Add some more tests for the ownerDocument() property.
by Nikolay Sivov (＠nsivov) Feb. 25, 2026

Feb. 25, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10188

2 1

[PATCH 0/1] MR10187: bcryptprimitives: Ensure ProcessPrng fills the whole buffer
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

[`ProcessPrng`](https://learn.microsoft.com/en-us/windows/win32/seccng/processprng) takes a `SIZE_T` argument for its length whereas [`RtlGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom) takes a `ULONG`, which may be smaller. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10187

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

> I don't really understand why we're doing this in the first place. The documentation often claims things that are wrong especially as related to edge cases. If there's not a foreseeable case where RtlGenRandom() could fail (and I don't think memory exhaustion counts as foreseeable either) then I don't think it's worth touching. Yeah. And I honestly don't see how even memory exhaustion is a bad case here, there is no new allocations on the way. And if page in for previously allocated buffer space fails the process will be OOM killed without our abort. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130523

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 18:50:59 2026 +0000, Elizabeth Figura wrote: > I don't really understand why we're doing this in the first place. The > documentation often claims things that are wrong especially as related > to edge cases. If there's not a foreseeable case where RtlGenRandom() > could fail (and I don't think memory exhaustion counts as foreseeable > either) then I don't think it's worth touching. The documentation is right as far as I'm aware and the whitepaper explains that it was an intentional decision that people can rely on. So I do think that wine should behave as close to Windows as reasonably possible. And after looking at it closer I think wine already does exhibit the same behaviour in practice. So I'm coming round to the idea that this doesn't need to be handled in `ProcessPrng`. I am thinking it might be appropriate to more strongly guarantee this at the actual point where we return an error, e.g. https://gitlab.winehq.org/cdenton/wine/-/commit/93ed99966b316f4c9c1e03af7de… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130522

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Elizabeth Figura (＠zfigura) Feb. 25, 2026

Feb. 25, 2026

I don't really understand why we're doing this in the first place. The documentation often claims things that are wrong especially as related to edge cases. If there's not a foreseeable case where RtlGenRandom() could fail (and I don't think memory exhaustion counts as foreseeable either) then I don't think it's worth touching. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130521

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 17:52:11 2026 +0000, Paul Gofman wrote: > Even for ERR I'd also think a formally better place for that would be > ntdll/unix/system.c:read_dev_urandom() (after checking that read to the > requested size actually succeeded). But yet I am still failing to see > how that changes anything in practice, the code is not supposed to fail > there as well. Maybe assert( ret == len ) in the end of the function > (with appropriate move ret definition) would make some sense. Hm, ok so I think this could instead be handled at different level by upgrading the existing `WARN` to `ERR` in `fill_random_buffer` and `assert` the failure case never happens in `SystemFunction036` (aka `RtlGenRandom`). E.g. something like https://gitlab.winehq.org/cdenton/wine/-/commit/93ed99966b316f4c9c1e03af7de… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130519

1 0