Fix: signature copy offset, CMAC slice, urandom FD #121
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes three correctness/security issues:
startIndex..endIndex
) instead of the entire array./dev/urandom
open: treat onlyfd < 0
as error (0 is a valid descriptor).Why these changes are correct
Signature copy offset
signIntoByteArray(destination, destinationOffset)
contract writes the full signature atdestinationOffset
. UsingcopyInto(destination, destinationOffset, destinationOffset)
erroneously interprets the offset as the source start index, truncating whendestinationOffset > 0
.copyInto(destination, destinationOffset, 0, size)
, i.e. copy from the start of the signature into the requested offset.public expect fun ByteArray.copyInto(destination: ByteArray, destinationOffset: Int = 0, startIndex: Int = 0, endIndex: Int = size): ByteArray
CMAC slice update (OpenSSL 3)
EVP_MAC_update(ctx, data, datalen)
digests exactly thedatalen
bytes starting atdata
. PassingsafeAddressOf(0)
andsource.size
ignores the requested slice and can MAC unintended bytes.safeAddressOf(startIndex)
and(endIndex - startIndex)
matches the streaming API’supdate(source, startIndex, endIndex)
contract./dev/urandom
file descriptor checkopen(2)
returns a non-negative file descriptor on success; only-1
indicates error. FD0
is valid (stdin) and can be returned depending on process state.fd <= 0
tofd < 0
avoids false-positive error handling.Impact
fd = 0
.Validation
Follow‑ups (separate PR)