It seems you are correct. That’s probably worth updating but in the meantime your system-files-hugepages will have to do.
I don’t know a better way for the /dev access you need. raw-volume looked promising but is only suitable for Ubuntu Core which I’m guessing isn’t the target for this snap. Given the specific purpose of the snap and the intended use/users, perhaps the /dev/* access may have to be granted. I think we would need a disclaimer in the snap description warning users that the snap is highly privileged.
Ok. Makes sense. I will update the snap removing browser-support, and adding something in the description along the lines of “Disclaimer: due to the system access necessary for Autopsy to perform correctly, this snap is highly privileged”
@dclane, I uploaded a new version of the snap removing browser-support and added a disclaimer to the description. If there is anything else I can do on my end, please let me know. Thanks!
As an occasional user of Autopsy, I appreciate your request and understand the need for these plugs, so that I will definitively support the decision to grant them the ability to connect.
However, as a store reviewer, I also need to consider that most of these interfaces are superpriveleged, and given that the target audience of this software should not face major difficulties to manually connect them, I would suggest to not grant them auto-connect.
Hi @jslarraz, just to make sure I understand, you are suggesting that the super-privileged interfaces should have the ability to connect, but not granted auto-connect? So dm-crypt, block-devices, desktop-launch, and system-files access to /dev could be left in the snapcraft.yaml for the user to connect if they desire, and fuse-support, removable-media, mount-observe could be auto-connected? Based on the conversation with @dclane, it seems that system-files read access to /sys/kernel/mm/hugepages is comparable in behavior to hugepages-control. Given that hugepages-control is not super-privileged, is this system-files read access super-privileged in your mind?
I like the suggestion of @jslarraz to allow connection of these super-privileged interfaces but not to auto-connect them. The concern I have with the original proposal is that it is very permissive and when considering the voice of the user it doesn’t seem unreasonable to ask them to connect the interfaces allowing these access themselves.
What I think would satisfy the review team and not be too onerous for users would be:
auto-connect:
dm-crypt (super-privileged)
block-devices (super-privileged)
desktop-launch (super-privileged)
fuse-support
mount-observe
hugepages-control
system-files (hugepages) (super-privileged)
manual-connect:
system-files (/dev) (super-privileged)
removable-media (super-privileged)
The reason I propose breaking them into these categories would be that these two interfaces that would still require manual connection are likely the easiest for your users to understand, and of course they’re highly sensitive.
I’ll ask @Igor to chime in too, because we will need to complete publisher vetting in order to allow the use of the super-privileged interfaces, so perhaps it is worth kicking that off now.
I think what you and @jslarraz are proposing could work. We can update our documentation regarding how to properly setup connections in the Autopsy snap for the manual-connect plugs.
I would also suggest not to have super-privileged interfaces auto-connected
Are you saying that you agree with @dclane’s suggestion here ?
Regarding the description, would something like this suffice?
Autopsy is a graphical interface to The Sleuth Kit and other open source digital forensics tools.
Disclaimer: due to the system access necessary for Autopsy to perform correctly, this snap is highly privileged and uses the following interfaces:
block-devices, dm-crypt, fuse-support, removable-media, mount-observe, and system-files-dev (system-files read access to /dev) to find and ingest data sources
system-files-hugepages (system-files read access to /sys/kernel/mm/hugepages), and hugepages-control to run Solr for indexing keywords in files, which in turn uses hugepages for performance implications
desktop-launch to launch file manager to view autopsy log folders, web browsers online/offline help, and user default applications for opening extracted files in external applications
+1 from my side, I agree with the suggestion made by @dclanehere, it makes sense to have these two interfaces system-files on having read access to /dev and removable-media to be manually connected and remaining to be auto-connect
Thank you very much! Moving forward, when Autopsy has a new release (i.e. we move from 4.21.0 to 4.21.1 or 4.22.0), what is the process for updating the snap? I’ve done some reading here. Ideally from my perspective, we may create a candidate risk level release or possibly multiple candidate releases if we find bugs. Then, when we are satisfied with a particular candidate, we would move a candidate into stable and it would be the default option for users to install from the snapcraft store. Is that workflow possible, and if so, what uploads to the store and store requests would need to be made? I’m assuming we would need to upload all of the candidate releases, but is there a way to move a candidate to stable? I noticed there is a “promote” button next to the release. Would I use that? Also, for any store requests that need to be made, what is the easiest/fastest way to get a new release approved?
Also, I was looking over the page for the Autopsy snap. I noticed that the icon and license were missing. Currently, in the snapcraft.yaml, I have icon: snap/gui/autopsy.png which seems to be a valid path relative to the snap root, and the image is 256x256. For license, I have license: Apache-2.0 which appears to be a valid SPDX license here. Is there something I need to do to have those fields corrected?
Also, is there a way to make the publisher of Autopsy the name of the organization as opposed to my user account and allow multiple people to publish?
If you’re building locally and uploading with snapcraft upload then you can use the --release flag to choose which channel to release to (edge, beta, candidate or stable), so yes the workflow you propose is spot on. If you release initially to candidate and later determine you’re happy with that revision then you can promote it to stable just by dragging that revision up to stable on the autopsy releases page.
All revisions that get uploaded to the store will go through review but they wont need any extra manual reviews unless you start using super-privileged interfaces.
Regarding the icon and license issues, I am not an expert on these but I know they can be manually set on your Autopsy listing page. You should also be able to manage collaborators here. As for the publisher name, I think you would have to create a new account representing the organisation and publish it to that account. You could do that with yourself as a collaborator.
