[GH-ISSUE #3618] Must-fix bugs for release 0.9.64 #2274

Closed
opened 2026-05-05 08:57:58 -06:00 by gitea-mirror · 10 comments
Owner

Originally created by @netblue30 on GitHub (Sep 1, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3618

Start adding here bugs that need to be fixed before we release it. We have a lot of new functionality (SELinux, DBus, DHCP etc.), not to mention tones of new profiles. We'll go with a two weeks test release - maybe with not all the fixes in - followed by the real release. There will be at least another release before Debian goes in lockdown February next year. A new Firetools release will go in parallel - fixes to accommodate DBus handling are currently in.

The release will be the new base for LTS branch. The idea is to have both mainline and LTS from the same source code.

Milestone page: https://github.com/netblue30/firejail/milestone/1

Anything missing, put them directly in the milestone page.

Originally created by @netblue30 on GitHub (Sep 1, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3618 Start adding here bugs that need to be fixed before we release it. We have a lot of new functionality (SELinux, DBus, DHCP etc.), not to mention tones of new profiles. We'll go with a two weeks test release - maybe with not all the fixes in - followed by the real release. There will be at least another release before Debian goes in lockdown February next year. A new Firetools release will go in parallel - fixes to accommodate DBus handling are currently in. The release will be the new base for LTS branch. The idea is to have both mainline and LTS from the same source code. Milestone page: https://github.com/netblue30/firejail/milestone/1 Anything missing, put them directly in the milestone page.
Author
Owner

@rusty-snake commented on GitHub (Sep 1, 2020):

whitelist/blacklist replacement - #3447 - if not a full fix, at least we need to have an idea where we are going with it.

I would not go for such a big (maybe breaking) change short before a release. However, if we have a (mostly) finish draft what we change, we can add a "warning" it the relnotes.

As I said here, I'm fine with making this a breaking change + releasing it as a firejail 1.0 if we have a option/script which changes custom profiles.

<!-- gh-comment-id:684802039 --> @rusty-snake commented on GitHub (Sep 1, 2020): > whitelist/blacklist replacement - #3447 - if not a full fix, at least we need to have an idea where we are going with it. I would not go for such a big (maybe breaking) change short before a release. However, if we have a (mostly) finish draft what we change, we can add a "warning" it the relnotes. As I said [here](https://github.com/netblue30/firejail/issues/3447#issuecomment-683449719), I'm fine with making this a breaking change + releasing it as a firejail 1.0 if we have a option/script which changes custom profiles.
Author
Owner

@netblue30 commented on GitHub (Sep 1, 2020):

@rusty-snake - can you to edit directly in the first post?

As I said here, I'm fine with making this a breaking change + releasing it as a firejail 1.0 if we have a option/script which changes custom profiles.

That's an interesting idea! Most users are customizing the profiles, but we don't need to break anything. We can leave whitelist/blacklist in as aliases for some time in parallel with the new names.

<!-- gh-comment-id:684815245 --> @netblue30 commented on GitHub (Sep 1, 2020): @rusty-snake - can you to edit directly in the first post? > As I said here, I'm fine with making this a breaking change + releasing it as a firejail 1.0 if we have a option/script which changes custom profiles. That's an interesting idea! Most users are customizing the profiles, but we don't need to break anything. We can leave whitelist/blacklist in as aliases for some time in parallel with the new names.
Author
Owner

@smitsohu commented on GitHub (Sep 1, 2020):

  1. It might be good if options like ls, tree, top and so on could replace control characters, similar to what we already do in other places. Otherwise this opens up some opportunities for a rogue sandbox, for example it could use carriage return to hide what is really going on. The coreutils ls and procps ps, top and so on are already doing the same.

  2. Ideally sbox would not just close stdin if it cannot open the null device. In the beginning only Firejail code was run in an sbox and all was fine, but nowadays an increasing amount of code that is not controlled by the project is executed in these minimal sandboxes as well. If applications are not prepared to run with their stdin closed unexpected things can happen.

Not sure if these qualify as mustfix or should wait.

<!-- gh-comment-id:684901524 --> @smitsohu commented on GitHub (Sep 1, 2020): 1. It might be good if options like `ls`, `tree`, `top` and so on could replace control characters, similar to what we already do in other places. Otherwise this opens up some opportunities for a rogue sandbox, for example it could use carriage return to hide what is really going on. The coreutils `ls` and procps `ps`, `top` and so on are already doing the same. 2. Ideally sbox would not just close stdin if it cannot open the null device. In the beginning only Firejail code was run in an sbox and all was fine, but nowadays an increasing amount of code that is not controlled by the project is executed in these minimal sandboxes as well. If applications are not prepared to run with their stdin closed unexpected things can happen. Not sure if these qualify as _mustfix_ or should wait.
Author
Owner

@reinerh commented on GitHub (Sep 1, 2020):

I've created a milestone to track all issues mentioned in in this thread:
https://github.com/netblue30/firejail/milestone/1

<!-- gh-comment-id:685138065 --> @reinerh commented on GitHub (Sep 1, 2020): I've created a milestone to track all issues mentioned in in this thread: https://github.com/netblue30/firejail/milestone/1
Author
Owner

@reinerh commented on GitHub (Sep 2, 2020):

Btw. before releasing it, it would be nice to have a release candidate.
I could upload this to Debian/experimental to let it perform test builds on all architectures, and already run the test suite.

<!-- gh-comment-id:685852304 --> @reinerh commented on GitHub (Sep 2, 2020): Btw. before releasing it, it would be nice to have a release candidate. I could upload this to Debian/experimental to let it perform test builds on all architectures, and already run the test suite.
Author
Owner

@reinerh commented on GitHub (Oct 5, 2020):

0.9.64-rc1 is now available in Debian/experimental, if someone wants to test it.

<!-- gh-comment-id:703908677 --> @reinerh commented on GitHub (Oct 5, 2020): 0.9.64-rc1 is now available in Debian/experimental, if someone wants to test it.
Author
Owner

@reinerh commented on GitHub (Oct 5, 2020):

There are some "random" build errors related to manpage preprocessing.
There seems to be a race between this part in the main Makefile:

$(MANPAGES): $(wildcard src/man/*.man)

and the actual generation of the *.man files.

I'll have a look at it tomorrow, if no one beats me to it.

<!-- gh-comment-id:703934483 --> @reinerh commented on GitHub (Oct 5, 2020): There are some "random" [build errors](https://buildd.debian.org/status/package.php?p=firejail&suite=experimental) related to manpage preprocessing. There seems to be a race between this part in the main Makefile: ``` $(MANPAGES): $(wildcard src/man/*.man) ``` and the actual generation of the *.man files. I'll have a look at it tomorrow, if no one beats me to it.
Author
Owner

@rusty-snake commented on GitHub (Oct 6, 2020):

I saw they a few days ago on my new laptop, but never on my "old" laptop. Since my new laptop has more cores then my old one, it could be a race. The interesting thing is that manpages got installed always.

<!-- gh-comment-id:704184776 --> @rusty-snake commented on GitHub (Oct 6, 2020): I saw they a few days ago on my new laptop, but never on my "old" laptop. Since my new laptop has more cores then my old one, it could be a race. The interesting thing is that manpages got installed always.
Author
Owner

@reinerh commented on GitHub (Oct 6, 2020):

Build failure should be addressed in 1329aff.
I'll attempt another upload.

<!-- gh-comment-id:704452206 --> @reinerh commented on GitHub (Oct 6, 2020): Build failure should be addressed in 1329aff. I'll attempt another upload.
Author
Owner

@rusty-snake commented on GitHub (Oct 22, 2020):

To migrate your custom additions in ~/.config/firejail, you can use this script.

#!/bin/bash
sed -i -E \
        -e "/^nodbus$/c\\dbus-user none\ndbus-system none" \
        -e "/^ignore nodbus$/c\\ignore dbus-user\nignore dbus-system" \
        ~/.config/firejail/*
<!-- gh-comment-id:714423674 --> @rusty-snake commented on GitHub (Oct 22, 2020): To migrate your custom additions in ~/.config/firejail, you can use this script. ```bash #!/bin/bash sed -i -E \ -e "/^nodbus$/c\\dbus-user none\ndbus-system none" \ -e "/^ignore nodbus$/c\\ignore dbus-user\nignore dbus-system" \ ~/.config/firejail/* ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2274
No description provided.