GPG error after upgrade to 4.1

[buck-E]

Describe the bug
After upgrading to 4.1 and working on #4054 (comment), the Version control settings say there is a GPG error.

To Reproduce
Steps to reproduce the behavior:

1. Go to settings > Version control
2. Enter "Source code repository" like git+ssh://[email protected]/repository.git
3. See error:

Could not update repository: error: gpg failed to sign the data fatal: failed to write commit object (128)
URL of a repository, use weblate://project/component to share it with other component.

Expected behavior
There should be no error because this repo is good and GPG signing is turned on in settings.py (unless there is a new setting in 4.1 that I missed? But I imported the old GPG setting from 4.0.4)

Server configuration and status
On pip installed Weblate:

$ weblate list_versions
 * Weblate: 4.1.1
 * Django: 3.0.5
 * siphashc: 1.3
 * Whoosh: 2.7.4
 * translate-toolkit: 3.0.0
 * lxml: 4.5.0
 * Pillow: 7.1.1
 * bleach: 3.1.4
 * python-dateutil: 2.8.1
 * social-auth-core: 3.3.3
 * social-auth-app-django: 3.4.0
 * django-crispy-forms: 1.9.0
 * oauthlib: 3.1.0
 * django-compressor: 2.4
 * djangorestframework: 3.11.0
 * django-filter: 2.3.0
 * django-appconf: 1.0.4
 * user-agents: 2.1
 * filelock: 3.0.12
 * setuptools: 44.0.0
 * jellyfish: 0.7.2
 * openpyxl: 3.0.3
 * celery: 4.4.2
 * kombu: 4.6.8
 * translation-finder: 2.1
 * html2text: 2020.1.16
 * pycairo: 1.19.1
 * pygobject: 3.36.0
 * diff-match-patch: 20181111
 * requests: 2.23.0
 * django-redis: 4.11.0
 * hiredis: 1.0.1
 * sentry_sdk: 0.14.3
 * Cython: 0.29.16
 * misaka: 2.1.1
 * GitPython: 3.1.1
 * borgbackup: 1.1.11
 * pyparsing: 2.4.6
 * Python: 3.8.3
 * Git: 2.26.2
 * psycopg2-binary: 2.8.5
 * phply: 1.2.5
 * chardet: 3.0.4
 * ruamel.yaml: 0.16.10
 * aeidon: 1.7.0
 * Redis server: 6.0.3
 * PostgreSQL server: 11.6
 * Database backends: django.db.backends.postgresql
 * Cache backends: default:RedisCache, avatar:FileBasedCache
 * Email setup: django.core.mail.backends.smtp.EmailBackend: localhost
 * OS encoding: filesystem=utf-8, default=utf-8
 * Celery: redis://localhost:6379, redis://localhost:6379, regular
 * Platform: Linux 4.9.0-8-amd64 (x86_64)

Additional context
Using weblate://project/component provides:

Invalid link to a Weblate project, cannot link it to itself!
URL of a repository, use weblate://project/component to share it with other component.

[nijel]

Is gpg installed on the system?

[buck-E]

Is gpg installed on the system?

Yes. And this was working until the upgrade to 4.1. Or at least - I only noticed that it was not working at that time. We did have other problems before that regarding the repo, but not this error message.

[nijel]

Things to check:

• Does gpg work? gpg --version
• Does gpg see the key? HOME=DATA_DIR/home/ gpg --list-secret-keys
• Does gpg signing work? HOME=DATA_DIR/home/ gpg --default-key KEYID --sign

[buck-E]

Does gpg work? gpg --version

Yes

Does gpg see the key? HOME=DATA_DIR/home/ gpg --list-secret-keys

Yes

Does gpg signing work? HOME=DATA_DIR/home/ gpg --default-key KEYID --sign

Yes, but...

gpg: all values passed to '--default-key' ignored

Question: does Weblate automatically generate a key if you specify the e-mail address in settings.py but it doesn't find a key?

[buck-E]

