Gpgme gave error gpgme 54 unusable secret key

Sync gpgme error: Unusable secret key about ros_buildfarm HOT 6 OPEN

There was just another instance of this today:

clalancette commented on January 15, 2023

tfoote commented on January 15, 2023

These last jobs failed within a minute of each other on separate days. Do we have a server maintenance task managing the gpg keys at that time? The earlier case is also just before the hour too.

nuclearsandwich commented on January 15, 2023

I saw a similar but different GPG error importing the jammy repositories today. https://build.ros2.org/job/import_upstream/357/

I am going to block out some time for this toward the start of next year.

ijnek commented on January 15, 2023

Update

ijnek commented on January 15, 2023

• doc_independent jobs have started failing due to dependencies moving forward to python 3.6 syntax on xenial base HOT 2
• 13 jobs still use EOL xenial base images HOT 2
• snapshots.ros.org returns code 504 HOT 2
• RHEL sync-packages-to-testing jobs are not upstreams of upload_testing
• Problems using github-branch-source plugin for pull request jobs
• doc jobs fail on buildfarm HOT 2
• Build farm doesn’t handle pip test dependencies properly HOT 12
• Prerelease.sh script cannot find /tmp/ros_buildfarm scripts HOT 2
• How to pre-release test with third party package
• Prerelease test with kinetic : » RuntimeError: Could not resolve the rosdep key ‘catkin’ » HOT 3
• ROS_ROOT not available when running devel job tests? HOT 5
• ROS 1 wiki package changelogs are outdated or missing HOT 13
• Proposal: Move ros_builfdarm scripts into libexec and invoke them with single ros_buildfarm binary.
• :man_farmer: `generate_ci_script,py` crashes when creating a benchmark script. HOT 1
• New release? HOT 7
• RUN rosdep init error HOT 2
• Migration from pulp to createrepo-agent HOT 20
• ROS2 build: cannot create directory error
• Humble build lto flags cause link errors

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

TensorFlow

An Open Source Machine Learning Framework for Everyone

Django

The Web framework for perfectionists with deadlines.

Laravel

A PHP framework for web artisans

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

Some thing interesting about web. New door for the world.

server

A server is a program made to process requests and deliver data to clients.

Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

Visualization

Some thing interesting about visualization, use data art

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.

Microsoft

Open source projects and samples from Microsoft.

Источник

Gpgme gave error gpgme 54 unusable secret key

This value indicates the end of a list, buffer or file.

This value indicates success. The value of this error code is 0 . Also, it is guaranteed that an error value made from the error code 0 will be 0 itself (as a whole). This means that the error source information is lost for this error code, however, as this error code indicates that no error occurred, this is generally not a problem.

This value means that something went wrong, but either there is not enough information about the problem to return a more useful error value, or there is no separate error value for this type of problem.

This value means that an out-of-memory condition occurred.

System errors are mapped to GPG_ERR_FOO where FOO is the symbol for the system error.

This value means that some user provided data was out of range. This can also refer to objects. For example, if an empty gpgme_data_t object was expected, but one containing data was provided, this error value is returned.

This value means that some recipients for a message were invalid.

This value means that some signers were invalid.

This value means that a gpgme_data_t object which was expected to have content was found empty.

This value means that a conflict of some sort occurred.

This value indicates that the specific function (or operation) is not implemented. This error should never happen. It can only occur if you use certain values or configuration options which do not work, but for which we think that they should work at some later time.

This value indicates that a decryption operation was unsuccessful.

This value means that the user did not provide a correct passphrase when requested.

This value means that the operation was canceled.

This value means that the engine that implements the desired protocol is currently not available. This can either be because the sources were configured to exclude support for this engine, or because the engine is not installed properly.

This value indicates that a user ID or other specifier did not specify a unique key.

This value indicates that a key is not used appropriately.

This value indicates that a key signature was revoced.

This value indicates that a key signature expired.

This value indicates that no certificate revocation list is known for the certificate.

This value indicates that a policy issue occurred.

This value indicates that no secret key for the user ID is available.

This value indicates that a key could not be imported because the issuer certificate is missing.

This value indicates that a key could not be imported because its certificate chain is not good, for example it could be too long.

This value means a verification failed because the cryptographic algorithm is not supported by the crypto backend.

This value means a verification failed because the signature is bad.

This value means a verification failed because the public key is not available.

