Publish "Listen Port Convention"

phabricator-migrator · February 19, 2024, 5:43pm

Information

ID: 659
PHID: PHID-TASK-zjn74i3qs7k65a5diku7
Author: dau
Status at Migration Time: open
Priority at Migration Time: Normal

Description

The [[ proposals/635-listen-port-convention.txt at master · Kicksecure/proposals · GitHub | Listen Port Convention proposal ]] is finished, received some feedback and seems ready to be published as an actual convention.

Should this be moved out of proposals/?
It should have an official place to be hosted (on GitHub and/or on Whonix’ docs/wiki)
Places I think it should be announced:
- News - Whonix Forum
- debian-devel

This is a follow-up ticket to T635

Comments

Patrick

2017-04-28 14:36:13 UTC

dau

2017-04-29 17:54:50 UTC

! In T659#13045, @Patrick wrote:
Should this be moved out of proposals/?

I am neutral. If you like, go for it.

(In comparison, RFC - they keep calling them RFCs.)

I have never done anything like this before, so I honestly do not know what the best choice is. I think it would be good to use an approach that already works for others too, like you mentioned RFCs. Or how Tor manages theirs (I think they have “specs” and “spec proposals”).

I am just unsure if in the future it will be useful to separate them to know what is stable/accepted/etc and what is not. Should we worry about that later?

Yes. Would you like to create a Whonix blog account?

I just suggested that should be done, so anyone could do it. I have never done that either but if you think it is a good idea, I will be happy to do so.

I don’t know. I guess we’re missing one ticket “wait for Debian stretch to become Debian stable and then suggest this convention to Debian”?

We are! Were we supposed to create a ticker on their tracker (or something like that) too?

Patrick

2017-04-29 21:55:13 UTC

dau (Felipe Dau):

dau added a comment.

In ⚓ T659 Publish "Listen Port Convention", @Patrick wrote:

Should this be moved out of proposals/?

I am neutral. If you like, go for it.

(In comparison, RFC - they keep calling them RFCs.)

I have never done anything like this before, so I honestly do not
know what the best choice is.

I doubt there is a best practices for that one.

I think it would be good to use an
approach that already works for others too, like you mentioned RFCs.
Or how Tor manages theirs (I think they have “specs” and “spec
proposals”).

Right. From that perspective, we should probably rename the repository
to specs with a sub folder proposals.

example:
115-two-hop-paths - Tor design proposals
Filename: 115-two-hop-paths.txt
Title: Two Hop Paths
Author: Mike Perry
Created:
Status: Dead
Supersedes: 112
Or we don’t use sub folders - then the file name would stay the same.
And just use a header to document the status and remaining to do.

I am just unsure if in the future it will be useful to separate them
to know what is stable/accepted/etc and what is not. Should we worry
about that later?

Let’s just take our best guess. There is a lot of freedom in these options.

Yes. Would you like to create a Whonix blog account?

I just suggested that should be done, so anyone could do it. I have
never done that either

Yes, you generally are on a very good track, so I have high confidence.

but if you think it is a good idea, I will be
happy to do so.

Definitely please go ahead.

I don’t know. I guess we’re missing one ticket “wait for Debian
stretch to become Debian stable and then suggest this convention to
Debian”?

We are! Were we supposed to create a ticker on their tracker (or
something like that) too?

Yes. It’s a bit strange. We now need a ticket here to remind to create a
ticket at their tracker since he said “it’s not the best time to discuss
this now at Debian”.

dau

2017-04-30 05:59:28 UTC

! In T659#13130, @Patrick wrote:
Right. From that perspective, we should probably rename the repository
to specs with a sub folder proposals.

example:
115-two-hop-paths - Tor design proposals
Filename: 115-two-hop-paths.txt
Title: Two Hop Paths
Author: Mike Perry
Created:
Status: Dead
Supersedes: 112
Or we don’t use sub folders - then the file name would stay the same.
And just use a header to document the status and remaining to do.

I am just unsure if in the future it will be useful to separate them
to know what is stable/accepted/etc and what is not. Should we worry
about that later?

Let’s just take our best guess. There is a lot of freedom in these options.
Great idea! The proposals kind of have a two-line header containing the links. What else should we add? Should we copy a few things from the format used in phabricator’s tickets too? Idea:

Ticket:

File:

Authors:

Assignees:

[Supersedes:]

[Priority:]

[Impact:]

Status:

[items] could be optional and I think “TODO” could be a separate section because it might have a long content.

What do you think?

(Should this be discussed in another ticket?)

Yes. Would you like to create a Whonix blog account?

I just suggested that should be done, so anyone could do it. I have
never done that either

Yes, you generally are on a very good track, so I have high confidence.

but if you think it is a good idea, I will be
happy to do so.

Definitely please go ahead.

Cool, thanks! Can you guide me on how to create the account?

I hope to compose a draft and post here within the week.

Yes. It’s a bit strange. We now need a ticket here to remind to create a
ticket at their tracker since he said “it’s not the best time to discuss
this now at Debian”.

Ahh, right. Should we coordinate the blog post and the Debian ticket? Post at the same time or maybe wait for feedback from the ticket and then make the announcement on Whonix’s blog and debian-devel?

Thanks!

Patrick

2017-04-30 10:20:57 UTC

dau (Felipe Dau):

Great idea! The proposals kind of have a two-line header containing the links. What else should we add? Should we copy a few things from the format used in phabricator’s tickets too? Idea:

