mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3618] Must-fix bugs for release 0.9.64 #2274
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2274
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@rusty-snake commented on GitHub (Sep 1, 2020):
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 commented on GitHub (Sep 1, 2020):
@rusty-snake - can you to edit directly in the first post?
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 commented on GitHub (Sep 1, 2020):
It might be good if options like
ls,tree,topand 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 coreutilslsand procpsps,topand so on are already doing the same.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 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
@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.
@reinerh commented on GitHub (Oct 5, 2020):
0.9.64-rc1 is now available in Debian/experimental, if someone wants to test it.
@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:
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 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.
@reinerh commented on GitHub (Oct 6, 2020):
Build failure should be addressed in
1329aff.I'll attempt another upload.
@rusty-snake commented on GitHub (Oct 22, 2020):
To migrate your custom additions in ~/.config/firejail, you can use this script.