On 2018-10-30 19:08:32, intrigeri wrote: [...]
>> Instead, I've started thinking about what a parcimonie rewrite would >> look like, one that would *not* depend on dirmngr (or, in fact, any >> specific OpenPGP implementation). If you permit, I would like to use >> this space to brainstorm such a design […] > > I'm glad you're bringing such out-of-the-box thinking in this space! > It's refreshing. I did not put much thought into it yet but at first > glance, your design makes sense to me. Thanks! :) >> All this doesn't seem that complicated to me. The tricky bit is the gate >> to keep garbage and hostile keys from going into the keyring. > > Agreed, that was my concern as well. As it turns out, while doing a review of the upcoming gpg2 update for stretch, I found out that GnuPG supports "filters" in gpg --import, through the `--import-filter` commandline option. Some key improvements of that are being backported to stretch as well. This is basically what we'd be looking at to implement this crucial component: https://manpages.debian.org/unstable/gpg/gpg.1.en.html#FILTER_EXPRESSIONS Through those, there should be a way to avoid importing secret keys and make sure the imported key material matches (one of?) the UID we are looking at. It's too bad we can't restrict on a fingerprint there... Something to think about, anyways. >> I would welcome feedback on how this could be done, or if it's just an >> incredibly stupid idea. > > I'll happily let you reuse the parcimonie name once you have it > working with good enough™ backwards compatibility with the > current interfaces. Glad to hear that. A. -- Sous un gouvernement qui emprisonne injustement, la place de l’homme juste est aussi en prison. - La désobéissance civile, Henry David Thoreau
