Classic confinement request for graalvm-jdk

store-requests classic-confinement
1

Here are the details

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

The other upstream link (which I couldn’t mention) due to the restriction on the number of links is: GitHub - oracle/graal: GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀

3

The snaps (–beta and --edge) currently pushed to the store use devmode. Let me know if I need to change this to classic before the review process is started.

4

Hey @pushkarnk,

In general classic confinement requires of publisher vetting, which has following objective:

To ensure that the publisher of a snap is genuinely associated with the upstream project or belongs to a trusted group (e.g., Snapcrafters, Canonical, Verified Accounts ).

Considering the provided information (upstream-relation: user) I think you don’t meet this criteria (please correct me). Thus, I think the best option to proceed here would be to ask the upstream if they are willing to incorporate the snap package to the upstream repository (or a different upstream maintained repository).

Thanks

5

Hi @jslarraz

Thank you for the information. The graalvm-jdk snap has now been transferred under the Canonical org. Can we please revisit the classic confinement request? Please do let me know if you need any other information.

6

Hey @pushkarnk

Looking at the reasoning:

GraalVM will need access to Java source and other binaries (JAR files) to compile and build a native image.

  • Java source refers to the application code that will be compiled? If so, I think home + potentially removable media should be enough
  • other binaries (JAR files): could you please clarify what is the origin of those binaries in the most general cases?

Thanks