Skip to content

Conversation

@Miauwkeru
Copy link
Collaborator

  • Add supported targets page with an extension
  • Add the defaults for every type
  • Remove unnecessary spaces from files
  • Let autoapi also discover all _os.py modules

closes #84

@Miauwkeru Miauwkeru requested a review from Schamper July 29, 2025 14:48
@Miauwkeru
Copy link
Collaborator Author

Miauwkeru commented Jul 29, 2025

When testing against autoapi, I did notice that a few projects fail when generating the api documentation. These are:

I'll make a ticket for those projects

@Miauwkeru
Copy link
Collaborator Author

How the table generation works. We have some default csv files that contain the descriptions.
for example _defaults/filesystems.csv contains the descriptions for all the different filesystems.

the _ext/supported_targets.py extension maps those descriptions together with all the filesystems it can find (within dissect.target.filesystems) and generates a csv file inside the supported_targets/ directory . (e.g. supported_targets/filesystems.csv ). If a description is missing for a specific filesystem it will generate a warning containing information on how to resolve it.

The output format depends on the type of file being generated (loaders looks different from filesystem for example), but it comes down to:

Class, ..., Description
:class:`link.to.filesystem.Filesystem`, ..., "Description for the filsystem"

the supported-targets.rst file uses a csv-table to read the generated csv file.

@Miauwkeru Miauwkeru force-pushed the supported-targets branch from 38dd213 to 981e014 Compare July 30, 2025 11:35
Copy link
Member

@Schamper Schamper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the original ticket did warn that an automated approach might be hard and not lead to a high enough quality result. If you do still intend to attempt to do it in an automated fashion, it must be better and lead to as high a quality result as a handcrafted table.

return [loader.realattr for loader in LOADERS_BY_SCHEME.values()]


SUPPORTED_SYSTEMS = [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this so complex? What's wrong with just iterating i.e. loader.LOADERS?

Besides, it's giving a wrong impression on things that are supported. Not everything that's in dissect/target/filesystems is actually supported or should be listed here. Who cares about ITunesFilesystem if it can't actually be manually opened or selected? What value is there in knowing that it exists? I do care about the ITunes Backup loader (not ITunesLoader, what's that?).

This page should reflect what a user can expect from Dissect, not a factual representation of what modules and classes exist. I open the API documentation if I was looking for that.

Comment on lines 9 to 13
.. Descriptions can be reworded by changing _defaults/loaders.csv
.. csv-table:: Supported Loaders
:header-rows: 1
:file: /supported_targets/loaders.csv
:widths: 15 10 25
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CSV approach sucks a bit, is there not a better way? Maybe a custom table directive where you can manually override entries, keyed on the module name?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought a bit further about it, and having a plugin automatically generate it will be more effort than it is worth. So I opted to write it manually

The contents get generated from the files inside of defaults_/*.csv
These were generated by taking the first line from the class its
docstring
@Miauwkeru Miauwkeru marked this pull request as draft October 8, 2025 15:28
Copy link
Member

@Schamper Schamper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, remember that this page should not have too much implementation details. Someone reading this should not have to know what a plugin is. Any and all links or references to more in-depth or API stuff should be optional links, and not part of the main text.

Also, maybe vibe some sentences to make them flow nicer.

Shell </target-shell>
Mount </target-mount>
Acquire </acquire>
Supported Targets </supported-targets>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe put this just above tutorial?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a change in this PR, but why does this page like to dissect.target and not dissect? And "github" is not even properly capitalized...

Get in touch, join us on github <https://github.com/fox-it/dissect.target>_!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question

~~~~~~~~~~~~~~~~~


Dissect includes a range of ``OSPlugins`` that help identify the operating system present on a target.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Dissect includes a range of ``OSPlugins`` that help identify the operating system present on a target.
Dissect includes a range of ``OSPlugins`` that help identify the operating system present on a target.

Unnecessary detail? Just say we support various operating systems.

:header-rows: 1
:widths: 20

* - Operating System
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some improper capitalization in this list.

:widths: 20

* - Operating System
* - :class:`Android <dissect.target.plugins.os.unix.linux.android._os.AndroidPlugin>`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe don't list this alphabetically, but rather sorted by inheritance.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll sort it by inheritance

* - Child Target
- Description
* - :class:`Colima <dissect.target.plugins.child.colima.ColimaChildTargetPlugin>`
- Child target plugin that yields Colima containers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Child target plugin that yields Colima containers.
- Colima containers.

This prefix is unnecessary. And what is Colima? Just add one line for everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Maintain full list of supported "targets"

3 participants