[BlueOnyx:21240] Re: Blueonyx 5209R - no 1 letter email aliases possibe?

[Michael Stauber]

Hi Dirk,

> ok, but on 5106R it was possible and I have a customer who 
> is migrating from 5106R to 5209R in these days and he is
> complaining that 1-charcter email addresses are no longer
> possible.
> > If there are good reasons I will explain to him.

I just checked and it may indeed be an oversight and not intentional.

The input in "Email Aliases" is verified with the regular expression
TypeDef called "alphanum_plus_multiline". This checks input in
text-areas of the new GUI. In the old GUI we could use the simpler
"alphanum_plus" for that purpose.

The old GUI checked each line of the multi-line input from textareas
with its regular expression, whereas in the new GUI we need to check the
whole input start to finish with a slightly different regular expression.

The regexp for "alphanum_plus" would indeed allow a single character
email alias.

But the regexp for "alphanum_plus_multiline" demands at least two
characters and I don't see a good reason for why it does that.

I'll update baseType.schema to fix that regular expression and will
publish an update later on today.

However: We also (again) ought to make sure that a username does not
start with a number. There was a recent bug in Systemd which (again)
made me aware of this issue. In Unix/Linux the userspace tools are
responsible for making sure that a username does not start with a
number. This is a really ancient requirement, but certain OS's and
services have relaxed that over the years. So on some OS's it's now
possible to use usernames that start with numbers and on other it isn't.

The problem: Some services (and that included Systemd) expect not to
find usernames that start with a number and then bugger out when they
find one. Systemd for example had the bug that if you wanted to run a
service as unprivileged user and the name of that user started with a
number, then it would run the service as "root" instead, because it
failed to verify the username as valid. Which was pretty stupid and
Poettering even defended this brain-dead behavior and double screw-up
and blamed the userland tools for allowing such a username in first place.

Our problem: At one point or another we started to allow usernames with
leading number and this might not have been the best idea. I'm eager to
switch it back to what it was before, but am reluctant to do so because
it changes expected behavior. If someone currently has users with
leading numbers, they might then fail a future cmuImport.

-- 
With best regards

Michael Stauber