• https://github.com/netblue30/firejail/issues/3257
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822693
• https://www.whonix.org/pipermail/whonix-devel/2020-February/001519.html
• https://forums.whonix.org/t/stacked-wrappers/7944
• https://www.whonix.org/pipermail/whonix-devel/2019-August/001423.html
• https://www.whonix.org/pipermail/whonix-devel/2019-August/001424.html

In T324#18696, @Patrick wrote:

What is a good way to detect that users are using VM kernel in Qubes? @marmarek If uname -r outputs 4.19.43-1.pvops.qubes.x86_64 i.e. matches *pvops* it means that no VM kernel is being used?

needrestart works good enough for it to be implemented as a test in whonixcheck (--verbose?).

The public tahoeLAFS introducer is dormant:
https://tahoe-lafs.org/pipermail/tahoe-dev/2018-April/009913.html

*Most recet info on test grid can be found from their freenode IRC channel

Asked the devs some questions about integration:

Whonix project metadata could be distributed using Tahoe-LAFS - a redundant, encrypted storage array accessible over Tor. Instructions to users about alternative download mechanisms of the project's code and documentation can be passed thru this channel.

Looks great!

Sorry for taking a long time to open these:

Right. That's it. :)

• Find a place to "officially" publish the convention (has it moved from "proposal" to "convention"?)

In T635#12974, @Patrick wrote:

The original write draft for local listener standard on debian-devel seems done.

Could you please kindly close this ticket / create follow up ticket(s)?

The original write draft for local listener standard on debian-devel seems done.

In T635#12944, @Patrick wrote:

json is not trivially parsed in shell scripts. For shell scripts, something that can be simply evaluated would be nice. (Just echo listen_ip=xxx, so listen_ip=xxx gets set.)

Hmm, maybe I was not very clear on the explanation. I did not suggest changing the configs format (the .conf files). They should still look like something evaluable.

I did not interpret your suggestion as a change in the conf files.

What I suggested was the use of json to return the *parsed* configs to applications.

Yes, got that. That's why I wanted to point out, that json is hard to parse in shell scripts.

As a Python user (and as this would be a Python package) I would expect to get a dict with the configs to use on my application. For non-Python applications, that dict would be serialized to json because I believe that is one of the most popular formats these days with support from many languages. Also, we can offer multiple "serializers" if needed.

Yes, something that works for shell scripts would be nice.

Was that your concern?

Yes.

json is not trivially parsed in shell scripts. For shell scripts, something that can be simply evaluated would be nice. (Just echo listen_ip=xxx, so listen_ip=xxx gets set.)

Hmm, maybe I was not very clear on the explanation. I did not suggest changing the configs format (the .conf files). They should still look like something evaluable.

In T635#12941, @Patrick wrote:

Perhaps
check_filename -> is_config_file
find_files -> find_config_files
?

On the other hand... I personally prefer the very at the end and to have some consistency, i.e. config_read, config_check and so forth.

In T635#12915, @dau wrote:

P.S. I noticed the link in the description needs to be updated. Would you change to https://github.com/Whonix/proposals/blob/master/635-listen-port-convention.txt?

Perhaps
check_filename -> is_config_file
find_files -> find_config_files
?

I noticed the link in the description needs to be updated. Would you change to https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt?

This class is reasonably flexible so that people are able to customize how files are found and parsed. I pretty much just wrote the API, but here is what I have in mind:

I see. I will let you know how that goes.

Well, there is run-parts. Example:

In T635#12865, @Patrick wrote:

I have no idea if something like this exists. Might not as I don't know python applications doing this.

I have no idea if something like this exists. Might not as I don't know python applications doing this.

In T635#12847, @Patrick wrote:

I think [zzz] is a bonus. No need to wait for it or to let it block our progress here. We got some great suggestions for our initial draft which we then implemented. I think in this case it's fair to interpret the absence of criticism and praise as an okay signal to move forward. This is probably also how things work. Some people create some convention, then just do it. If it then proves to be useful and working, it might become an official Debian standard. Neither Debian nor freedesktop want to be the gatekeepers of innovation.

Holger Levsen:

https://lists.debian.org/debian-devel/2017/03/msg00348.html

In T635#12834, @Patrick wrote:

Sent.

Sent.

In T635#12825, @Patrick wrote:

Looks great!

Should I copy/paste and post it or would you like to do that?

Looks great!

In T635#12823, @Patrick wrote:

Right. Could you please add that text the Description part? I mean, the Description part is the part that gets actually copied over to the Debian mailing list in this case.

I'd suggest to add the link to the ticket and repo rather as a bonus. To be added somewhere at the end. We are mainly addressing the people on the mailing list. Beginning the text with two external links, I mean with...

• Ticket: https://phabricator.whonix.org/T635
• File: https://github.com/Whonix/proposals/blob/master/635-listen-port-convention.txt

might deter readers? Or am I over thinking this? I don't want to start painting the proverbial bikeshed.

Feedback on the ticket and pull requests on the repository are welcome.