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.

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 ? ;).

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.

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.

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.

Thanks, will update soon.