After receiving the upload, the store performs an automated review of the snap file. If no errors are found, the store makes the snap immediately available to users.
If the automated check finds any errors, Snapcraft will give a brief summary and guidance on how to correct each one. Correct all the errors, rebuild the snap, then upload it again. Continue retrying until successful.
My understanding from reading this was that the snap would be automatically reviewed. However, it was instantly put under ManualReviewPending. Why is that? How long should developers expect for their snaps to be reviewed? Is every snap, on every upload human-reviewed? How is this scalable?
My guess is that my uploaded elmerfem snap uses network-bind, and that’s why it’s flagged as “potentially malicious”.
I see no way to enter comments on the store or review dashboard, so I’ll add them here to justify the usage, in case it helps with manual review. @policy-reviewers@store, FYI:
The goal: replace the elmer-csc PPA binaries bundled in the freecad snap. We’re in the process of upgrading the freecad snap from core22 to core24, and there are no 24.04 builds in the Elmer CSC PPA. Besides, the PPA is one of the reasons we’re blocked from building arm64 binaries. That’s why I’m attempting to build Elmer as a snap instead, and to use it as stage-snaps to be bundled in the freecad app.
The why: elmerfem is a snap of the Elmer FEM solver, a scientific computing application that uses the OpenMPI (Message Passing Interface) library for parallel processing. The network-bind plug is required for the OpenMPI runtime to initialize correctly. Diagnostics confirm this sequence of events:
When the solver starts, it calls the MPI initialization function (MPI_Init). This function must set up a communication channel for MPI processes.
Even for a single process running on a single node, OpenMPI’s default mechanism for this involves starting a helper daemon (orted). The main process and this daemon coordinate using the network stack.
To establish this communication, one of the processes acts as a server by binding to a TCP port and making a listen() system call.
The OpenMPI library as packaged in Ubuntu does make these listen() calls on TCP sockets during startup.
In a strict confinement snap, this listen() call is correctly blocked by the sandbox, resulting in an “Operation not permitted” error and causing the entire MPI initialization to fail, which crashes the application.
The network-bind plug is the specific permission for the listen() call to succeed, enabling the MPI runtime to work.
As an additional note, on the current freecad snap, this all works because freecad itself declares network-bind indirectly, via the kde-neon (or in the core24 snap kde-neon-6) extension. I guess that as a workaround, network-bind could be dropped from the elmerfem snap, since its main purpose is to be added as a dependency bundled within the freecad snap. But it would be a pity to diminish the standalone elmerfem snap for others wanting to use it without freecad.
Also note I’ve registered two namespaces by mistake: elmer-csc should be removed, but I cannot do it myself, since it has uploads pending manual review (which can be discarded). elmerfem should be kept.
