Classic confinement for the `am-okay` program (a powerfull program allowing dynamically to copy or move files/dirs from the terminal)

store-requests
#1

Hello, my name is Baldé, I am a computer scientist.

I recently wrote a program called am-okay with the zsh and bash interpreters, the program in question allows copying or moving files or directories in a dynamic mode via a console(terminal).

With this program you can tag files or directories as items to copy or move via a console(terminal), and paste these items via a another console(terminal).

After installing the am-okay program, you can execute the command am-okay --help or am-okay --doc to get more information on how to use the am-okay program. A lot of actions are possible, you can even tag files or directories in arrays and paste them wherever you want in your Linux system.

For it to work properly, I need classic confinement.

The program in question acts on the cursor and other features of the Linux system. Here is a Github link of the am-okay program in deb extension: https://github.com/baldeuniversel/linux

Thanks you for understanding.

A classic confinement for the `am-okay` program (a powerfull program allowing dynamically to copy or move files/dirs from the terminal)
Suggestion about speeding up classic confinement queries for standalone shell programs
#2

Hi @baldeuniversel ,

Could you please explain more regarding the functionality of your snap and the reasons you think classic is needed.

Also, according to Process for reviewing classic confinement snaps, classic requests should fall under at least one of the supported categories. Could you please clarify if/how your snap fits within any of the supported categories? Thanks

#3

Hi ! @sahnaseredini

My program needs to classic confinement, because it allows dynamically to move and copy files and directories throughout the system from terminals, furthermore its use depends other programs like setterm.

For sure the orchestra of the program will be the user, he is the one who gives instructions.

Thanks for your understanding .

#4

Can you point to the category from the list of supported categories for classic confinement in the link amir posted that you think justifies classic confinement for your app ?

note that only apps fitting in one of the supported categories are actually allowed to gain classic confinement, this is a hard rule…

#5

Hi ! @ogra

I don’t know what you’re talking about .

#6

please see Process for reviewing classic confinement snaps which amir posted in the first reply above … there are two lists, to get approval for classic confinement your app must fit into one of the supported categories …

#7

Yep, my program fits in one of the scenarios, .

It’s about this :

terminal emulators, multiplexers and shells

#8

Ah okay, from your initial description it did only look like an extension of a shell (which is not covered by that category), but not actually like a standalone shell or multiplexer (which the category covers)…

Anyway, pointing to the correct category and describing why it fits there is an initial step the reviewers need from you to judge if it can get classic granted…

1 Like
#9

Yep, the program is a standalone shell. The interpreters used are zsh, bash, a lot of dependences are required like [setterm, gawk, bash, zsh …].

For the program to work, classic confinement is required.

#10

This is fine, just do not forget that snaps need to be fully self contained (independent of the confinement they use), so all your dependencies need to be shipped with the snap… i.e. i can install snaps on a busybox-only yocto build, so the required bits and pieces need to be included in your snap and utilized from it.

Also, would you mind making the title of your post a bit more descriptive (classic confinement for what app etc), there are 100s of posts in the store requests category and they are used as paper trails for users to look up why and how a certain exception was granted to a snap… it would be nice if a user could find this post in 2y when looking up why your snap was allowed the exception to be classic…

1 Like
#11

Okay, Well received !

I update now the topic.

1 Like
#12

@ogra how long will it take for the acceptance or evaluation of classic confinement ?

#13

The reviewers need to get to it and judge it… you need two positive reviews (IIRC the period for this is usually two weeks) … once granted there is a publisher vetting taking place after which the thing can go live in the store…

#14

@ogra okay !

Thanks for your help.

#15

From what I can see, this is a command-line application, it is not a shell itself - as such it does not fit within the existing category of shells / terminals for classic confinement. Unfortunately the snap model of strict confinement is not suitable for all applications and so some are not able to be easily packaged as snaps. I am removing this request from our queue, but if you have further information to provide then we can reopen this if required. Thanks.

#16

@alexmurray , the only languages used are zsh and bash.

#17

@alexmurray The program can not run properly without a classic confinement due the dependencies and the permissions of writing in different directories.

#18

confinement has nothing to do with dependencies, you would/will need to ship them inside your snap in any case, a snap needs to be fully self-contained so if you have any dependencies they need to be in your snap regardless if it is classic or strict, your snap needs to be installable on i.e. a yocto system that only comes with busybox sh and has neither bash or zsh installed, so you would have to include both of them in your package anyway for it to work. this is a hard requirement for snaps as i pointed out above already …

#19

Hi ! @ogra @alexmurray .

I have already shipped all the dependencies in the snap. The problem is that, as my program is accessed on copying and moving files, all directories except the home directory are not writable, unless you plug it manually (it’s an operation tedious and inefficient).

#20

Well, the unsupported categories explicitly have:

  • access to arbitrary files on the system because the application isn’t designed with confinement in mind

so i fear your app falls under this …