Show OpenPGP notation data in Seahorse

This week I picked up Keyoxide to offer a verifyable way to my online identity claims.
The project makes use of OpenPGP Notation Data.

Since I use Seahorse as my GUI for managing GPG keys, I was wondering whether there is interest in exposing this information in the interface as well.
Right now I’m using GPG for it.

Seahorse maintainer here. It’s definitely an interesting thought, and I personally haven’t had any use for notation data, so I wonder if there are any other know use cases out there, and what the possible downsides might be.

One thing I can particularly think is that we’d have to load our keys with the GPGME_KEYLIST_MODE_SIG_NOTATIONS flag (per the GPGME manual) , which is noted there to possible lead to a problematic performance hit.

Wow, I didn’t expect an answer that fast :open_mouth:
Great to have reached the right person then.

Thank you for considering the inclusion. Before Keyoxide I wasn’t even aware of that feature (but I still have to get used to reading specs, too). I forwarded your question to Yarmo (maintainer of Keyoxide) and await an answer. If I don’t receive one by the end of the week I’m going to bring it to their forums to prevent it from getting lost in some chat backlog.

When looking at

it appears that Seahorse is written in C. I guess this means the feature couldn’t be controlled by a checkbox? (I’m more familiar with interpreted languages, so don’t know how compiled once behave here). Is there a way to load the flag on demand? Possibly after a restart of the application?

I’m trying to get a better understanding of the limitations of a C application here.

Note that the fact that the app is written in C is quite irrelevant here :slight_smile: (and for what it’s worth, it also partially written in Vala). Changing an option like that at runtime is doable in any programming language I can think of.

Now: adding an option to the app for fetching/showing notation data could be a possibility, but I’d really like to avoid that, especially since they’re really quite esoteric. There’s a good chance it will end up that

(a) nobody (including the devs) except for a small group of users turn on the option, which makes the whole thing immediately bitrot as it goes mostly untested. There’s a good chance it’ll break once in a while making the future less useful which is going to be a frustrating experience for everybody
(b) We turn it on by default and users (might) suddenly deal with a degraded performance, which to them will look like a regression. They’ll file bugs which then have to be closed with “oh yeah that’s some fancy option you can probably turn off”

So all not ideal. If we’re going to add support notation data, it’ll be unconditionally . But that can only happen on the condition that it can’t degrade the app.

Finally: even though we might agree at some point that this would be good to add, please consider that someone still has to do the work and that Seahorse is a volunteer-driven project so there’s no guarantee it will be picked up by someone (soon)

Hi Niels,

I was able to get a hold on Yarmo, the maintainer behind Keyoxide.
I documented the conversation’s gist in their community forum at

TL;DR: He’s not aware of any other project that supports this field and accepts your argument.
However, it’s part of the specification, even if esoteric.

I don’t know whether you have heard about it but supports it.
Hope that helps you (I only understand half of it with my current knowledge).

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.