Update /etc/services: attempt to bring it to the new century

[pfg]

Summary

The previous update has been split in two, to account for the build systems' inability to use a larger PROTOMAX value from that used in the base utilities. THis update will have to wait until releases catch up with the PROTOMAX update.

Test Plan

CI builds

[mjg]

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

Ubuntu 18.04 has the file only at 591 lines, which means FreeBSD is already pushing it with 2496 lines. So imo if anything we should be looking at trimming the list to be closer size-wise to what they ship in Linux.

[pfg]

Hello;

In D23621#518513, @mjg wrote:

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

I do agree there is some crap that we don't care about: things like flex-lm licensing or some services that I suspect have died and were never de-registered at IANA. Some other things like vnc-server I happen to have used a lot and I was surprised we never carried.

Ubuntu 18.04 has the file only at 591 lines, which means FreeBSD is already pushing it with 2496 lines. So imo if anything we should be looking at trimming the list to be closer size-wise to what they ship in Linux.

Well, the list that NetBSD carries, and was partially used as reference, is 21838 lines. What is the use of a database if it has to be short ? ;).

[mjg]

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:

https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com

Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

I'm afraid NetBSD doing something is not an argument.

[cy]

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

[pfg]

In D23621#518528, @mjg wrote:

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:

https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com

Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

This is different, plus the change of size in the services file is an order of magnitude smaller. Comparing to linux is not always a good idea either.

I just looked at the services in ubuntu/debian and they haven't updated in a while. They use as a reference the FreeBSD file when we were using CVS.

Another linux source for the /etc/service file is here:
http://sethwklein.net/iana-etc (which is what NetBSD follows)

I'm afraid NetBSD doing something is not an argument.

The above change is not an argument either not updating things either.

Let me do some revision here to drastically reduce the size. I basically do agree that we shouldn't add crap anywhere for the matter of change, but it shouldn't be that we have to hunt for services table when you have one in the system.

[pfg]

In D23621#518545, @cy wrote:

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

I did check the IANA ports number database :). The Kerberos IV numbers I removed are not registered in IANA any more.

Kerberos IV was not only EOL'd in Oct 2006:
https://web.mit.edu/kerberos/krb4-end-of-life.html

It's use is a security risk.

[cy]

If they've been removed from IANA's list, then that's OK. To be absolutely correct, using KRB4 is a security risk, however allowing them to stay in services(5) is not a risk. It's KRB4 that is the risk. I'll accept this revision as long as the commit message *accurately* reflects that we are truing up our services(5) with IANA, not the documentation of a port is itself a security risk, which it is not. Just so we are clear about how this is documented in the commit message.

[pfg]

Update Take2:
It is important to consider the differences between System Ports and User
ports. This changes keeps the system ports closely in sync with IANA.

For the users ports we can keep only those that are vaulable, ignoring a huge
amount of transitory services used by commercial applications to register.
I looked at the OpenBSD list which is reasonably sized as a further reference.

[pfg]

Sync with latest updates.

[pfg]

Update User Ports, attempting to bring balance with what can actually appear in a UNIX system.

[pfg]

I plan to re-commit this as soon as FreeBSD 12.2 is released, to avoid a limitation of the build system.

[pfg]

Merge latest current

[cy]

usr.sbin/services_mkdb/services

2155

eklogin and ekshell are still a thing. Look at Solaris 11 and RHEL 8. These need to stay.

2281

Kerberos IV is a thing of the past. And, Kerberos V no longer supports krb524.

[pfg]

Thanks, will update soon.

usr.sbin/services_mkdb/services

2155

According to IANA, those are assigned to something else:
mzap 2106 tcp MZAP [Dave_Thaler_2]
mzap 2106 udp MZAP [Dave_Thaler_2]

2281

This is assigned though.

[pfg]

Update with cy's feedback.
This will be committed about a week after 12.2 is released.

[cy]

usr.sbin/services_mkdb/services

2155

There are a lot of inconsistencies, still. Fortunately we developers are not the arbiters of discrepancies. The best we can do is document them.

2281

Then keep it.

[pfg]

Re-state krb524

[pfg]

For the record: after discussing with Li-Wen Hsu, it has been suggested to wait until after the 12.1 EOL, and I am actually fine with that.