How do I "clean the cache"? (pip install)

[nijel]

See https://docs.weblate.org/en/latest/admin/optionals.html#gpg-sign, it generates the key if not found.

You can delete this particular cache entry using:

weblate shell -c 'from django.core.cache import cache; cache.delete("gpg-key-id")'

[buck-E]

weblate shell -c 'from django.core.cache import cache; cache.delete("

After doing this and deleting the key in question, and also stopping/restarting celery and running collectstatic, the public key shown on the keys/ page is the same one as before.

I also killed gpg-agent.

I think this means it is still cached?

[nijel]

Yes, the public key might be still cached, it uses different cache key. But that's just a display issue and should not affect functionality. Is a commit now working for you?

[buck-E]

Yes, the public key might be still cached, it uses different cache key. But that's just a display issue and should not affect functionality.

Okay. Anyway today the new key shows in the UI.

Is a commit now working for you?

No but now the error is different. Now I get

remote: Commit c9af1b1a4a3339b84a91ba9f1a7482e9d07222b7 was not signed by a GPG key, rejecting push

With new key I still get:

$HOME=DATA_DIR/home/ gpg --default-key KEYID --sign
gpg: all values passed to '--default-key' ignored
...
 ! [remote rejected] master -> master (pre-receive hook declined)

[buck-E]

So I think the problem could be that when upgrading to 4.1, Weblate lost the setting to sign with GPG. The key is there, and settings.py has WEBLATE_GPG_IDENTITY set correctly.

But /weblate-env/lib/python3.8/site-packages/data/home/.gitconfig did not have gpgsign=true and for some reason it did not have the signingkey = set.

So I set those manually and now the problem is gone.

It also added confusion that:

• I had a typo in the GPG key name in settings.py, so Weblate created a new key instead of using the old one.

• There was a UI issue preventing me from even seeing any errors (except server error): Can Not Commit After 4.1 upgrade #4054

So I think this is a bug with 4.1. When I upgraded, these settings went away (I guess?) and even changing settings.py did not update .gitconfig.

Keeping open as this fix is really just a hack.

[nijel]

But /weblate-env/lib/python3.8/site-packages/data/home/.gitconfig did not have gpgsign=true and for some reason it did not have the signingkey = set.

It was never there, it's set on the command line:

weblate/weblate/vcs/git.py

Lines 171 to 176 in 9976c84

	@staticmethod
	def get_gpg_sign_args():
	sign_key = get_gpg_sign_key()
	if sign_key:
	return ["--gpg-sign={}".format(sign_key)]
	return []

Generally, commit signing works in Weblate, you can see it for example on this commit: ae143d9

The issue with changed configuration not being applied was addressed in c3c6dd0. That probably lead to behavior you've observed.

[github-actions]

Thank you for your report, the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, consider supporting Weblate by donating.

[buck-E]

It was never there, it's set on the command line:

But in this case it was not happening, so my fix was necessary.

Generally, commit signing works in Weblate

Yes it was working for us before an upgrade (maybe to 4.0.4, maybe to 4.1, that is not clear)

The issue with changed configuration not being applied was addressed in c3c6dd0. That probably lead to behavior you've observed.

How? I upgraded more than 3 days ago and that is a more recent commit.

[JohnRDOrazio]

Things to check:

• Does gpg work? gpg --version
• Does gpg see the key? HOME=DATA_DIR/home/ gpg --list-secret-keys
• Does gpg signing work? HOME=DATA_DIR/home/ gpg --default-key KEYID --sign

Just a heads up for anyone trying this:

1. from the command line you may need to refer to a previously defined variable with a dollar sign: HOME=$DATA_DIR/home/ gpg --list-secret-keys
2. you may want to add the --armor option when signing, to prevent your terminal from turning into gibberish: HOME=$DATA_DIR/home/ gpg --default-key KEYID --sign --armor
3. Just in case you're not sure what to do after issuing --sign --armor, just type any message, then on a new line type CTRL-D (^D) to signal EOF (end of file)