-
Notifications
You must be signed in to change notification settings - Fork 713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for extracting attachments from OneNote section files #1048
Support for extracting attachments from OneNote section files #1048
Conversation
395151e
to
0a8b93a
Compare
I added 3 test tiles to demonstrate extraction of the clam.exe program from OneNote section files exported by OneNote 2007, OneNote 2010, and a recent Office364 OneNote export. If extraction were to fail, it would fail the libclamav unit tests as well as some clamd and clamscan tests. I have temporarily set the I think it's ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to address the hardcoded path before merging?
Ok fixed to remove hardcoded path and dead code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't flag all the spots where you could probably pull out some const
's in onenote.rs
for all those hardcoded hex strings.
c59d598
to
03ca53e
Compare
03ca53e
to
cf9a608
Compare
ca55c59
to
2633cbc
Compare
Includes rudimentary support for getting slices from FMap's and for interacting with libclamav's context structure. For now will use a Cisco-Talos org fork of the onenote_parser until the feature to read open a onenote section from a slice (instead of from a filepath) is added to the upstream.
While interesting, it does not appear this warning is useful to anyone.
995d0b5
to
c7413f8
Compare
In order to generate Rust bindings for C code, Rust's bindgen module needs to know where to find all headers included by the API. If they're all inside the project or inside the standard include path (e.g. /usr/include and /usr/local/include) that's fine. But for third- party C library headers from outside the standard include path, that's a problem. We didn't really notice this problem when generating on Unix systems until we switched to use OpenSSL 3.1 and tested on systems that have the OpenSSL 1.1.1 dev package installed. The ability to find headers outside the project path is also needed to generate bindings on Windows, if desired. This commit solves the problem by passing include directories for the ClamAV::libclamav CMake build target to the Rust build via the CARGO_INCLUDE_DIRECTORIES environment variable. Then, in the `libclamav_rust/build.rs` script, where we run bindgen, we split that `;` separated string into invididual paths and add each to the bindgen builder.
The fmap structure has some stuff that differs in size in memory between Linux and Windows, and between 32bit and 64bit architectures. Notably, `time_t` appears to be defined by the Rust bindgen module as `ulong` which may be either 8 bytes or 4 bytes, depending architecture (thanks, C). To resolve this, we'll store time as a uint64_t instead. The other problem in the fmap structure is the windows file and map handles should always be exist, and may only be used in Windows, for consistency in sizing of the structure.
Fix Coverity issues 192935, 192932, 192928, and 192917. None of these are particularly serious. I thought I'd clean them up while trying to track down a strange crash that occurs in Windows debug builds with my specific setup when freeing the metadata filename pointer malloced by the UnRAR iface "peek" function. I wasn't able to figure out why freeing that causes a crash, so instead I converted it to an array that need not be freed, and my troubles melted away.
dc435b3
to
2500f74
Compare
Resolves: #819
Also includes rudimentary support in libclamav Rust code for getting slices from FMap's and for interacting with libclamav's context structure.