Configuring time.FORMAT breaks ssh

[mnsh]

• Gitea version (or commit ref): a2d365c
• Git version: 2.11.0
• Operating system: CentOS-6.9
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Lately SSH access to a gitea instance of ours tracking the master branch has been broken. Doing a clone or pull over ssh simply hangs, with gitea serv key-X --conf=... blocking on waitid(...) and it's spawned git-upload-pack org/repo.git blocking on read(0, ...).

After a little digging, I tried running the expected gitea serv ... command as the gitea user:

$ SSH_ORIGINAL_COMMAND="git-upload-pack '/org/test.git'" /usr/local/bin/gitea serv key-1 --config=/path/to/conf/app.ini
2017/04/20 03:45:15 [T] Custom TimeFormat: 2006-01-02 15:04:05 CET
00f263b78e06ee70f741ce1360f5c6c2e15a09df4d3e HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2.11.0
003f63b78e06ee70f741ce1360f5c6c2e15a09df4d3e refs/heads/master
0000

The first line in the output is causing the problem - it's written to stdout, which git expects to "own".

Commenting out [time] -> FORMAT in the configuration or commenting out the log.Trace("...")-call in modules/setting/setting.go restores SSH access to gitea.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[ptman]

this is quite annoying

[zeripath]

Hi is this still happening in 1.8?

I thought I'd got upload pack et al to be truly quiet in #5887.

If it's still happening I should be able to fix.