Add FileEntryMetadata to FileEntry for permissions, ownership, and special bits

[Copilot]

• Create FileEntryMetadata class with nullable properties: Mode (long?), IsExecutable (bool?, derived), IsSetUid (bool?, derived), IsSetGid (bool?, derived), Uid (long?), Gid (long?)
• Add Metadata property of type FileEntryMetadata? to FileEntry class (null by default)
• Update TarExtractor to populate metadata from TarArchiveEntry.Mode, UserID, GroupId
• Update ZipExtractor to populate metadata from ZipArchiveEntry.Attrib (Unix permissions from upper 16 bits)
• Update RarExtractor to populate metadata from RarArchiveEntry.Attrib
• Update SevenZipExtractor to populate metadata from SevenZipArchiveEntry.Attrib
• Update ArFile to parse UID, GID, and mode from the ar header bytes (28-33: uid, 34-39: gid, 40-47: mode octal)
• All Attrib property access wrapped in try-catch with trace logging including archive type and file path
• Add tests for metadata extraction (8 tests: tar async/sync, ar async/sync, defaults, derived properties, setuid/setgid)
• Restore nuget.config to original configuration

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add file metadata to FileEntry</issue_title>
<issue_description>It might be interesting to some consumers what the stated permissions and other metadata is available about the file. For example, some files could unzip with chmod +x and be executable.

This requires first to see what common factors are shared between SharpZipLib extracted entries, and also LibObjectFile file entries. For LibObjectFile entries reading real filesystems this is particularly interesting. Deciding on a new schema for FileEntry - either a number of fields or a FileMetadata object.

This is a feature request related to Attack Surface Analyzer.</issue_description>

<agent_instructions>Investigate adding this feature. I think the right way to do this would be to add a new property to FileEntry that itself has metadata attributes, so we can expand that over time without addition changes directly to the FileEntry interface. First you will need to investigate which attributes are available for each respective extractor type, I tihnk what we care about is the attributes that will persist when the file actually hits a disc (though, these attributes are only important when extracting to FileEntry via Lib for API consumers performing in memory analysis). Very important ones we should look for on all extractos when possible is if the extracted file will be marked executable, permissions, timestamps, setuid/setgid maybe? You can expand this if there are others that make sense. Also be sure to have sane default values that should make it clear that the attribute wasn't available to us (should it be null?), some formats afterall will not actually have all the same attributes available (or they may not be exposed by the APIs we are using for those formats). There are some extractors where we own the implementation (Ar files for example) which should also be pretty simple to recover much of this information from, but where we have to build the implementation.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Add file metadata to FileEntry #82

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[gfs]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).