GPG_ERR_USER_1 GPG_ERR_USER_2 . GPG_ERR_USER_16

Источник

Ошибка «Нет секретного ключа» при подписании git commit в Windows

Я получаю эту ошибку при попытке подписать коммит:

Это результат gpg —list-secret-keys —keyid-format LONG

Ключ там присутствует

А это git config с таким же ключом

Есть идеи, что случилось?

Сначала проверьте, есть git config gpg.program ли это gpg или gpg2 (как здесь ).

И введите where gpg nd, where gpg2 чтобы проверить, какой путь рассматривается для программы GPG.

Я предложил установить gpg.program в gpg2 , и копировать gpg.exe (при условии его версии является 2.x) для gpg2.exe

Это должно заставить Git / GPG действовать как gpg2.

Столкнулся с той же проблемой в Windows 10 git bash. Это решило мою проблему. Вы можете найти этот путь, запустив where gpg

$ git config —global gpg.program «C:Program FilesGitusrbingpg.exe»

В случае , если кто — нибудь это dufus как я я получаю эту ошибку , потому что я имел gitkey неправильно во время непосредственного редактирования файла с помощью: git config —global -e или code

/.gitconfig или любого вкуса редактора , вам понравится.

git config —global gpg.program «c:/Program Files (x86)/GnuPG/bin/gpg.exe»

Я установил с помощью Kleopatra и сгенерировал в нем свой ключ. Мне не удалось создать фиксацию, пока я не выполнил указанную выше команду.

Источник

Gpgme gave error gpgme 54 unusable secret key

This ticket tracks migrating the RPM repository management tool used in ros_buildfarm from pulp to a new purpose-built tool called createrepo-agent.

Background

RPM repository metadata consists of a collection of XML files which reside in a subdirectory of the repository root. The root document, repomd.xml , can be signed using a GPG key. Unlike debian metadata which uses a «clearsign» signature, the repomd.xml.asc is a «detached» signature. Any modification to the contents of the repository typically results in changes to each of the

5 XML files and the signature.

Pulp is a general-purpose content management solution with robust plugins specifically targeted at RPMs. It leverages postgresql, redis, Django, and stores payload data in a CAS. It is written in Python, and uses several daemon processes to implement different roles to service different types of requests.

Motivation for this change

Pulp is a very powerful content management tool, but it is extremely heavyweight and complex. Implementing the required queries to perform package invalidation (as is required by ros_buildfarm ) means that we must perform import operations serially, and performance at our scale has become unsustainable. Central to our performance problems are that metadata generation in Pulp is far too slow.

Additionally, the way RPM repository metadata is hosted inherently provides for races when updating metadata that clients may be simultaneously downloading due to the fact that several separate files must be updated together. Pulp has no mitigation for this problem, and it is causing jobs to occasionally fail to download repository metadata.

Another problem with our current solution is that the serialization of repository operations is tightly coupled to Jenkins, making it difficult to experiment with other orchestration and execution solutions.

After analyzing the performance problems we’re currently experiencing with Pulp, it was decided that a new tool should be created which can solve several of the problems holding us back today.

Overview of createrepo-agent

• Background process which keeps metadata in memory so that it doesn’t need to be re-read for each change — only written.
• Integrated change queue which not only ensures that simultaneous operations do not overwrite each other, but also batches all pending changes in the same metadata write operation.
• No system provisioning beyond installation of the tool — existing repositories can be used or new ones created as necessary.
• Process for keeping old metadata files (other than the top-level repomd.xml ) and retiring after it is unlikely to be requested.

Roll out process

Created at 3 months ago

Hi, I’m currently release the pepper_meshes package for ROS2, and the CI fails while building the binaries:

(here’s the full log for more details)

When building the package, a temporary directory is created to download and unzip the meshes (see that part of the CMakeLists.txt). This process worked with all ROS1 distros, but doesn’t see to fly with the ROS2 CI. Is that normal, and if so, do you have any idea on how to overcome that?

Created at 4 months ago

This project includes a large number of scripts, many of the form generate_*_.py (92). This makes it a rather unwieldy when installed in a global FHS such as a debian package.

Since many of these scripts don’t include ros_buildfarm some amount of digging is required to identify their provenance.

I’d like to propose updating the installation mechanism for these scripts allowing them to be used in a libexec style. I haven’t yet looked closely enough to see whether the entry points specification could be used instead (or as an implementation detail for accomplishing the same effect).