Ticket:

File:

Authors:

Assignees:

[Supersedes:]

[Priority:]

[Impact:]

Status:

[items] could be optional and I think “TODO” could be a separate section because it might have a long content.

What do you think?

Perfect!

(Should this be discussed in another ticket?)

You can if there are additional questions, sure.

Yes. Would you like to create a Whonix blog account?

I just suggested that should be done, so anyone could do it. I have
never done that either

Yes, you generally are on a very good track, so I have high confidence.

but if you think it is a good idea, I will be
happy to do so.

Definitely please go ahead.

Cool, thanks! Can you guide me on how to create the account?

Oh, I forgot that the link is for some reason (bug) not obvious on our
wordpress installation. Sign up can be done here:

News - Whonix Forum

I hope to compose a draft and post here within the week.

Great!

Yes. It’s a bit strange. We now need a ticket here to remind to create a
ticket at their tracker since he said “it’s not the best time to discuss
this now at Debian”.

Ahh, right. Should we coordinate the blog post and the Debian ticket? Post at the same time or maybe wait for feedback from the ticket and then make the announcement on Whonix’s blog and debian-devel?

No, I don’t think progress should be blocked by Debian since I find the
request to wait to create the ticket quite strange. Tickets should help
to postpone and organize work in the future, but if we must wait for the
right time to create a ticket (and forget until then, then we need
another tracker and a ticket to make notes about when to create a ticket.

dau

2017-04-30 20:56:27 UTC

! In T659#13135, @Patrick wrote:
dau (Felipe Dau):
(Should this be discussed in another ticket?)

You can if there are additional questions, sure.

Alright, opened T668.

Oh, I forgot that the link is for some reason (bug) not obvious on our
wordpress installation. Sign up can be done here:

News - Whonix Forum

Ah, got it! Just created it

No, I don’t think progress should be blocked by Debian since I find the
request to wait to create the ticket quite strange. Tickets should help
to postpone and organize work in the future, but if we must wait for the
right time to create a ticket (and forget until then, then we need
another tracker and a ticket to make notes about when to create a ticket.

Sounds good. Opened T669 too.

Unrelated: Is it possible to reply to the email notifications to post replies here? Because the sender is noreply@phabricator.whonix.org.

Thanks!

Patrick

2017-05-01 00:47:44 UTC

dau

2017-05-01 17:14:51 UTC

I tried to reply, but here is what I got:

Your email to Phabricator was not processed, because an error occurred while
trying to handle it:

Your message does not contain any body text or attachments, so Phabricator can
not do anything useful with it. Make sure comment text appears at the top of
your message: quoted replies, inline text, and signatures are discarded and
ignored.

-- Original Message Body -----------------------------------------------------

On Mon, May 01, 2017 at 12:47:47AM +0000, Patrick (Patrick Schleizer) wrote:
> Just now added rights to your account so you can write and post. :)

Cool!

> Actually, reply by e-mail works. I use it quite often. Such as now.
> Indeed `noreply` is not great as sender. Although I every now and then
> check if my reply really reached the tracker. Everything below `-----`
> or so is eaten, because phabricator thinks that's a mail signature to be
> better cut off.

Oh, good to know. I am replying to this one. Let's see if it is
delivered.

Thanks :)

I think my comment is basically “quoted replies” and “inline text”. How exactly do I use this?

Patrick

2017-05-07 14:42:48 UTC

dau

2017-05-13 01:19:16 UTC

! In T659#13246, @Patrick wrote:
May I assign this to you?

Sure!

I modified the initial part of the proposal a bit for the blogpost, but should be the same idea.

Listen Port Convention

Server applications using Tor ephemeral onion services such as ricochet-im, onionshare, ZeroNet and unMessage usually listen on localhost only, as Tor usually runs on the same system and is able to map them. However, due to Whonix’s split design, Tor runs on the gateway and the application runs on the workstation, requiring the application to listen on the workstation’s external interface in order to allow the mapping from the gateway.

At the moment, it looks like there is no convention to configure where these applications listen by default (localhost vs. all interfaces) and deciding that seems to be up to the upstream author of the software as well as the packager. Then it’s up to the system administrator to decide on where the server application should listen, and currently there is not a great place for derivatives to globally modify this setting.

We believe that a solution to this problem is having a convention where listen config files for server applications are added to listen.d folders. Applications would then use a parser to read these configs in order to find, for example, which interface to listen on. This approach would prevent redundancy of application configs, support multiple systems, simplify applications development/packaging, as well as the system administration.

We would like to present the [[ proposals/635-listen-port-convention.txt at master · Kicksecure/proposals · GitHub | specification ]] of such a convention we have written, after incorporating feedback from users of [[ Debian Mailing Lists -- Index for debian-devel | debian-devel ]]. What do you think? Would you use it? Can it be improved? Lets us know your opinion.

Is it too long?

Is it okay to link to the file on GitHub? It was going to be hosted somewhere at whonix.org as well, right?

The “New Post” page has lots of options. Can you tell me which I should change and which I shouldn’t?

Let me know what you think.

Thanks! (And sorry for the delay )

Patrick

2017-05-16 15:00:11 UTC

dau

2017-05-16 18:53:48 UTC

Patrick

2017-05-16 19:10:28 UTC

dau

2017-05-16 19:40:17 UTC

Patrick

2017-05-16 20:49:46 UTC

dau

2017-05-16 23:56:13 UTC

Patrick

2017-05-17 12:25:05 UTC