Release 0.9.68 discussion

[kmk3]

Release links:

• Project board: https://github.com/users/netblue30/projects/2
• GitHub Release: https://github.com/netblue30/firejail/releases/tag/0.9.68

Discussions for the previous releases:

• Must-fix bugs for release 0.9.64 #3618
• Next release (0.9.64.2 / 0.9.66) #3696

Discussion for the next release:

• Release 0.9.70 discussion #5181

---

The latest release (0.9.66) was made on 2021-06-29, which is almost 6
months old. There have been many profile fixes since then and I remember
seeing quite a few issues opened that were caused by old firejail/profile
versions in the mean time. Also, it already has a new arguably major feature,
the Intrusion Detection System (IDS). So I think it would be nice to have a
release by the end of the month (or next month at least).

With that said, is there anything blocking the next release? Post whatever you
think is broken, missing, etc.

Anyway, I also created a Project to track whatever we come up with:

• https://github.com/users/netblue30/projects/2

Cc: netblue30

[kmk3]

With that said, is there anything blocking the next release?

To me, the main thing that comes to mind is this:

• GitLab CI broken: Lintian failure because of binary in /etc (profstats) #4733

Because, as @rusty-snake said, it violates packaging guidelines (at least
Debian's and probably more) and so currently at least some workarounds would be
required to package firejail.

[rusty-snake]

• telegram-desktop: screen sharing doesn't work #4711 -- add the screen-sharing snippets from firefox/chromium
• firejail tree+list flags bypass hidepid mounted /proc displaying details of other users sandboxes #4705
• Allow apostrophe in whitelist (and blacklist) #4614 -- sounds like a small change
• noprinters #4607 -- update RELNOTES
• supertuxkart: cannot see controller without netlink #4605
• brave: program takes a long time to open #4604 -- consider to comment private-cache for now
• --build creates invalid paths with "after,$HOME" $HOME expanded #4592
• telegram-desktop: program does not shutdown #4511 -- fixed by deterministic-shutdown?
• Code scanning alerts (CodeQL CWE-367/TOCTOU warnings) #4503
• [Meta] Handling of background processes / services / agents / daemons #4440 -- can some of them closed with deterministic-shutdown?
• Firejail rejects empty arguments #4395
• Seccomp list output goes to stdout instead of stderr #4328 -- maybe move this to stderr for now
• terminal window title is not restored after firejail exits #4197
• Unset TMP if it doesn't exist inside of sandbox #4151 -- sound like a small change
• Document that private-etc and private-bin always accumulate #4078 -- add a note to the manpage
• Paths in app profiles with ^ and ! wildcards in them are not expanded #3862 -- allow [! or wontfix
• google-earth-pro: program does not start (private-bin) #4683 -- add readlink to google earth

[kmk3]

• noprinters #4607 -- update RELNOTES

Added. Good catch; I noticed some more things that could be in the RELNOTES.
I'll add them later.

• telegram-desktop: program does not shutdown #4511 -- fixed by deterministic-shutdown?

This may already be fixed; added a comment.

• Code scanning alerts (CodeQL CWE-367/TOCTOU warnings) #4503

I think most of these potential race conditions were already there on 0.9.66,
the only difference being that CodeQL points them out now. So I don't think
it's a blocker, but a nice-to-have. So how about splitting the original list
into a blocker list and a nice-to-have list?

• Firejail rejects empty arguments #4395
• Seccomp list output goes to stdout instead of stderr #4328 -- maybe move this to stderr for now
• terminal window title is not restored after firejail exits #4197
• Unset TMP if it doesn't exist inside of sandbox #4151 -- sound like a small change
• Document that private-etc and private-bin always accumulate #4078 -- add a note to the manpage
• Paths in app profiles with ^ and ! wildcards in them are not expanded #3862 -- allow [! or wontfix

These issues are older than 0.9.66. Some, like #4151 and #4078 indeed seem
easy enough, though they could be made later in e.g.: a 0.9.67.1 release.

• telegram-desktop: screen sharing doesn't work #4711 -- add the screen-sharing snippets from firefox/chromium
• firejail tree+list flags bypass hidepid mounted /proc displaying details of other users sandboxes #4705
• Allow apostrophe in whitelist (and blacklist) #4614 -- sounds like a small change
• supertuxkart: cannot see controller without netlink #4605
• brave: program takes a long time to open #4604 -- consider to comment private-cache for now
• --build creates invalid paths with "after,$HOME" $HOME expanded #4592
• [Meta] Handling of background processes / services / agents / daemons #4440 -- can some of them closed with deterministic-shutdown?
• google-earth-pro: program does not start (private-bin) #4683 -- add readlink to google earth

Most of the other things seem to be problems that may also happen with 0.9.66
(or that were caused by new program versions rather than by firejail). Is
there any that you think was caused by commits after 0.9.66? The next release
doesn't have to be perfect, just better than the previous one. Especially
since fixing all of that could mean even more months until a release is made.
And I think it would be important to have releases more often, as profiles tend
to become broken over time due to program upgrades.

As a user, this is generally what I expect when installing new versions of
programs (in order of importance):

1. No breakages (not without a very good reason at least)
2. Bugfixes
3. New features (optional)

Anyway, the main goal of this thread is to find this: What are the things that
could make a user worse off by installing from master compared to 0.9.66?

The categories that first came to mind are:

• Functionality regressions: Features/profiles that work on 0.9.66 but not on
  master
• Performance regressions: firejail taking N times longer to run
• Incompleteness: Features that were added but that do not work fully as
  intended or that are not documented properly

[kmk3]

@netblue30 commented on Jan 16:

Anyway, I'm going for a test release (0.9.68~rc1) next week, the big release
two weeks later. We can wait to bring in pipewire if needed.

Shouldn't that be "0.9.67~rc1"? Or is skipping "67" intentional?

[rusty-snake]

firejail uses (old) unix style versioning, meaning odd-numbered versions for development releases and even-numbered versions for stable releases.

For firejail this means

• 0.9.<odd number>: development version
• 0.9.<even number>: stable version
• 0.9.<even number>.<minor>: minor patch if the were bigger regressions in a release
• 0.9.<even number>-rcN: release candidate
• 0.9.<even number>(.<minor>)-LTS: for LTS versions

[kmk3]

@rusty-snake on Jan 18:

firejail uses (old) unix style versioning, meaning odd-numbered versions for
development releases and even-numbered versions for stable releases.

For firejail this means

* `0.9.<odd number>`: development version
* `0.9.<even number>`: stable version
* `0.9.<even number>.<minor>`: minor patch if the were bigger regressions
  in a release
* `0.9.<even number>-rcN`: release candidate
* `0.9.<even number>(.<minor>)-LTS`: for LTS versions

Ahh I see. Interesting, I only remember seeing the even/odd style being used
by Linux for LTS releases or something like that.

Now looking at the previous releases in the RELNOTES I can see it. Weird, I
never really noticed this.

Anyway, I updated the title to 0.9.68 in here and in
https://github.com/netblue30/firejail/projects/4.

[netblue30]

rc1 is out, two more weeks to fix some of the bugs here. Let's keep this discussion open for whatever more problems are coming.

[kmk3]

@netblue30 on Jan 19:

rc1 is out, two more weeks to fix some of the bugs here. Let's keep this
discussion open for whatever more problems are coming.

Could you name a specific intended date for the release (as in, it would not be
released before day X)?

I'd like to make sure that some things are organized before a release is made.
Mostly RELNOTES, as there are some IMO important items missing (I'm working on
it).

[netblue30]

Saturday, Feb 5, and we push it with one more week if we run into problems.

[kmk3]

@netblue30 on Jan 22:

Saturday, Feb 5, and we push it with one more week if we run into problems.

Could it be pushed another week? I'd like to finish organizing some things on
the RELNOTES. There is also #4883 on the todo list.

[rusty-snake]

@miragy69 at keepassxreboot/keepassxc#7317 (comment):

Summary

Keeppassxc can't detect any hardware key after get in the jail. Hardware serial number is detectable. (Edited) Please reassign the label if needed.

Temporary solution

The issue can be solved by commented out these applications under /usr/lib/firejail/firecfg.config. Then # firecfg --clean && firecfg for recreate links again for commenting out the keepassxc-proxy can solve the issue #6230, i.e. you don't have to manually click reload on browser plugin for password autoloading.

Looking for future support on firejail

It will make safer for running keepassxc in the firejail, if the above issue can be solved. Many thanks.

---

Possible solutions:

1. Add a comment (Put 'ignore nou2f' and 'ignore private-dev' in your keepassxc.local).
2. Remove nou2f and a a comment for private-dev (If you need to plugin devices while kpxc is running add ...)
3. Remove both, nou2f and private-dev.

I'm not sure which one is the best, but I think we should fix this for 0.9.68.

[kmk3]

@rusty-snake on Jan 27:

@miragy69 at keepassxreboot/keepassxc#7317 (comment):

Summary

Keeppassxc can't detect any hardware key after get in the jail. Hardware
serial number is detectable. (Edited) Please reassign the label if needed.

I agree with fixing this for 0.9.68, though I think that it would be better to
track it on a new issue.

[rusty-snake]

Done, #4883

[netblue30]

Release tomorrow (Sunday), check in today anything else you have!

A short video about --netlock: https://www.brighteon.com/0d8aea4a-fa61-406d-9f37-dcf54204b0c1
There is a lot of work to go in there, but will have to do it for now.

[tomasz-c]

I noticed that the kodi profile for firejail 0.9.68 does not seem to work.
After running kodi:

firejail --profile=/etc/firejail/kodi.profile kodi

From the file manager in Kodi I can browse all directories, drives (not just those defined in the profile) and delete data from them (if Linux permissions allow it). Surely in some previous version this worked correctly.

My questions are:

• could someone confirm this?
• should I report this as a bug?
• should I report it as Bug report or Report a security vulnerability?

Thank you in advance for your feedback.

[rusty-snake]

Sounds like kodi uses portals. (= not a bug, a feature) edit: file-manager not file-chooser

First make sure the files are actual accessible (e.g. firejail --profile=kodi ls foo/bar). s.a.

Second note that kodi.profile isn't whitelisting profile and does not set disable-mnt. So if you can access /mnt/foo/bar or ~/Downloads/frogs.png this is expected.

Report a security vulnerability?

Would be a bit late 😉

[kmk3]

Continued on:

• kodi: can access non-media paths #5179