The emoticons that you put in the description field of the composer.json of your packages breaks uploads to Artifactory.

[DR4296]

Version: ALL

Bug Description

I'm a developer who works in an organization that uses JFrog's Artifactory as its repo system.
I couldn't figure out why Composer was complaining that your nette/schema and later nette/utils libraries weren't in the repository when I could plainly see them. However, I noticed that they were missing a lot of listings on their "properties" tab in Artifactory. And this tipped me off. When I saw the emoticons in the Description fields, I removed them and repackaged the .zip. I then uploaded them to Artifactory and suddenly Composer could see them.

Steps To Reproduce

... If possible a minimal demo of the problem ...

Expected Behavior

... A clear and concise description of what you expected to happen.

Possible Solution

  Remove emoticons from your composer.json for your packages.  Keep everything UTF-8. 

[dg]

Shouldn't you rather report this as a bug in JFrog's Artifactory? The composer.json file is, of course, entirely in UTF-8.

[vardumper]

@dg I disagree. I recently reported this problem the emoticons cause with trivy vulnerability scan: rectorphp/swiss-knife#92 over at rectorphp.

Same attitude, over there: "Have nette fix this." I can see how it's very comfortable to send people around repositories, have them report issues that only araise because someone insisting on putting emoticons all over the place.

Really? Are you going to send me back to trivy?
I just wish people could take responsibility for the troubles they cause others and not dismiss their valid concerns like this.

[mabar]

I think that this could be easily fixed on Composer side, by using json_encode($data, JSON_UNESCAPED_UNICODE); instead of json_encode($data);

[vardumper]

Appreciate the feedback. Thanks

[mabar]

@vardumper Here's some reasoning, so you have a fighting chance.

Non-ascii/UTF-8/UTF-16/... characters are not just emojis, but also Chinese, Japanese and many other characters. Removing the emojis is therefore not really a solution, just workaround.

The PHP's json decoder handles well both escaped and unescaped unicode sequences. However this may not be the case everywhere because the specification recommends UTF-8 encoding. Not escaping unicode with PHP's json encoder could help.

In Go lang's (in which Trivy is written) encoding/json package works well with unescaped unicode:

var msg map[string]interface{}
json.Unmarshal([]byte(`{"message":"Success 😀","ok":true}`), &msg)
fmt.Println(msg)
// -> map[message:Success 😀 ok:true]

If this is not how Trivy decodes json, change on their side might be needed as well.

With encoding/json and escaped unicode, the situation is much more problematic and I believe it's the root cause of your issues. More in-depth explanation here

---

@DR4296 Your issue is likely of the same nature because Artifactory's creators JFrog use Go as well.

---

Related issues for reference: golang/go#39137, composer/composer#12338, #324

[vardumper]

so trivy uses jfather and already seem to have created a fix for this. interesting details, thanks for the insights and explanation. I'm still curious how the escaped installed.json - I found in the swiss-knife (and ECS) repos - was generated though. As per composer team, they do use unescaped unicode, so I would expect to see an emoticon instead. Maybe some linting gone wrong...