Electron Releases

Description of Change

Before: the native asar reader used the archive's header size field and each entry's size/offset as-is. A truncated or otherwise malformed archive (header size larger than the file, a negative entry size, or an entry extending past the end of the file) could make fs calls on it fail in confusing ways rather than reporting a clean error.

After: the header size is checked against the archive's actual length when the archive is opened, and entries whose size is negative or whose range does not fit inside the archive are treated as missing. This matches the validation @electron/asar already does in JS, so malformed archives now surface as "Invalid package" / ENOENT consistently across both readers.

How: Archive::Init() records the file length and rejects an oversized header before reading it; FillFileInfoWithNode() takes the file length and bounds-checks offset + size against it. Specs build small malformed archives on the fly and assert the fs wrapper reports them as invalid/missing.

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• npm test passes
• tests are changed or added

Release Notes

Notes: Fixed handling of malformed asar archives whose size fields do not match the file length.