svn commit: r358153 - head/usr.sbin/services_mkdb

Pedro Giffuni pfg at FreeBSD.org
Sat Feb 22 18:50:06 UTC 2020


On 22/02/2020 11:18, Florian Smeets wrote:
> On 20.02.20 04:54, Pedro F. Giffuni wrote:
>> Author: pfg
>> Date: Thu Feb 20 03:54:07 2020
>> New Revision: 358153
>> URL: https://svnweb.freebsd.org/changeset/base/358153
>>
>> Log:
>>    /etc/services: attempt bring the database to this century.
>>    
>> -smtps		465/tcp	   #smtp protocol over TLS/SSL (was ssmtp)
>> -smtps		465/udp	   #smtp protocol over TLS/SSL (was ssmtp)
> I'm not sure how removals of services have been handled in the past.
> This change broke loading of my pf rule set, as I had smtps in there.

Excellent!

Not that the change broke something but that since we had to revert it 
we get a second chance to review such things.


> I'm not saying that this change is wrong, but I think removing entries
> from services can break all kinds of stuff. Not just firewall rule sets,
> also scripts and thinking more about it, it will most certainly also
> break postfix as it also uses smtps as an alias for port 465 in its
> master.cnf

According to latest IANA registy:

urd                 465        tcp    URL Rendezvous Directory for 
[Toerless_Eckert] [Toerless_Eckert]
                                       SSM
submissions         465        tcp    Message Submission over TLS [IESG] 
[IETF_Chair] 2017-12-12                [RFC8314]
                                       protocol
igmpv3lite          465        udp    IGMP over UDP for SSM 
[Toerless_Eckert] [Toerless_Eckert]

Anything that can be done upstream to sort this out?

> I guess this needs to be at least mentioned in the release notes, and
> maybe smtps kept as an alias, and check all the others that were removed?

For the time being, we can absolutely keep the legacy value with a 
conflict note. I wish the services list were a bit easier to maintain 
for such situations.

Pedro.



More information about the svn-src-all mailing list