Must-fix bugs for release 0.9.64

[netblue30]

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.

[rusty-snake]

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.

[netblue30]

@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.

[smitsohu]

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.

[reinerh]

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

[reinerh]

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.

[reinerh]

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

[reinerh]

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.

[rusty-snake]

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.

[reinerh]

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

[rusty-snake]

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/*