Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails

[Paul Gofman (＠gofman)]

On Wed Feb 25 16:00:26 2026 +0000, Christopher Denton wrote:
> The point of having an abort in the function is not security in itself.
> The aborting code path should never be hit. If it is then it's a bug in
> the underlying implementation that should *ideally* be fixed. And if
> such a bug does occur then users shouldn't rely on it (even if
> unintentionally). So the `abort` ensure the function fulfils the
> documented behaviour even if something else goes wrong.
> This whole discussion is focusing on formal handling of return status, but is missing the fact that read_dev_urandom() in ntdll (the only place where something can *theoretically* fail outside of process memory corruption, inventive hotpatching and such) doesn't have error checking / return at all. If this is a real concern it would make more sense to check the result and assert there instead of putting wrong things to the PE side (while I am personally still not sure about how that is useful too, reading random bytes is not supposed to fail in Unix the same way as on Windows, reinforcing that system is not totally broken in some arbitrary places doesn't look too much useful to me).

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130506