I can see reasons to make this change gradually by first quickly re-organizing the existing scripts so that they’re runnable as

and then later transitioning to a more common git-style subcommand pattern. As well as reasons to break the CLI interface exactly once and build to our desired end state from the beginning but I also don’t know what that end state is.

Potential command patterns

• libexec / runner pattern: ros_buildfarm generate_release_script.py . , ros_buildfarm create_devel_task_generator.py .
• git subcommand pattern: ros_buildfarm release generate_script . , ros_buildfarm devel create_task_dockerfile .

There are a couple of miscellaneous scripts like the apt and git wrappers, and the subprocess reaper which may need special handling although I think these scripts may only be used from within the other scripts and thus may not need to be installed as scripts at all.

Created at 4 months ago

a@b:/tmp/prerelease_job$ ./prerelease.sh
Step 24/27 : RUN rosdep init
—> Running in 9ee7afba1935
ERROR: cannot download default sources list from:
https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/sources.list.d/20-default.list
Website may be down.
Removing intermediate container 9ee7afba1935
The command ‘/bin/sh -c rosdep init’ returned a non-zero code: 4

but i can visit the page and the command sudo rosdep init , rosdep update run in the terminal is ok

Created at 4 months ago

We’ve been using 3.0.0 up till now but since ros-infrastructure/bloom#649 was merged, it fails. Could a new release be tagged please?

Created at 6 months ago

I’m refiling osrf/infrastructure#3 (comment) here so that we can track this.

A somewhat similar thing happened to Melodic over the weekend; see https://discourse.ros.org/t/testing-repository-empty-amd64/20908 for some more of the details.

I’m wondering if it would make sense to have the sync-to-testing jobs run nightly, as a backup in case something failed. That way the time frame of the breakage (if it does occur) would at least be time-limited.

In the failed melodic log noticed that there’s actually a real error that we should not be having

We should make sure that doesn’t happen.

Created at 6 months ago

Bug Report

I’m not able to reproduce a benchmark job locally using the buildfarm scripts.

Steps to reproduce

Additional info

It works with other jobs normally, apparently is failing only with the benchmark job, even when it’s there in the index.yaml file. Apparently there’s a problem with its template generation, and shows this error:

I found this while investigating: ros-tooling/libstatistics_collector#132
Which is actually a problem in the benchmark job to find openssl.

Created at 8 months ago

The discussion of the problem started on Discourse .

Two example packages with problems:

https://wiki.ros.org/message_filters points to Changelog for package message_filters, which has latest release 1.15.9. However, the latest entry in message_filters changelog on github is 1.15.14.

https://wiki.ros.org/robot_body_filter — ROS Wiki is released into Noetic and has a doc job enabled. But the changelog is not there at all: Changelog . However, the doc job log says it was processed and generated: Ndoc__robot_body_filter__ubuntu_focal_amd64 #8 Console [Jenkins]

Many many more packages are affected. I actually don’t remember seeing a Changelog on Wiki that would be up-to-date (I’ve seen tens of them over the last few years).

Created at 10 months ago

Some recent changes to the buildfarm will break if the deployed Jenkins jobs are not in sync with the repository, so we’ll need to make the changes in multiple stages. This issue tracks the follow-up stages of the changes so that the backwards-compatible changes aren’t left in the code.

• #726 added the os_name argument to run_check_sync_criteria_job.py . That argument should be made required.
• #769 changed the behavior of some directory arguments to facilitate decoupling. Those arguments should be made required or mapped in the scripts to become used as necessary.
  • #709 is an intermediate change to start using the arguments modified in the first change
• #781 modified an argument to pass the os_name . The old argument should be dropped. Additionally, an Ubuntu-specific wrapper function should be dropped from status_page.py .
• #785 introduced an object for storing platform-specific package metadata retrieved from a repository. That str -compatible object should be replaced with a namedtuple as described in the comments.
• [ ] #787 added an attribute to an existing namedtuple and was given a default value. That default should be dropped making the new attribute mandatory.
• #922 deprecated a redundant function argument which should be removed.
• #926 deprecated an unused function argument which should be removed.
• #941 deprecated an unused function argument which should be removed.

Created at 10 months ago

Already Failing

