uuid known bugs

### Summary `v3`, `v5`, and `v6` accept external output buffers but do not reject out-of-range writes (small `buf` or large `offset`). By contrast, `v4`, `v1`, and `v7` explicitly throw `RangeError` on invalid bounds. This inconsistency allows **silent partial writes** into caller-provided buffers. ### Affected code - `src/v35.ts` (`v3`/`v5` path) writes `buf[offset + i]` without bounds validation. - `src/v6.ts` writes `buf[offset + i]` without bounds validation. ### Reproducible PoC ```bash cd /home/StrawHat/uuid npm ci npm run build node --input-type=module -e " import {v4,v5,v6} from './dist-node/index.js'; const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8'; for (const [name,fn] of [ ['v4',()=>v4({},new Uint8Array(8),4)], ['v5',()=>v5('x',ns,new Uint8Array(8),4)], ['v6',()=>v6({},new Uint8Array(8),4)], ]) { try { fn(); console.log(name,'NO_THROW'); } catch(e){ console.log(name,'THREW',e.name); } }" ``` Observed: - `v4 THREW RangeError` - `v5 NO_THROW` - `v6 NO_THROW` Example partial overwrite evidence captured during audit: ```text same true buf [ 170, 170, 170, 170, 75, 224, 100, 63 ] v6 [ 187, 187, 187, 187, 31, 19, 185, 64 ] ``` ### Security impact - **Primary**: integrity/robustness issue (silent partial output). - If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error. - In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw. ### Suggested fix Add the same guard used by `v4`/`v1`/`v7`: ```ts if (offset < 0 || offset + 16 > buf.length) { throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`); } ``` Apply to: - `src/v35.ts` (covers `v3` and `v5`) - `src/v6.ts`