Thank you for reporting the bug! Unfortunately we do not have a plugin checking for valid (base) names at the moment.

What about adding check/validation/match = BASENAME support in the validation plugin. Then we could specify a regex in src/plugins/hosts/contract.h which checks for valid hostnames (and aliases).

Do you know which hostnames and aliases are allowed?

This would also fix the problem with newlines in hostnames + aliases, see #1719 (but not the problem of newlines in comments...)

Do you know which hostnames and aliases are allowed?

i couldn't find any specification for /etc/hosts.

RFC952 states

A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names".

the grammar doesn't have that limitation though.

according to RFC1034 a FQDN is 254 characters max (including root). and a hostname is 63 characters max (which seems to be the more common than the 24 character limit)

what all have in common is that they can't end in a hypen, should start with either an alphanumeric character of a numeric character (depending on which documentation you read) and end with an alphanumeric character.

i'd go with the FQDN definition, and imho a simple check if the basename qualifies at a valid FQDN should be done in the hosts plugin (it's just 4 strchr calls + distance check to the previous one)

what do you think ?

Sounds good! If you can give it a quick check with what glibc/musl does, it is even better.

musl does the bare minimum

if (strnlen(host, 255)-1 >= 254 || mbstowcs(0, host, 0) == -1) return 0;
for (s=(void *)host; *s>=0x80 || *s=='.' || *s=='-' || isalnum(*s); s++);

not sure what glibc does, too just too much to read, did a few greps, but couldn't find any validation of the hostname in /etc/hosts

i'd go with musl's check but add maybe isalpha(host[0]) && isalnum(host[strlen(host)-1]) like the RFC1034 grammar states with a "strict" config option ?

i'd go with musl's check

Sounds good!

grammar states with a "strict" config option

Only if somebody needs both options. Otherwise simply implement one.

@tom-wa actually we already have a kind-of "strict" option: the --with-recommends option. So everything directly implemented in hosts is "non-strict", what you implement as regex in the contract (which is only applied when --with-recommends is used) is "strict".

@tom-wa any update here?

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