• doc_independent #877
• doc_rosindex
  • ros2/ros2_documentation#1518
  • ros-infrastructure/rosindex#268
  • hidmic/sphinx-tabs#1

Not yet failing

• ci_create_reconfigure_task #906
• devel_create_reconfigure_task #906
• doc_create_reconfigure_task #884
• doc_metadata_task #884
• rosdistro_cache_task #886
• release_check_sync_criteria_task #886
• release_create_reconfigure_task #886
• release_create_trigger_task #886
• blocked_releases_page_task #885
• blocked_source_entries_page_task #885
• release_compare_page_task #885
• release_status_page_task #885

Created at 11 months ago

However after that was verified we found that the ros_buildfarm doesn’t use the same rosdep code paths and was causing regressions on the buildfarm. In particular the devel jobs.

And we reverted the libcurl change: ros/rosdistro#18223

Another instance was just found: ros/rosdistro#18272 where a previously used package has been changed to be a virtual package.

The query logic needs to be extended to support virtual packages that are provided by other packages in the same way that rosdep was extended.

Created at 1 year ago

Following the steps in http://prerelease.ros.org/kinetic, I generated a prerelease script, but when I run it ( ./prerelease.sh ) :

Indeed, it seems that the Rosdepview object does not contain some keys, like the ‘catkin’ one.

It may be that rosdep skips the kinetic version?

in this case, is it still possible to run the prerelease tests for kinetic?

I was trying with a repository of mine, but the problem occurs also for other repos, like moveit_msgs.
You should be able to replicate the issue with (command generated by the website):

Created at 1 year ago

It started failing 3 days ago.

Jinja has also jumped up to 3.x from 2.x in the last few hours. https://pypi.org/project/Jinja2/#history

pinning to markupsafe==1.1.1

The problem is that this is still running xenial and that’s officially EOL which is why everyone’s moving forward.

Created at 1 year ago

I want to release a package to ROS community. Firstly, I run a pre-release test.
After ./prerelease.sh , I got this error:

`
==> Processing catkin package: ‘vino_core_lib’
==> Creating build directory: ‘build_isolated/vino_core_lib’
==> Building with env: ‘/tmp/ws/install_isolated/env.sh’
==> cmake /tmp/ws/src/ros_openvino_toolkit__custom-1/vino_core_lib -DCATKIN_DEVEL_PREFIX=/tmp/ws/devel_isolated/vino_core_lib -DCMAKE_INSTALL_PREFIX=/tmp/ws/install_isolated -DBUILD_TESTING=0 -DCATKIN_SKIP_TESTING=1 -G Unix Makefiles in ‘/tmp/ws/build_isolated/vino_core_lib’
— The C compiler identification is GNU 7.5.0
— The CXX compiler identification is GNU 7.5.0
— Check for working C compiler: /usr/lib/ccache/cc
— Check for working C compiler: /usr/lib/ccache/cc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info — done
— Detecting C compile features
— Detecting C compile features — done
— Check for working CXX compiler: /usr/lib/ccache/c++
— Check for working CXX compiler: /usr/lib/ccache/c++ — works
— Detecting CXX compiler ABI info
— Detecting CXX compiler ABI info — done
— Detecting CXX compile features
— Detecting CXX compile features — done
— Looking for inference engine configuration file at:
CMake Error at CMakeLists.txt:31 (find_package):
By not providing «FindInferenceEngine.cmake» in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
«InferenceEngine», but CMake did not find one.

Could not find a package configuration file provided by «InferenceEngine»
with any of the following names:

Add the installation prefix of «InferenceEngine» to CMAKE_PREFIX_PATH or
set «InferenceEngine_DIR» to a directory containing one of the above files.
If «InferenceEngine» provides a separate development package or SDK, be
sure it has been installed.

— Configuring incomplete, errors occurred!
See also «/tmp/ws/build_isolated/vino_core_lib/CMakeFiles/CMakeOutput.log».
cd /tmp/ws/build_isolated/vino_core_lib && /tmp/ws/install_isolated/env.sh cmake /tmp/ws/src/ros_openvino_toolkit__custom-1/vino_core_lib -DCATKIN_DEVEL_PREFIX=/tmp/ws/devel_isolated/vino_core_lib -DCMAKE_INSTALL_PREFIX=/tmp/ws/install_isolated -DBUILD_TESTING=0 -DCATKIN_SKIP_TESTING=1 -G ‘Unix Makefiles’
`

