GECOS Field [LWN.net]

GECOS Field

Posted Apr 1, 2026 22:52 UTC (Wed) by anselm (subscriber, #2796)
In reply to: GECOS Field by linuxrocks123
Parent article: Objections to systemd age-attestation changes go overboard

So, why not just add a new comma field at the end of the GECOS data? Wouldn't software that doesn't know about it ignore it?

Software that doesn't know about it will probably get confused if it assumes the GECOS field contains exactly the common four subfields, or it will simply attach the value of the extra date-of-birth subfield to the value of the preceding subfield (the user's home phone number in the traditional interpretation). The basic problem with the GECOS field is that its handling is specified too loosely already to be really useful, and adding extra confusion into the mix by introducing more gratuitous subfields does not help anyone.

If you add the date of birth to the systemd user database instead, at least you won't break an indeterminate number of other programs which have been around for a very long time and which nobody is keen on having to update anymore.

to post comments

GECOS Field

Posted Apr 2, 2026 4:23 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (4 responses)

I don't think that's true. Wikipedia states that standard GECOS treats the fifth field as "Other" and gives an email address as an example of something you could put there:

https://en.wikipedia.org/wiki/Gecos_field

Specify that the fifth field means "date of birth" if and only if it starts with "DB-" or something, and you should be good, right?

GECOS Field

Posted Apr 2, 2026 6:52 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> and you should be good, right?

No, not right. That is a hack, and this hack will fail if some other software uses the GECOS "other" field for any other purposes, or makes wrong assumptions about its content.

The point of systemd as a project is to remove hacks and replace them with clean engineering, not add to them.

GECOS Field

Posted Apr 2, 2026 7:45 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

standard GECOS treats the fifth field as "Other" and gives an email address as an example of something you could put there

So? BSD only documents four fields and doesn't mention “Other”. The Linux manpage for the /etc/passwd doesn't specify the interpretation of the GECOS field at all. Wikipedia, of course, has no normative effect on anything. All of this only serves to point out the confusion that already exists around the GECOS field.

You can of course define your own meaning for the “Other” field (if we assume it even exists), but that will break all existing programs that expect it to be, e.g., an e-mail address, or that expect there to be only four fields altogether. Even adding a prefix like “DB-” won't help because to an existing program which expects the “Other” field to be an e-mail address, something like DB-1900-01-01 will just look like either a funny e-mail address or a syntax error. And what do you do if the “Other” field is already occupied by, say, an e-mail address? Add a sixth field?

On the contrary, adding the date of birth to the systemd user database does not jeopardise existing software, puts the information into a well-defined place, and does not prejudice further extensions. It is a reasonable engineering approach while extending the GECOS field in a potentially-incompatible way would be just a brittle hack.

GECOS Field

Posted Apr 5, 2026 17:51 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

I highly doubt there are enough programs using fields 4 _OR_ 5 of the GECOS field for that to be a problem.

I don't think we want good engineering. I think we want the crappiest possible solution we can get away with. If a non-California-distributed operating system uses Field 5 of GECOS for something else, meaning spyware can't reliably count on the birthday being there -- good.

GECOS Field

Posted Apr 7, 2026 9:07 UTC (Tue) by taladar (subscriber, #68407) [Link]

If you build anything with shitty engineering all that will happen is that your solution is ignored in favor of one built by someone with slightly better engineering. If you refuse to build a good solution you lose any influence your technical skill might have given you over the outcome.