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