Feature #218
GPG for Informacam (pinentry, what else?)
| Status: | New | Start date: | 07/24/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | harlo | % Done: | 0% | |
| Category: | - | |||
| Target version: | Back Burner | |||
| Component: |
Description
We need to finish up the current GPG binary version for InformaCam.
I know we need "pinentry" support, but what else?
I have assigned this to Abel, but everyone please join in and reply so we can flush this out.
what are the issue: gpg-agent? packaging? speed? size?
History
#1 Updated by abeluck over 5 years ago
The gpgme library is breaking (platform specific threading issues it seems like). I spent most of yesterday working on this.
Though, for most of what Harlo needs (afaik) we could get by with command line wrapping, which seems to fully work. Since this has high priority, should we focus on meeting Harlo's needs with just this CLI wrapper?
#2 Updated by abeluck over 5 years ago
Harlo, could you please supply a list of gpg actions you need to be able to do?
e.g.:- sign messages
- import/export
- decrypt/encrypt arbitrary data
#3 Updated by abeluck over 5 years ago
- Assignee changed from abeluck to harlo
#4 Updated by harlo over 5 years ago
Certainly:
Abel, the lib could definitely be a CLI wrapper; I would like that very much.
Here's a short list of actions I'll need, which I might add to at a later time:- encrypt/decrypt (should be able to directly accept data streams of arbitrary length; not only files)
- parse .asc files for keys and metadata (IE userIds, expiry dates, etc.)
- sign/verify messages
- SECURE PINENTRY for decrypting things!
I have questions about key management: so far, I'm storing keys in an encrypted database and running them through boucycastle api whenever I need them. Would our gpg build make this processes safer and more efficient? What should that workflow look like?
Thanks,
Harlo
#5 Updated by harlo over 5 years ago
Just talked to Nathan about this-- to clarify:
it would be very nice if our gpg build could fulfill the following use case:
read a file's datastream directly from IOCipher, without ever having to be burnt to a flat file somewhere on the flash drive.
do you think this is possible?
#6 Updated by abeluck over 5 years ago
harlo wrote:
Just talked to Nathan about this-- to clarify:
it would be very nice if our gpg build could fulfill the following use case:
read a file's datastream directly from IOCipher, without ever having to be burnt to a flat file somewhere on the flash drive.do you think this is possible?
I've created IOCipher Issue #226 for this.. I've a couple questions if we could discuss it there please ? :)
#7 Updated by harlo almost 5 years ago
- Priority changed from High to Normal
#8 Updated by hans almost 5 years ago
the only practical way to ship GnuPG-for-Android is as a standalone app. Its just too complicated and large to think about embedding in other apps at this point. So we should be focusing on getting all the Intents and ContentProviders that you need working in GnuPG-for-Android.
#9 Updated by n8fr8 almost 5 years ago
- Target version changed from InformaCam - Public Preview v1 to Back Burner