WhyNotHugo

WhyNotHugo

π = 3

Member Since 10 years ago

Amsterdam, The Netherlands

Experience Points
124
follower
Lessons Completed
12
follow
Lessons Completed
553
stars
Best Reply Awards
81
repos

1857 contributions in the last year

Pinned
⚡ ✅ A simple, standards-based, cli todo (aka: task) manager.
⚡ 📇 Synchronize calendars and contacts.
⚡ ㊙️ Create standard barcodes with Python. No external dependencies. 100% Organic Python.
⚡ ⚖️ AFIP invoice integration for django.
⚡ 📄 A Django app to render django templates as PDF files.
⚡ Universal payment handling for Django.
Activity
Dec
4
2 days ago
Activity icon
issue

WhyNotHugo issue comment rust-windowing/winit

WhyNotHugo
WhyNotHugo

Add DroppedFile support for Wayland

The DroppedFile event should be supported on Wayland through the data device, but afaik at this point the feature isn't implemented on Wayland yet.

I suppose the HoveredFile and HoveredFileCancelled could also be implemented, but I'm mainly concerned with the DroppedFile event.

WhyNotHugo
WhyNotHugo

so winit should also support clipboard to have drag and drop implemented

Not really. They re-use the same objects because copy-pasting and drag-dropping share a lot of the same concepts, but you can implement the latter without the former.

Dec
3
3 days ago
Activity icon
issue

WhyNotHugo issue comment pimutils/vdirsyncer

WhyNotHugo
WhyNotHugo

Future of vdirsyncer

I've been thinking about the general direction of vdirsyncer for a few weeks now (or is it actually months already?).