This package need the third party package OpenVINO support.
So, how can i add this dependence?

Источник

We have a private debian repository that was set up years ago by an earlier system admin. Packages were signed by the older key, 7610DDDE (which I had to revoke), as shown here for the root user on the repo server.

# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid                  Debian Archive Automatic Signing Key (2006)  <ftpmaster@debian.org>

pub   1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

pub   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

All commands below are as the root user.
I modified the repository/conf/distributions file to use the new sub key I created explicityly for signing:

Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672

But when I use dput to update a package I get

Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)

And when I run reprepro export directly I get:

# reprepro -V export unstable
Exporting unstable...
 generating main/Contents-i386...
 generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!

I Googled and found a couple of old threads that indicated a possible problem with reprepro finding the proper gnupg directory…so I tried this with the same results above:

# GNUPGHOME=/root/.gnupg reprepro -V export unstable

One thread suggested testing the key by signing a dummy file which seemed to work fine…at least it reported no errors and I ended up with a 576 byte bla.gpg file after it was finished.

# touch bla
# gpg -u DD219672 --sign bla

The reprepro man page also suggests «If there are problems with signing, you can try gpg —list-secret-keys value to see how gpg could interprete the value. If that command does not list any keys or multiple ones, try to find some other value (like the keyid), that gpg can more easily associate with a unique key.» So I checked that as well and got:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

And finally I was able to get in touch with the sys admin that first set up our repros and he suggested trying a key without a passphrase. So I generated a new signing key, DD219672, published it, went through the above steps again but with the same result.

Today, after more reading and studying man pages and noting that pgp-agent is automatically started when I run reprepro, I decided to chase that for a while.

I added a gpg-agent.conf with

debug-level 7
log-file    /root/gpg.agent.log
debug-all

And I can see in the log that gpg-agent is not finding the keys

2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]

I have so far been unable to figure out where gpg-agent is finding the keys it lists in HAVKEY and how to point it in the right direction to find the new key, DD219672, to sign our updated packages.

Using gpgme (the development library for gpg/gnupg), I’m trying to sign some data.
In the key ring I have more then 1 private key so I want to select the
correct one.
This fails with: «Unusable secret key (117440566)».
The key was generated with gnupg2 itself. When using gnupg the problem also occurs.

sec   1024R/14B7E8E6 2015-05-27
      Key fingerprint = 95C7 6C5E F839 43DA 2F32  2CF4 D2C2 5144 14B7 E8E6
uid                  testkey2 (testkey2) <test@vanheusden.com>
ssb   1024R/ED8059EA 2015-05-27

pub  rsa1024/14B7E8E6
     created: 2015-05-27  expires: never       usage: SC
     trust: ultimate      validity: ultimate
sub  rsa1024/ED8059EA
     created: 2015-05-27  expires: never       usage: E
sub  rsa1024/74D6F5C6
     created: 2015-05-31  expires: never       usage: S

First I check if there’s a private key for the key selected:

gpgme_op_keylist_start(..., ..., 1);
if (gpgme_op_keylist_nex() == GPG_ERR_NO_ERROR) { proceed }

do the signing:

gpgme_new()
gpgme_set_pinentry_mode(GPGME_PINENTRY_MODE_LOOPBACK) // yes i installed v2.1
gpgme_set_passphrase_cb()
/* ...binary to gpgme_data_t... */
gpgme_data_set_encoding(GPGME_DATA_ENCODING_BINARY)
gpgme_signers_clear()
gpgme_signers_add()   // <- that key that I checked for existance earlier
if (gpgme_signers_count() != 1) { fail(); } // sanity check
gpgme_op_encrypt_sign(ctx, recipient, GPGME_ENCRYPT_ALWAYS_TRUST /* FIXME */, data_in, sig);

Now that gpgme_op_encrypt_sign always fails with that «Unusable secret key (117440566)» error.
Any tips/hints?

Software versions:

gnupg    1.4.18-7
gnupg-agent      2.1.4-1
gnupg2   2.1.4-1
libgpgme++2      4:4.14.2-2+b1
libgpgme11:amd64         1.5.1-6
libgpgme11-dev   1.5.1-6
python-gnupginterface    0.3.2-9.1

I enabled debug-tracing but it doesn’t help me much:

