Libelektra: Crypto: GPG error returned by kdb set and kdb setmeta

[petermax2]

Steps to Reproduce the Problem

sudo kdb mount test.ini user/test crypto_gcrypt "crypto/key=$(elektra-gpg-testkey)" base64 ini
kdb setmeta user/test/password crypto/encrypt 1
kdb file user/test/password | xargs cat
kdb set user/test/password 1234
#> Set string to "1234"
kdb set user/test/config "I am not encrypted"
#> Create a new key user/test/config with string "I am not encrypted"
kdb file user/test/password | xargs cat

Expected Result

The value of the key user/test/password should be encrypted.

Actual Result

The command kdb setmeta failed while accessing the key database with the info:
Sorry, the error (#151) occurred ;(
Description: error in the GPG module.
Reason: GPG failed with return value 512. gpg: [don't know]: invalid packet (ctb=00)

Ingroup: plugin
Module: crypto
At: ../src/plugins/crypto/gpg.c:925
Mountpoint: user/test
Configfile: /root/.config/test.ini.4526:1554625598.571509.tmp

System Information

• Elektra Version: f38d443bb41be9aa97c267bba74a6d0a226014f2
• Operating System or Docker Container: docker
• Versions of other relevant software: gpg (GnuPG) 2.2.4, libgcrypt 1.8.1

Further Log Files and Output

The master password (part of the plugin configuration) is lost between checkconf (creation of the password) and kdb get (retrieval of the password).

The encrypted master password (measured in method ELEKTRA_PLUGIN_FUNCTION (gpgEncryptMasterPassword), gpg.c) has a length of 41. The retrieved master password (measured in method ELEKTRA_PLUGIN_FUNCTION (gpgDecryptMasterPassword), gpg.c) has a length of 1.

[markus2330]

Thank you for reporting this problem!

[petermax2]

The reason for this issue is that if ini is used as default storage, the master password (which is a binary value) can not be stored within Elektra's configuration (/etc/kdb/elektra.ini in my case):

[mountpoints/user\/test/getplugins/#9#crypto_gcrypt#crypto_gcrypt#/config/crypto]
key = 6C2CE3467EBF1BF8F5968792575C5FE620FA0712
[mountpoints/user\/test/getplugins/#9#crypto_gcrypt#crypto_gcrypt#/config/crypto/masterpassword]

[petermax2]

My suggestion to fix this issue is to generally Base64 encode and decode the "master password" (is this term still politically correct?).

@markus2330 crypto is still marked as "unfinished" and "discouraged", so breaking existing config should not be too bad, right?

[markus2330]

I think for now you can simply disable your plugins if ini is the default storage and write about that incompatibility (like in #2592). (But this incompatibility is actually against every storage plugin that does not support binary data and not specific for ini.)

The proper solution would be that ini recommends some plugin that makes sure no binary data is in the INI files (or implements such a feature itself).

E.g. the YAMLcpp plugin already supports binary data. Hopefully we soon replace the build-job INI-as-default with a YAML-as-default.

[markus2330]

Btw. it would be great if unfinished and discouraged would be removed soon :+1:

[petermax2]

Btw. it would be great if unfinished and discouraged would be removed soon

I know, but I'm really not confident about the crypto plugin(s). :laughing:

[petermax2]

I think for now you can simply disable your plugins if ini is the default storage

But it is very easy to store the master password encoded. I managed to do that and could provide a PR soon. Do you prefer to disable the plugins anyway?

[petermax2]

The (ini) configuration looks like this:

[mountpoints/user\/test/getplugins/#9#crypto_gcrypt#crypto_gcrypt#/config/crypto]
key = 6C2CE3467EBF1BF8F5968792575C5FE620FA0712
masterpassword = "hQGMA1dcX+Yg+gcSAQv+KUDwk0R1kUTv9y2iYlpG70lirqFVF5e+zmK4tnUwoqqwtVnPU4lcOjKz+D3+59T9Gjus6eOY059PWacgOKCRy0Srzw=="

I think this option is not too bad, even if a user sets a storage pluign, which does support binary values.

[markus2330]

If you already implemented this feature I'll of course accept it.

[petermax2]

Excellent! The PR is coming either tomorrow evening or over the weekend.