Python has proven to be a bad choice for maintaining this project long term. Debian has such an old version it's hard to write modern Python that works on it. Meanwhile, other distros keep up to date with upstream's latest. Improvements on Python are hard to pick up (I can basically use python 3.10 improvements in a few years, when it's the oldest version we support, so, not anytime soon).

Plus, each time a library is added, it produces a burden on distribution packager on packaging yet another library.

I'm very tempted to port vdirsyncer to golang. Rust is nice and all, but it's a far too high bar for contributions, and its ecosystem isn't very mature when it comes to webdav/icalendar/vcard/etc. Golang has good libraries, is very very fast, and is very easy to ship. It's high-level enough that writing it and maintaining it won't be a nightmare too.

I'd still encourage distributions to package it, but for those that don't, access is easier. Testing also becomes a lot simpler, and it's a good opportunity to re-think things. I'd personally like something that can be triggered when a collection is altered, and run at that point (probably with a small delay, the finer details are to be seen).

That would result in very fast push of changes. Pulling could be done on a schedule via cron(8) or a systemd.timer(5).

Go libraries in the ecosystem exist, and many of them are being actively maintained, so I think this is a better opportunity for mutual collaboration.

I'll probably only maintain the Python version until that new project has a working release -- I rely on vdirsyncer myself, so always need a working version.

WhyNotHugo
WhyNotHugo

Currently not much going on on this front. golang currently has some limitations to the its timezone library which is blocking parsing timezones from icalendars correctly.

See https://github.com/emersion/go-ical/issues/10.

Activity icon
issue

WhyNotHugo issue comment emersion/go-ical

WhyNotHugo
WhyNotHugo

Reading in-file timezones

I've a lot of events that look like this:

BEGIN:VCALENDAR
PRODID:-//Radicale//NONSGML Radicale Server//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:local
X-RADICALE-NAME:local
BEGIN:STANDARD
DTSTART:20090314T230000
TZNAME:ART
TZOFFSETFROM:-0200
TZOFFSETTO:-0300
X-RADICALE-NAME:local
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Redacted summary
DTSTART;TZID="local;VALUE=DATE-TIME":20150315T123000
DTEND;TZID="local;VALUE=DATE-TIME":20150315T193000
DTSTAMP:20150315T103349Z
UID:762CJK7VMGEBP416C5TE3V6KFHVJXY2Y6IPD
SEQUENCE:0
X-RADICALE-NAME:762CJK7VMGEBP416C5TE3V6KFHVJXY2Y6IPD.ics
END:VEVENT
END:VCALENDAR

This doesn't seem to be invalid; the timezone is specific in the file. However, parsing these returns error unknown time zone local.

WhyNotHugo
WhyNotHugo

I've proposed adding a new public constructor for Location upstream (since the same issue is blocking other related projects too): https://github.com/golang/go/issues/49951

Activity icon
issue

WhyNotHugo issue comment golang/go

WhyNotHugo
WhyNotHugo

time: add a public function to generate a `time.Location` struct

What version of Go are you using (go version)?

$ go version
go version go1.17.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/hugo/.cache/go-build"
GOENV="/home/hugo/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/hugo/.cache/golang/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/hugo/.cache/golang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1388033309=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to create an instance of time.Location based on data read from an iCalendar file.

What did you expect to see?

Some way to construct a time.Location instance.

What did you see instead?

No public function to create such an instance; time.Location instances can only be created with time.LoadLocationFromTZData.

More background

We're trying to parse iCalendar files, which contain VTIMEZONE entries, which represent a timezone (time.Location in go).

However, there's no public function to create time.Location instances, and the only way to create them is using using IANA Time Zone database-formatted data, which is a rather complex binary format.

So currently, the only way to create time.Location entries for the timezones read, is to convert them into the above mentioned binary format, and then feed that into time.LoadLocationFromTZData.

This has two big problems: (1) it's very complex to convert VTIMEZONE data into that binary format, and also, needless complexity (2) it's very inefficient, since every entry read has to be converted into an intermediate representation, to then be parsed again and then converted into the final one.

Making the time.zone and time.zoneTrans public (e.g.: renaming them into time.Zone and time.ZoneTrans, plus adding a time.LocationFromZoneInfo(name string, zones []Zone, zoneTrans []ZoneTrans) Location function would very much help address this issue.

I'd be happy to try and tackle the implementation myself, if the approach seems sound, but I figure it's best to ask for feedback on that first; it's possible that someone has cleaner approaches to solving this issue, or that this breaks some existing convention.

As an alternative approach, a function that takes a string with an RFC-5545 compliant VTIMEZONE and returns a time.Location instance might be a cleaner API, but I'm not sure if adding iCalendar-specific code into this package would be deemed acceptable.

WhyNotHugo
WhyNotHugo

The Zone and ZoneTrans structs are currently private, and making them public seems like the easiest way to create a public constructor for Location:

Rename the current zone to Zone. Rename the current zoneTrans to ZoneTrans.

With both structs being publicly usable, add a new method to create a Location instance:

func NewLocationFromZoneData(name string, zones []Zone, zoneTrans []ZoneTrans) Location...

I tried thinking of alternative APIs without using zone and zoneTrans, but they all end up basically re-implementing those two structs, since they represent the minimal amount of data required to create a Location instance.

open pull request

WhyNotHugo wants to merge netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

WhyNotHugo
WhyNotHugo
pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

Activity icon
issue

WhyNotHugo issue comment netblue30/firejail

WhyNotHugo
WhyNotHugo

`noprinters`

Describe the solution you'd like

noprinters command to disable printing. It should blacklist /dev/lp* stuff and /run/cups/cups.sock.

This idea is based on the observation that wrc has

  • /run/**/resolv.conf which is either needed or useless because of net none
  • /run/dbus/system_bus_socket which is further handled by dbus-system
  • /run/media which is further handled by disable-mnt/disable-write-mnt.inc
  • /run/cups/cups.sock which is not handled elsewhere.
WhyNotHugo
WhyNotHugo

How about disabling printers by default and having a printers command to enable them when desired?

It's a bit easier to think about permissions in terms of "profile doesn't allow anything, unless otherwise stated", rather than the other way around.

push

WhyNotHugo push WhyNotHugo/firejail

WhyNotHugo
WhyNotHugo

Implement a whitelist-ro command

This is a shortcut to:

whitelist $PATH read-only $PATH

Ideally, a great deal of usages of whitelist should be replaced with this instead.

commit sha: 894bf81a595304b0c1a843c85a607003fd419d1b

push time in 2 days ago
Activity icon
issue

WhyNotHugo issue comment netblue30/firejail

WhyNotHugo
WhyNotHugo

Implement a `whitelist-ro` command

This is a shortcut to:

whitelist $PATH
read-only $PATH

Ideally, a great deal of usages of whitelist should be replaced with this instead.

WhyNotHugo
WhyNotHugo

I'm a bit hesitant on whether a whitelist-rw makes sense, and then discourage using whitelist.

Specifying whether it should be read-only or read-write explicitly could reduce surprises and avoid unintentionally granting write access when trying to just grant read access.

pull request

WhyNotHugo pull request netblue30/firejail

WhyNotHugo
WhyNotHugo

Implement a `whitelist-ro` command

This is a shortcut to:

whitelist $PATH
read-only $PATH

Ideally, a great deal of usages of whitelist should be replaced with this instead.

open pull request

WhyNotHugo wants to merge netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

Activity icon
created branch

WhyNotHugo in WhyNotHugo/firejail create branch whitelist-ro

createdAt 2 days ago
Activity icon
issue

WhyNotHugo issue comment netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

WhyNotHugo
WhyNotHugo

I think all comments have been addressed, but lemme know if I've missed anything.

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

open pull request

WhyNotHugo wants to merge netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

WhyNotHugo
WhyNotHugo

The thing that doesn't fully convince me about the whitelist mechanic, is that by default, all access to /run is allowed, so we use include whitelist-run-common.inc, but that still grants access to various unnecessary items (including printing!?) which this application doesn't need.

Ideally, /run should be entirely hidden here.

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

open pull request

WhyNotHugo wants to merge netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

WhyNotHugo
WhyNotHugo

True, it'd be a mess in terms of compat and breaking people's overrides too.

I think whitelist-ro makes sense too. My train of though is mostly that, if I want to grant just read-only access to a directory right now, I need to whitelist, which grants write access and then remove the write access, which just sounds... not right. I'll experiment a bit with that and see if I can produce a viable PR.

Activity icon
issue

WhyNotHugo issue comment golang/go

WhyNotHugo
WhyNotHugo

time: Add a public function to generate a `time.Location` struct

What version of Go are you using (go version)?

$ go version
go version go1.17.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/hugo/.cache/go-build"
GOENV="/home/hugo/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/hugo/.cache/golang/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/hugo/.cache/golang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1388033309=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to create an instance of time.Location based on data read from an iCalendar file.

What did you expect to see?

Some way to construct a time.Location instance.

What did you see instead?

No public function to create such an instance; time.Location instances can only be created with time.LoadLocationFromTZData.

More background

We're trying to parse iCalendar files, which contain VTIMEZONE entries, which represent a timezone (time.Location in go).

However, there's no public function to create time.Location instances, and the only way to create them is using using IANA Time Zone database-formatted data, which is a rather complex binary format.

So currently, the only way to create time.Location entries for the timezones read, is to convert them into the above mentioned binary format, and then feed that into time.LoadLocationFromTZData.

This has two big problems: (1) it's very complex to convert VTIMEZONE data into that binary format, and also, needless complexity (2) it's very inefficient, since every entry read has to be converted into an intermediate representation, to then be parsed again and then converted into the final one.

Making the time.zone and time.zoneTrans public (e.g.: renaming them into time.Zone and time.ZoneTrans, plus adding a time.LocationFromZoneInfo(name string, zones []Zone, zoneTrans []ZoneTrans) Location function would very much help address this issue.

I'd be happy to try and tackle the implementation myself, if the approach seems sound, but I figure it's best to ask for feedback on that first; it's possible that someone has cleaner approaches to solving this issue, or that this breaks some existing convention.

As an alternative approach, a function that takes a string with an RFC-5545 compliant VTIMEZONE and returns a time.Location instance might be a cleaner API, but I'm not sure if adding iCalendar-specific code into this package would be deemed acceptable.

WhyNotHugo
WhyNotHugo

Can't you load the Location from VTIMEZONE.TZID? loc,err := time.LoadLocation(VTIMEZONE.TZID)

Regrettably, it's not that simple. This works for components created by some applications, but not all. Looking at my personal calendar, about 30% fail to parse when using this assumption. Some just have a TZID of local, other have the city name in another format, and a few are simply GMT-0300.

Some of the ones that say local include DST transitions too, so they retained the entire local TZ data, without serialising the name.

Aside from the anecdotal data, it's not safe to assume the TZID will match the timezone identifier; from RF5545:

    Note: This document does not define a naming convention for
    time zone identifiers.  Implementers may want to use the naming
    conventions defined in existing time zone specifications such
    as the public-domain TZ database [TZDB].  The specification of
    globally unique time zone identifiers is not addressed by this
    document and is left for future study.

FWIW, this approach you're suggesting is the one we initially took, and that's how we discovered this problem, apologies for not mentioning it initially.

if your system does not contain a timezone database you could use the loc := time.FixedZone("locationName", secondsEastOfUTC)

This won't yield the right results for repeating events (e.g.: a repeating event that repeats every day at 10:00, for a timezone with some DST).

It's also a bit problematic in that de-serialising the data, and the serialising it again would result in some data loss, and if the date for the iCalendar component is changed the timezone needs to be re-read since it's DST data has been lost.

push

WhyNotHugo push WhyNotHugo/firejail

WhyNotHugo
WhyNotHugo

configure.ac: Ensure whitespace after each comma

For increased consistency and readability.

This restores the spaces removed on commit bf81cd6ad ("configure.ac: run autoupdate to fix autoconf warning") / PR #4316.

Command used to check for the lack of whitespace:

grep ',[^ ]' configure.ac
WhyNotHugo
WhyNotHugo

configure*: Trim trailing spaces on var assignments

Command used to find them:

grep ' "$' configure.ac
WhyNotHugo
WhyNotHugo

configure*: Fix wrong quote character in AC_MSG_ERROR

Square brackets are used as quotes in autoconf.

From Section 8.1.1, Active Characters of the Autoconf manual[1]:

To fully understand where proper quotation is important, you first need to know what the special characters are in Autoconf: ‘#4 tries to match by pairs), and finally ‘$’ inside a macro definition.

[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Active-Characters

WhyNotHugo
WhyNotHugo

configure*: Add missing quotes to arguments

For increased safety and consistency. In addition, this should make it clearer where each argument starts and ends.

See also the following item from autoconf NEWS[1]:

  • Noteworthy changes in release 2.70 (2020-12-08) [stable]

[...]

*** Many macros have become pickier about argument quotation.

If you get a shell syntax error from your generated configure script, or seemingly impossible misbehavior (e.g. entire blocks of the configure script not getting executed), check first that all macro arguments are properly quoted. The “M4 Quotation” section of the manual explains how to quote macro arguments properly.

It is unfortunately not possible for autoupdate to correct quotation errors.

[1] https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=NEWS;h=ba418d1af5da752de77a2c388f9af56f8f1bf6a4;hb=97fbc5c184acc6fa591ad094eae86917f03459fa

WhyNotHugo
WhyNotHugo

configure*: Move AC_SUBST calls to more obvious places

These macros should always be called regardless of the intended value of each variable, as even if e.g.: no --enable-apparmor flag is given, the configure script still has to substitute @[email protected] with blank in the relevant files.

Something similar is already being done for HAVE_OVERLAYFS since commit fb9f2a5fb ("disabled overlayfs, fixes pending; added video channels to README* files", 2021-02-06).

Note that each AC_SUBST is not immediately converted into search/replace code when generating the configure script. It appears that the variables are handled only after parsing all of configure.ac (or until a specific command is found), as all arguments passed to every AC_SUBST call are defined at once on the ac_subst_vars list. The actual substitutions are also done all at once (while iterating through the list) and that happens much later in the script (see both occurrences of ac_subs_vars on the current script).

WhyNotHugo
WhyNotHugo

configure*: Remove redundant AC_SUBST calls near HAVE_LTS

Added on commit d1acb31c9 ("compile time: enable LTS", 2021-02-28).

It only needs to be called once for each variable. See the configure script diff and the previous commit ("configure*: Move AC_SUBST calls to more obvious places").

WhyNotHugo
WhyNotHugo

build: Normalize HAVE_SUID

See commit 15d793838 ("Try to fix #2310 -- Can't create run directory without suid-root", 2021-05-13) / PR #4273.

It is the only "HAVE_" option whose value is set by if/else on a makefile. Also, it is set in different places to either "yes", "no", blank or "-DHAVE_SUID". Set the value only on configure.ac and only to either blank or to "-DHAVE_SUID".

Misc: The ifeq ($(HAVE_SUID),-DHAVE_SUID) comparison that this adds is based on the existing ifeq ($(HAVE_APPARMOR),-DHAVE_APPARMOR) comparison on Makefile.in.

WhyNotHugo
WhyNotHugo

build: Normalize HAVE_CONTRIB_INSTALL

Added on commit 8d8686af2 ("Make installation of contrib scripts configurable", 2017-04-13).

Remove redundant argument to AS_IF and make it look more like the other nearby AS_IF calls.

WhyNotHugo
WhyNotHugo

disable shell tab completion for --whitelist and --private commands

WhyNotHugo
WhyNotHugo

fix: allow tilde (home directory) in --netfilter file name

WhyNotHugo
WhyNotHugo

Keep audio and video groups regardless of nogroups

Currently, on systems that use seat managers that do not implement seat-based ACLs (such as seatd), sound is broken whenever nogroups is used. This happens because without ACLs, access to the audio devices in /dev is controlled by the standard group permissions and the "audio" group is always dropped when nogroups is used. This patch makes the "audio" and "video" groups be dropped if and only if noaudio and novideo are in effect, respectively (and independently of nogroups). See #4603 and the linked issues/discussions for details.

Note: This is a continuation of commit ea564eb74 ("Consider nosound and novideo when keeping groups") / PR #4632.

Relates to #2042 and #4531.

WhyNotHugo
WhyNotHugo

Keep render, lp, input and other groups regardless of nogroups

Mappings of command -> group that this commit adds:

  • no3d -> render
  • noprinters -> lp
  • nodvd -> cdrom (Debian[1] and Gentoo[2]), optical (Arch[3])
  • noinput -> input

Mappings that were considered but that are not added:

  • notv -> ? (unknown group)
  • nou2f -> ? (devices are apparently owned by root; see #4603)

Based on @rusty-snake's suggestion: https://github.com/netblue30/firejail/issues/4603#issuecomment-944046299

See the previous commit ("Keep audio and video groups regardless of nogroups") for details.

Relates to #2042 and #4632.

[1] https://wiki.debian.org/SystemGroups [2] https://api.gentoo.org/uid-gid.txt [3] https://wiki.archlinux.org/title/Users_and_groups

WhyNotHugo
WhyNotHugo

Make nogroups work on nvidia again

Remove workaround from commit 623e68216 ("temporary fix for nvidia/nogroups/noroot issue (#3644, #841)", 2020-10-02) and from commit cb460c32c ("more nvidia (#3644)", 2020-10-03).

The handling of the "render" and "video" groups is separate from nogroups now, so disabling nogroups on nvidia shouldn't be necessary anymore. See the previous 2 commits for details.

See also the discussion on PR #4632.

WhyNotHugo
WhyNotHugo

etc: Remove comments about nogroups and noroot on nvidia

nogroups should not have been causing issues with rendering on nvidia since commit 623e68216 ("temporary fix for nvidia/nogroups/noroot issue (#3644, #841)", 2020-10-02) and commit cb460c32c ("more nvidia (#3644)", 2020-10-03), which had made it a no-op on nvidia. And the handling of the "render" and "video" groups are independent to the handling of nogroups now; see the previous 3 commits.

Commits which introduced the comments on each profile:

  • kodi.profile: commit ce462b6b1 ("fix #3501", 2020-07-16)
  • mpsyt.profile: commit e17b48fca ("new profile mpsyt.profile", 2018-11-28)
  • mpv.profile: commit cc7c48983 ("Document #1945", 2018-07-25)
  • steam.profile: commit d6f8169dd ("steam fixes; #841, #3267", 2020-03-15)

Commands used to find the comments:

git grep -i nvidia -- etc/profile-* | grep -v private-etc

Relates to #4632.

WhyNotHugo
WhyNotHugo

Merge pull request #4712 from kmk3/configure-improvements2

Configure improvements2

WhyNotHugo
WhyNotHugo

Blacklist ~/.config/monero-project

WhyNotHugo
WhyNotHugo

install profstats in /etc/firejail directory - undocumented, used only for development

WhyNotHugo
WhyNotHugo

Merge pull request #4726 from tredondo/patch-9

Add blacklist to disable-programs

commit sha: 08d0c495c63767dea0c784ad551e958df87b1145

push time in 2 days ago
open pull request

WhyNotHugo wants to merge netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

WhyNotHugo
WhyNotHugo

Somewhat out-of-scope: what do you think about whitelisted locations being read-only by default, and requiring that read-write be set explicitly?

Currently, a lot of locations are whitelisted, and all those are made read-write implicitly, which really increases the scope of how much access each sandbox has (and how much impact they can have messing around).

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

pull request

WhyNotHugo merge to netblue30/firejail

WhyNotHugo
WhyNotHugo

Add a profile for Flatseal

Flatseal is a GUI tool to configure permissions for Flatpak applications.

This restricts permissions as much as possible without affecting functionality.

Previous