<0x1927>  gpgme_debug: level=4
<0x1927>  gpgme_check_version: call: 0=(nil), req_version=(null), VERSION=1.5.1
<0x1927>  gpgme_check_version_internal: call: 0=(nil), req_version=(null), offset_sig_validity=60
<0x1927>  gpgme_set_locale: enter: ctx=(nil), category=0, value=C
<0x1927>  gpgme_set_locale: leave
<0x1927>  gpgme_set_locale: enter: ctx=(nil), category=5, value=C
<0x1927>  gpgme_set_locale: leave
<0x1927>  gpgme-dinfo: gpgconf='/usr/bin/gpgconf'
<0x1927>  gpgme-dinfo:     gpg='/usr/bin/gpg2'
<0x1927>  gpgme-dinfo:   gpgsm='/usr/bin/gpgsm'
<0x1927>  gpgme-dinfo: homedir='/home/folkert/.gnupg'
<0x1927>  gpgme-dinfo:   agent='/home/folkert/.gnupg/S.gpg-agent'
<0x1927>  gpgme-dinfo:   uisrv='/home/folkert/.gnupg/S.uiserver'
<0x1927>  gpgme_new: enter: r_ctx=0x7fff5afd07a8
<0x1927>  gpgme_new: leave: ctx=0x20c0810
<0x1927>  gpgme_op_keylist_start: enter: ctx=0x20c0810, pattern=0BF38589, secret_only=1
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c0810, fd 4, dir=1 -> tag=0x20c26b0
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c0810, fd 6, dir=1 -> tag=0x20c2800
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 0, type_data (nil)
<0x1927>  gpgme_op_keylist_start: leave
<0x1927>  gpgme_op_keylist_next: enter: ctx=0x20c0810
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2820, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2820, handler (0x20c0c10, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = sec:u:2048:1:CC73A8A60BF38589:1433443717:::u:::scESC::::::
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = fpr:::::::::20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = uid:u::::1433443717::9963CFDE0C8920AD077B06A281992C4008E67E4F::testkey3 (testkey3) <test@vanheusden.com>:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = ssb:u:2048:1:22317805D48C1491:1433443717::::::e::::::
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = fpr:::::::::FB6FFB7D8BEC710A745DE86C22317805D48C1491:
<0x1927>    _gpgme_run_io_cb: call: item=0x20c26d0, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c26d0, handler (0x20c0c10, 4)
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c26b0, setting fd 0x4 (item=0x20c26d0) done
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2820, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2820, handler (0x20c0c10, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = (null)
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 2, type_data 0x20c2850
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c2800, setting fd 0x6 (item=0x20c2820) done
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd0700
<0x1927>  gpgme_op_keylist_next: leave: key=0x20c2850 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589)
<0x1927>  gpgme_release: call: ctx=0x20c0810
<0x1927>  gpgme_new: enter: r_ctx=0x7fff5afd0818
<0x1927>  gpgme_new: leave: ctx=0x20c2210
<0x1927>  gpgme_op_keylist_start: enter: ctx=0x20c2210, pattern=4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02, secret_only=0
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c2210, fd 4, dir=1 -> tag=0x20c1f50
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c2210, fd 6, dir=1 -> tag=0x20c1fa0
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 0, type_data (nil)
<0x1927>  gpgme_op_keylist_start: leave
<0x1927>  gpgme_op_keylist_next: enter: ctx=0x20c2210
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1fc0, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1fc0, handler (0x20c0c10, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = (nil), line = tru::0:1433443869:2410285847:3:1:5
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = (nil), line = pub:-:1024:17:3AD6F8118300CC02:1039074767:::-:::scESC::::::
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = fpr:::::::::4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:-::::1203999932::275AAD3E991F1962AD510CC96760907BE70FE668::Bla <bla@com>:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:-::::1203999938::59689891229F1817EF66BFC63D9D0BB2F45F5209::Bla <bla@com>:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:r::::::8A709552E7AB85B53DDAE18A48C0978E5EBF5547::Bla <bla@com>:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = sub:-:2048:16:942E547C12A6B1C2:1039075030::::::e::::::
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = fpr:::::::::E69EF5226BBF7EC14F1D7D96942E547C12A6B1C2:
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1f70, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1f70, handler (0x20c0c10, 4)
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c1f50, setting fd 0x4 (item=0x20c1f70) done
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1fc0, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c1fc0, handler (0x20c0c10, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = (null)
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 2, type_data 0x20c2b70
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c1fa0, setting fd 0x6 (item=0x20c1fc0) done
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd0760
<0x1927>  gpgme_op_keylist_next: leave: key=0x20c2b70 (4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02)
<0x1927>  gpgme_release: call: ctx=0x20c2210
<0x1927>  gpgme_new: enter: r_ctx=0x7fff5afd07c8
<0x1927>  gpgme_new: leave: ctx=0x20c2550
<0x1927>  gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=(nil)/(nil)
<0x1927>  gpgme_set_pinentry_mode: call: ctx=0x20c2550, pinentry_mode=4
<0x1927>  gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=0x403420/0x20c0058
<0x1927>  gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=0x403420/0x20c0058
<0x1927>  gpgme_new: enter: r_ctx=0x7fff5afd0768
<0x1927>  gpgme_new: leave: ctx=0x20c0810
<0x1927>  gpgme_op_keylist_start: enter: ctx=0x20c0810, pattern=0BF38589, secret_only=0
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c0810, fd 4, dir=1 -> tag=0x20c4fd0
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c0810, fd 6, dir=1 -> tag=0x20c5120
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 0, type_data (nil)
<0x1927>  gpgme_op_keylist_start: leave
<0x1927>  gpgme_op_keylist_next: enter: ctx=0x20c0810
<0x1927>    _gpgme_run_io_cb: call: item=0x20c5140, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c5140, handler (0x20c1d50, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = tru::0:1433443869:2410285847:3:1:5
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = pub:u:2048:1:CC73A8A60BF38589:1433443717:::u:::scESC:::::: 
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = fpr:::::::::20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589:  
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = uid:u::::1433443717::9963CFDE0C8920AD077B06A281992C4008E67E4F::testkey3 (testkey3) <test@vanheusden.com>:
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = sub:u:2048:1:22317805D48C1491:1433443717::::::e::::::
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = fpr:::::::::FB6FFB7D8BEC710A745DE86C22317805D48C1491:
<0x1927>    _gpgme_run_io_cb: call: item=0x20c4ff0, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c4ff0, handler (0x20c1d50, 4)
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c4fd0, setting fd 0x4 (item=0x20c4ff0) done
<0x1927>    _gpgme_run_io_cb: call: item=0x20c5140, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c5140, handler (0x20c1d50, 6)
<0x1927>    gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = (null)
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 2, type_data 0x20c5170
<0x1927>      _gpgme_remove_io_cb: call: data=0x20c5120, setting fd 0x6 (item=0x20c5140) done
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd06c0
<0x1927>  gpgme_op_keylist_next: leave: key=0x20c5170 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589)
<0x1927>  gpgme_release: call: ctx=0x20c0810
<0x1927>  gpgme_signers_clear: call: ctx=0x20c2550
<0x1927>  gpgme_signers_add: enter: ctx=0x20c2550, key=0x20c2850 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589)
<0x1927>  gpgme_signers_add: leave
<0x1927>  gpgme_op_encrypt_sign: enter: ctx=0x20c2550, flags=0x1, plain=0x20c2ed0, cipher=0x20c3f20
<0x1927>  gpgme_op_encrypt_sign: check: ctx=0x20c2550, recipient[0] = 0x20c5170 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589)
<0x1927>    gpgme_sig_notation_get: call: ctx=0x20c2550, ctx->sig_notations=(nil)
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c2550, fd 4, dir=1 -> tag=0x20c2070
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c2550, fd 8, dir=1 -> tag=0x20c21c0
<0x1927>    _gpgme_add_io_cb: call: ctx=0x20c2550, fd 11, dir=0 -> tag=0x20c2210
<0x1927>    gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 0, type_data (nil)
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2230, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2230, handler (0x20c2ed0, 11)
<0x1927>    _gpgme_data_outbound_handler: enter: dh=0x20c2ed0, fd=0xb
<0x1927>    _gpgme_data_outbound_handler: leave
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2230, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2230, handler (0x20c2ed0, 11)
<0x1927>    _gpgme_data_outbound_handler: enter: dh=0x20c2ed0, fd=0xb
<0x1927>        _gpgme_remove_io_cb: call: data=0x20c2210, setting fd 0xb (item=0x20c2230) done
<0x1927>    _gpgme_data_outbound_handler: leave
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2090, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2090, handler (0x20c1d50, 4)
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2090, need to check
<0x1927>    _gpgme_run_io_cb: call: item=0x20c2090, handler (0x20c1d50, 4)
<0x1927>    _gpgme_cancel_with_err: enter: ctx=0x20c2550, ctx_err=117440566, op_err=0
<0x1927>        _gpgme_remove_io_cb: call: data=0x20c2070, setting fd 0x4 (item=0x20c2090) done
<0x1927>        _gpgme_remove_io_cb: call: data=0x20c21c0, setting fd 0x8 (item=0x20c21e0) done
<0x1927>      gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd06c0
<0x1927>    _gpgme_cancel_with_err: leave
<0x1927>  gpgme_op_encrypt_sign: error: Unusable secret key <GPGME>
<0x1927>  gpgme_release: call: ctx=0x20c2550

EDIT

As requested by @kylehuff, here’s the code for the key selection:

search_key_result_t gpgme::find_key(const std::string & key_id, const bool priv_key_only, gpgme_key_t *k, std::string *const error)
  {
          error -> clear();

          *k = NULL;

          gpgme_ctx_t ctx = NULL;
          if (!my_gpgme_new(&ctx, false, error))
                  return SK_ERROR;

          gpgme_error_t err = gpgme_op_keylist_start(ctx, key_id.c_str(), priv_key_only ? 1 : 0);
          if (err != GPG_ERR_NO_ERROR)
          {
                  error -> append(format("Problem searching for %s: %s (%d)", key_id.c_str(), gpg_strerror(err), err));
                  gpgme_release(ctx);
                  return SK_ERROR;
          }

          err = gpgme_op_keylist_next(ctx, k);
          if (err == GPG_ERR_EOF)
                  return SK_NOT_FOUND;

          if (err != GPG_ERR_NO_ERROR)
          {
                  error -> append(format("Problem finding %s: %s (%d)", key_id.c_str(), gpg_strerror(err), err));
                  gpgme_release(ctx);
                  return SK_ERROR;
          }

          gpgme_release(ctx);

          return SK_FOUND;
  }

Then in the constructor I do:

std::string error;
  if (find_key(my_key_id, true, &my_key, &error) != SK_FOUND)
          error_exit(false, "Cannot find key %s: %s", my_key_id.c_str(), error.c_str());

and when it is time to sign:

          if (find_key(target_uid, false, &recipient[0], error) != SK_FOUND)
                  break;

          gpgme_signers_clear(ctx);
          err = gpgme_signers_add(ctx, my_key);
          if (err != GPG_ERR_NO_ERROR)
          {
                  error -> append(format("gpgme_signers_add(%s) failed: %s (%d)", my_key_id.c_str(), gpg_strerror(err), err));
                  break;
          }

          int n_signers = gpgme_signers_count(ctx);
          if (n_signers != 1)
          {
                  error -> append(format("Number of signers (%d) not expected number (1)", n_signers));
                  break;
          }

          err = gpgme_op_encrypt_sign(ctx, recipient, GPGME_ENCRYPT_ALWAYS_TRUST /* FIXME */, data_in, sig);
          if (err != GPG_ERR_NO_ERROR)
          {
                  error -> append(format("gpgme_op_encrypt failed: %s (%d)", gpg_strerror(err), err));
                  break;
          }

@kylehuff, is this what you requested?
Thanks

EDIT

Here’s the listing for 20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589:

tru::0:1433443869:2410285847:3:1:5
pub:u:2048:1:CC73A8A60BF38589:2015-06-04:::u:testkey3 (testkey3) <test@vanheusden.com>::scESC:
sub:u:2048:1:22317805D48C1491:2015-06-04::::::e:

EDIT

folkert@travelmate:~$ gpg2 —local-user 14B7E8E6 —sign bla.txt

folkert@travelmate:~$ gpg —verify bla.txt.gpg
gpg: Signature made Thu 18 Jun 2015 07:18:17 PM UTC using RSA key ID 74D6F5C6
gpg: Good signature from «testkey2 (testkey2) «

and with edit key I can see that 74d6f5c6 is indeed the sign sub-key:

sub 1024R/74D6F5C6 created: 2015-05-31 expires: never usage: S

So I’m a bit surprised that this doesn’t work for gpgme.
Not doing the find but directly the gpgme_get_key() gives the same error.