A few relevant topics discussed here: https://stackoverflow.com/questions/3470669/should-unicode-be-allowed-in-usernames

I think there was some RH Bugzilla problem a while ago when someone changed their user name to have an emoji, and the problem was that XML-RPC could not handle that. I searched my email for details but I must've deleted it.

Anyway, this is probably something to test all the way through the stack to verify that XML-RPC can handle every character type that we choose to "support".

TEXT is very big for something like a package name. Maybe we could drop that down to VARCHAR(255) or something.

Probably some java package is going to exceed 255, but certainly there is some practical limit we could set. We probably want to stop a broken build process from having a 1MB package name ;)

@mikem for java: It probably would mean, that some file aka package_name.jar must be created. In such case we still hit the limit of 255 (or shorter for unicode) as most filesystems stops there (https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits)

re: length. I was thinking perhaps a limit that is quite high, but still manageable. E.g. 2048. That gives plenty of room for systematically verbose names, but keeps someone from accidentally cramming, say, raw iso contents into a name field :smirk:

However, I intended this issue to be primarily about the character set limits.

At the extreme end we could say: ascii characters only in names.

Also, I feel like there are different categories here.

With our own name fields (tags, targets, permissions, volumes, btypes, ext repos) I feel we could be more strict.

WIth content that comes from build content (e.g. package names, rpm names, archive names, also comps data) we need to be more flexible. We don't want to put too many artificial limits on what can be built.

I don't think we have to sort this out for 1.22

So, does it make sense to close it, that our internal fields are ascii, whle external input is utf-8?

@tkopecek and I talked about this issue a bit today and I will attempt to summarize here.

• This discussion has been open for six months and we haven't gotten a great deal of input.

• Some kind of size limit seems appropriate. After all a 1GiB tag name is absurd.

• The full span of unicode seems too much, and for that matter we might not want to allow all
  ascii either (control codes, whitespace)

• We don't know what the existing set of characters in use across Koji installations is

• The rules probably need to be different for "internal" fields like tag names, versus "external"
  fields like name, version, and release of builds

I think in the end we were mostly settled on making this configurable. That would probably be:

1. A configurable max length for the affected fields
2. A configurable regex that the affected fields must match
3. Perhaps other config flags to control application of rules that are difficult to code in a regex (e.g. ascii only)

It's a little unclear just where we want to apply this. The title of this issue refers specifically to name fields, but we have many other TEXT fields that are not names, and package names might need special treatment (ditto version and release).

PR 3028

Commit c160e48 fixes this issue

Commit 74ac826 fixes this issue