Mailing List Archive

On 03/07/2012 12:22 AM, Hans-Christoph Steiner wrote:
>
> I'm trying to work out how best to implement pinentry for Android. Right now I'm thinking that it would be easiest to having a 'pinentry-android' which just launches the PassphraseEntry Activity (an core Android GUI class), then have the Java code reply to the UNIX socket using assuan.

That sounds about right, but I couldn't find documentation on
PassphraseEntry to confirm that it supports the features that pinentry
should support. There is a bunch of stuff going on there (description,
quality bar, error text, prompt, button texts).

Alternatively, the pinentry activity could just implement its own
interface, as it only requires a couple of widgets.

> Another possibility is having the Java code write a temp file with the response.

Not quite as good, and not only because you commit the passphrase to
storage. You don't really want to mug around in gpg-agent to avoid
calling pinentry through libassuan. There is a bunch of stuff going on
there, including gpg-agent reporting back on the quality of the
passphrase incrementally as it is entered.

> Any examples out there to draw from? Any suggestions along these lines?

If you look at the pinentry source code, it's quite modular, and you
only need to implement a single function (that serves several purposes
though as it configures the widgets of the passphrase entry dialog
window via a structure).

There are some subtleties in how the interface is expected to behave,
but nothing too bad.

To keep the build simple, you don't have to integrate the android
pinentry into the existing pinentry autoconf build, you can just make a
standalone package. For this, copy pinentry/pinentry/pinentry.{h,c} and
use the gtk+-2 implementation as a reference (ignore curses, the old gtk
pinentry and the qt pinentries).

You might want to (or have to) ignore secmem, it's used to disable swap
space for passwords.

Thanks,
Marcus

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Mar 9, 2012, at 10:50 AM, Marcus Brinkmann wrote:

> On 03/07/2012 12:22 AM, Hans-Christoph Steiner wrote:
>>
>> I'm trying to work out how best to implement pinentry for Android. Right now I'm thinking that it would be easiest to having a 'pinentry-android' which just launches the PassphraseEntry Activity (an core Android GUI class), then have the Java code reply to the UNIX socket using assuan.
>
> That sounds about right, but I couldn't find documentation on PassphraseEntry to confirm that it supports the features that pinentry should support. There is a bunch of stuff going on there (description, quality bar, error text, prompt, button texts).
>
> Alternatively, the pinentry activity could just implement its own interface, as it only requires a couple of widgets.

Sorry, I meant Activity is a core Android GUI class, and PassphraseEntry is the class that we are writing.


>> Another possibility is having the Java code write a temp file with the response.
>
> Not quite as good, and not only because you commit the passphrase to storage. You don't really want to mug around in gpg-agent to avoid calling pinentry through libassuan. There is a bunch of stuff going on there, including gpg-agent reporting back on the quality of the passphrase incrementally as it is entered.

Yeah, duh, I realized this after sending...


>> Any examples out there to draw from? Any suggestions along these lines?
>
> If you look at the pinentry source code, it's quite modular, and you only need to implement a single function (that serves several purposes though as it configures the widgets of the passphrase entry dialog window via a structure).
>
> There are some subtleties in how the interface is expected to behave, but nothing too bad.
>
> To keep the build simple, you don't have to integrate the android pinentry into the existing pinentry autoconf build, you can just make a standalone package. For this, copy pinentry/pinentry/pinentry.{h,c} and use the gtk+-2 implementation as a reference (ignore curses, the old gtk pinentry and the qt pinentries).
>
> You might want to (or have to) ignore secmem, it's used to disable swap space for passwords.

I've been looking through the examples, those are hard to generalize from for this use case since they are all pure C and can all be linked together into a single program. What I would love to see is an example transcript of the assuan dialog between a pinentry program and gpg-agent, since I think I'll have to implement the whole pinentry lib in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.

.hc
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>
> I've been looking through the examples, those are hard to generalize from for this use case since they are all pure C and can all be linked together into a single program. What I would love to see is an example transcript of the assuan dialog between a pinentry program and gpg-agent, since I think I'll have to implement the whole pinentry lib in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>

It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
that than to wrap libassuan or reimplement libassuan in Java.

gpg-agent can be configured to log its assuan communication with pinentry.

Thanks,
Marcus

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 03/09/2012 01:12 PM, Marcus Brinkmann wrote:
> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>>
>> I've been looking through the examples, those are hard to generalize
>> from for this use case since they are all pure C and can all be linked
>> together into a single program. What I would love to see is an
>> example transcript of the assuan dialog between a pinentry program and
>> gpg-agent, since I think I'll have to implement the whole pinentry lib
>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>>
>
> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
> that than to wrap libassuan or reimplement libassuan in Java.
>
> gpg-agent can be configured to log its assuan communication with pinentry.

I forgot to mention, we're going to be using gpgme in this. It looks
like gpgme somehow handles the pinentry stuff with callbacks, or am I
reading it wrong? If we are using gpgme, do we still need a custom
pinentry?

.hc

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote:
>
>
> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote:
>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>>>
>>> I've been looking through the examples, those are hard to generalize
>>> from for this use case since they are all pure C and can all be linked
>>> together into a single program. What I would love to see is an
>>> example transcript of the assuan dialog between a pinentry program and
>>> gpg-agent, since I think I'll have to implement the whole pinentry lib
>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>>>
>>
>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
>> that than to wrap libassuan or reimplement libassuan in Java.
>>
>> gpg-agent can be configured to log its assuan communication with pinentry.
>
> I forgot to mention, we're going to be using gpgme in this. It looks
> like gpgme somehow handles the pinentry stuff with callbacks, or am I
> reading it wrong? If we are using gpgme, do we still need a custom
> pinentry?

The callbacks are "old school" and not functional for gpg2 with
gpg-agent. :)

So a custom pinentry is indeed needed, and you don't need to set a gpgme
passphrase callback (it would never be called).

Thanks for the list of issues, btw, it's a big help as the mailing list
threads were getting a tiny bit unwieldy.

Thanks,
Marcus



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 03/10/2012 08:56 AM, Marcus Brinkmann wrote:
> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote:
>>
>>
>> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote:
>>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>>>>
>>>> I've been looking through the examples, those are hard to generalize
>>>> from for this use case since they are all pure C and can all be linked
>>>> together into a single program. What I would love to see is an
>>>> example transcript of the assuan dialog between a pinentry program and
>>>> gpg-agent, since I think I'll have to implement the whole pinentry lib
>>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>>>>
>>>
>>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
>>> that than to wrap libassuan or reimplement libassuan in Java.
>>>
>>> gpg-agent can be configured to log its assuan communication with
>>> pinentry.
>>
>> I forgot to mention, we're going to be using gpgme in this. It looks
>> like gpgme somehow handle
>
> Thanks,
> Marcus
>
>
s the pinentry stuff with callbacks, or am I
>> reading it wrong? If we are using gpgme, do we still need a custom
>> pinentry?
>
> The callbacks are "old school" and not functional for gpg2 with
> gpg-agent. :)
>
> So a custom pinentry is indeed needed, and you don't need to set a gpgme
> passphrase callback (it would never be called).
>
> Thanks for the list of issues, btw, it's a big help as the mailing list
> threads were getting a tiny bit unwieldy.

I'm back on this and still not quite seeing how to do it. From what
I've seen, it seems that gpg-agent executes pinentry, then communicates
with it via stdin/stdout. This is not possible in Android because you
cannot directly launch a GUI program in Android from the terminal.

The only way I've found to start an Android GUI screen from the terminal
is to launch an Activity (which is a Java Class representing a GUI
screen) using the 'am start' command. Its not blocking, and there is no
stdin/stdout to attach to.

What I think need to happen is that gpg-agent calls "am start
PassphraseActivity", then PassphraseActivity starts and connects to the
gpg-agent UNIX socket and does its communication there. It would also
be possible to have pinentry create its own UNIX socket and point
gpg-agent to it.

I have no idea how to do that, all of the existing pinentry programs
seem to work the exact same way. Any pointers?

.hc

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hans-Christoph Steiner:
>
>
> On 03/10/2012 08:56 AM, Marcus Brinkmann wrote:
>> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote:
>>>
>>>
>>> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote:
>>>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>>>>>
>>>>> I've been looking through the examples, those are hard to generalize
>>>>> from for this use case since they are all pure C and can all be linked
>>>>> together into a single program. What I would love to see is an
>>>>> example transcript of the assuan dialog between a pinentry program and
>>>>> gpg-agent, since I think I'll have to implement the whole pinentry lib
>>>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>>>>>
>>>>
>>>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
>>>> that than to wrap libassuan or reimplement libassuan in Java.
>>>>
>>>> gpg-agent can be configured to log its assuan communication with
>>>> pinentry.
>>>
>>> I forgot to mention, we're going to be using gpgme in this. It looks
>>> like gpgme somehow handle
>>
>> Thanks,
>> Marcus
>>
>>
> s the pinentry stuff with callbacks, or am I
>>> reading it wrong? If we are using gpgme, do we still need a custom
>>> pinentry?
>>
>> The callbacks are "old school" and not functional for gpg2 with
>> gpg-agent. :)
>>
>> So a custom pinentry is indeed needed, and you don't need to set a gpgme
>> passphrase callback (it would never be called).
>>
>> Thanks for the list of issues, btw, it's a big help as the mailing list
>> threads were getting a tiny bit unwieldy.
>
> I'm back on this and still not quite seeing how to do it. From what
> I've seen, it seems that gpg-agent executes pinentry, then communicates
> with it via stdin/stdout. This is not possible in Android because you
> cannot directly launch a GUI program in Android from the terminal.
>
> The only way I've found to start an Android GUI screen from the terminal
> is to launch an Activity (which is a Java Class representing a GUI
> screen) using the 'am start' command. Its not blocking, and there is no
> stdin/stdout to attach to.
>

A thought I had when I looked at this was to create an 'am start'
wrapper program, 'pinentry-android' for example.

This program would:

1. launch the activity (non-blocking)
2. block, as other pinentry programs do
3. communicate with the activity somehow (maybe suingsome shared memory,
mmap)
4. communicate with gpg-agent via stdin/out

#3 is the trickiest bit I think, but this method would work well if
non-blocking pineentry programs that communicate over the gpg-agent
socket aren't possible.

~abel

On 09/19/2012 12:30 PM, Abel Luck wrote:
> Hans-Christoph Steiner:
>>
>>
>> On 03/10/2012 08:56 AM, Marcus Brinkmann wrote:
>>> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote:
>>>>
>>>>
>>>> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote:
>>>>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>> I've been looking through the examples, those are hard to generalize
>>>>>> from for this use case since they are all pure C and can all be linked
>>>>>> together into a single program. What I would love to see is an
>>>>>> example transcript of the assuan dialog between a pinentry program and
>>>>>> gpg-agent, since I think I'll have to implement the whole pinentry lib
>>>>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java.
>>>>>>
>>>>>
>>>>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap
>>>>> that than to wrap libassuan or reimplement libassuan in Java.
>>>>>
>>>>> gpg-agent can be configured to log its assuan communication with
>>>>> pinentry.
>>>>
>>>> I forgot to mention, we're going to be using gpgme in this. It looks
>>>> like gpgme somehow handle
>>>
>>> Thanks,
>>> Marcus
>>>
>>>
>> s the pinentry stuff with callbacks, or am I
>>>> reading it wrong? If we are using gpgme, do we still need a custom
>>>> pinentry?
>>>
>>> The callbacks are "old school" and not functional for gpg2 with
>>> gpg-agent. :)
>>>
>>> So a custom pinentry is indeed needed, and you don't need to set a gpgme
>>> passphrase callback (it would never be called).
>>>
>>> Thanks for the list of issues, btw, it's a big help as the mailing list
>>> threads were getting a tiny bit unwieldy.
>>
>> I'm back on this and still not quite seeing how to do it. From what
>> I've seen, it seems that gpg-agent executes pinentry, then communicates
>> with it via stdin/stdout. This is not possible in Android because you
>> cannot directly launch a GUI program in Android from the terminal.
>>
>> The only way I've found to start an Android GUI screen from the terminal
>> is to launch an Activity (which is a Java Class representing a GUI
>> screen) using the 'am start' command. Its not blocking, and there is no
>> stdin/stdout to attach to.
>>
>
> A thought I had when I looked at this was to create an 'am start'
> wrapper program, 'pinentry-android' for example.
>
> This program would:
>
> 1. launch the activity (non-blocking)
> 2. block, as other pinentry programs do
> 3. communicate with the activity somehow (maybe suingsome shared memory,
> mmap)
> 4. communicate with gpg-agent via stdin/out
>
> #3 is the trickiest bit I think, but this method would work well if
> non-blocking pineentry programs that communicate over the gpg-agent
> socket aren't possible.

Abel and I discussed this on IRC, so I'm posting it here to get feedback
on the best approach here:

_hc: The thing is that all of the pinentry impls that I found use the
pinentry 'lib'
_hc: that pinentry lib makes it really easy to write a pinentry that is
launched via gpg-agent which communicates via stdin/stdout
_hc: the pinentry lib handles all of the conversation in the assuan protocol
_hc: and it seems that conversation is pretty elaborate
_hc: so we'll want to try to include the pinentry 'lib'
_hc: I guess the Activity could launch its own pinentry process and
intercept stdin/stdout
_hc: then that needs to be ferried back somehow, I guess that's your #3
14:55
abeluck: hm, thats not quite what i had in mind
abeluck: the CLI program gpg-agent would launch uses pinentry lib
abeluck: and is a middleman between gpg and the Activity
_hc: ok, so pinentry-android does exec("am start
info.guardianproject.gpg.PassphraseActivity);
abeluck: gpg-agent <--pinentry lib--> pinentry-android-blocking
<--mmap/other socket--> Java Activity
abeluck: yes
abeluck: yes, it starts the activity
abeluck: and bridges communication between gpg-agent
abeluck: and the activity
abeluck: using mmap/or socket to talk to the activity
abeluck: and using stdin/out to talk to gpg
abeluck: or s/stdin\out/pineentry-lib/ if necessary
_hc: right, ok
_hc: I guess pinentry-android makes it own UNIX socket, which the
PinEntryActivity connects to once it starts
abeluck: yes
_hc: ok, this is seeming doable
abeluck: its pretty elegant really
_hc: hmm, elegant considering the options
abeluck: indeed
_hc: if android just let you write a cmd line program that showed an
Activity, this would be done
abeluck: the savings there doesnt seem any more difficult than doing it
this way
abeluck: 'am start' is effectively that
_hc: it would be nice if gpg-agent could just call 'am start ...', then
the PinEntryActivity could just connect directly to the gpg-agent UNIX
socket and do everything there.
abeluck: the fact you have to communicate asyncly isn't a big deal imo
_hc: async isn't the problem, its adding another socket
_hc: just seems messy
abeluck: yea, that would be nice, but infeasible atm
_hc: but the only feasible approach right now

.hc

On Wed, 19 Sep 2012 04:23, hans@guardianproject.info said:

> I'm back on this and still not quite seeing how to do it. From what
> I've seen, it seems that gpg-agent executes pinentry, then communicates
> with it via stdin/stdout. This is not possible in Android because you

Right. Pretty standard thing.

> cannot directly launch a GUI program in Android from the terminal.

What is the reason? It is kind of funny that the whole GnuPG system
works nicely on Windows Mobile 6.x (the old one) but you can't make it
work on a free software Linux Platform.

> I have no idea how to do that, all of the existing pinentry programs
> seem to work the exact same way. Any pointers?

I would first investigate how to start a GUI application i the first
place (without the Java crap). If you really can't find a solution the
common workaround for such problems are daemon: Start a daemonized
pinentry version and use a stub pinentry program which is called by
gpg-agent and then communicates with the pinentry-daemon via
whatever-mechanism you like.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 09/24/2012 06:25 AM, Werner Koch wrote:
> On Wed, 19 Sep 2012 04:23, hans@guardianproject.info said:
>
>> I'm back on this and still not quite seeing how to do it. From what
>> I've seen, it seems that gpg-agent executes pinentry, then communicates
>> with it via stdin/stdout. This is not possible in Android because you
>
> Right. Pretty standard thing.
>
>> cannot directly launch a GUI program in Android from the terminal.
>
> What is the reason? It is kind of funny that the whole GnuPG system
> works nicely on Windows Mobile 6.x (the old one) but you can't make it
> work on a free software Linux Platform.

>> I have no idea how to do that, all of the existing pinentry programs
>> seem to work the exact same way. Any pointers?
>
> I would first investigate how to start a GUI application i the first
> place (without the Java crap). If you really can't find a solution the
> common workaround for such problems are daemon: Start a daemonized
> pinentry version and use a stub pinentry program which is called by
> gpg-agent and then communicates with the pinentry-daemon via
> whatever-mechanism you like.

Android is really quite a different operating system from GNU/Linux,
*BSD, and even Windows. I know nothing about Windows Mobile, so I can't
speak to that. Yes, there is a Linux kernel and a super minimal
pseudo-UNIX environment, its really not UNIX and is missing lots of
basic things, like command line programs launching GUIs.

The only way you launch a GUI program in Android is to send a message,
known as an Intent requesting a certain generic action or specific
Activity. That message goes to 'system_server', which requests 'zygote'
to fork off the process containing the right Activity. 'system_server'
then waits for the new process to contact 'system_server' via IPC, then
requests the right Activity from the process. We can send the Intent,
but we can't control the starting of the process.

So we could go with the idea Abel outlined, which sounds like what you
are proposing. I just think that the ideal solution would be having
gpg-agent launch the GUI Activity using "am start", then that GUI
Activity could talk directly to the gpg-agent UNIX socket, and that
would make the whole setup simpler. If that is not feasible, I'm OK
with going with the 'pinentry' that talks with the GUI Activity via its
own UNIX socket.

.hc

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Mon, 24 Sep 2012 23:35, hans@guardianproject.info said:

> then waits for the new process to contact 'system_server' via IPC, then
> requests the right Activity from the process. We can send the Intent,
> but we can't control the starting of the process.

Okay, so a simple two way communication is not possible.

> are proposing. I just think that the ideal solution would be having
> gpg-agent launch the GUI Activity using "am start", then that GUI
> Activity could talk directly to the gpg-agent UNIX socket, and that

We use a simple stdin/stdout server for the pinentry because it reduces
the complexity in gpg-agent. The pinentry can't use the
~/.gnupg/S.gpg-agent socket because that one is for the client's (gpg)
communication with the agent. If we would use that socket also for
pinentry communication, we would need to synchronize the actions of two
clients (the regular client and the pinentry). That defeats the idea of
having a simple and easy to audit communication with gpg-agent.

Using an extra socket for pinentry would be possible but this also adds
more complexity. Thus I am very in favor of having a wrapper pinentry
to mediate between gpg-agent and an Android based pinentry. I hope
there is no limit on the number of processes on Android like we have on
WindowsCE.

Adding such a daemonized version to the pinentry package and thus
re-using some of the pinentry logic is no problem. We don't require any
legal BS for pinentry.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Werner Koch:
> On Mon, 24 Sep 2012 23:35, hans@guardianproject.info said:
>
>> then waits for the new process to contact 'system_server' via IPC, then
>> requests the right Activity from the process. We can send the Intent,
>> but we can't control the starting of the process.
>
> Okay, so a simple two way communication is not possible.
>
>> are proposing. I just think that the ideal solution would be having
>> gpg-agent launch the GUI Activity using "am start", then that GUI
>> Activity could talk directly to the gpg-agent UNIX socket, and that
>
> We use a simple stdin/stdout server for the pinentry because it reduces
> the complexity in gpg-agent. The pinentry can't use the
> ~/.gnupg/S.gpg-agent socket because that one is for the client's (gpg)
> communication with the agent. If we would use that socket also for
> pinentry communication, we would need to synchronize the actions of two
> clients (the regular client and the pinentry). That defeats the idea of
> having a simple and easy to audit communication with gpg-agent.
>
> Using an extra socket for pinentry would be possible but this also adds
> more complexity. Thus I am very in favor of having a wrapper pinentry
> to mediate between gpg-agent and an Android based pinentry. I hope
> there is no limit on the number of processes on Android like we have on
> WindowsCE.
>
> Adding such a daemonized version to the pinentry package and thus
> re-using some of the pinentry logic is no problem. We don't require any
> legal BS for pinentry.
>
>
> Salam-Shalom,
>
> Werner
>

Hi Werner,

Abel from Guardian Project here.

I'm taking the lead on this task (pinentry on Android) for now, and I've
a few questions I hope you can help me with.

A quick recap:

1. Android has no X server
2. It is *impossible* to launch a GUI app from the CLI and communicate
synchronously
3. It is *possible* to launch a GUI app in a non-blocking fashion from
the CLI
4. We can communicate w/ the gui through a unix domain socket

The goal then is to create a pinentry that launches a non-blocking gui
(simple CLI command), then communicates over a unix domain socket with
the Android app that interacts with the user.

So, with that in mind I've been investigating the pinentry related
gpg-agent options, and I have a few questions.

How relevant are the following options to the above plan?
--keep-tty
--no-grab
--allow-loopback-pinentry

Could you elaborate more on the loopback mode, I don't quite understand
its function from the documents.

It seems this would be more feasible to implement as a modifier version
of pinentry/pinentry[-curses].[c,h] Does that sound reasonable, or do
you suggest a different codebase to use as a starting point?

Thanks,
Abel

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi!

On Sun, 11 Nov 2012 21:15, abel@guardianproject.info said:
> The goal then is to create a pinentry that launches a non-blocking gui
> (simple CLI command), then communicates over a unix domain socket with
> the Android app that interacts with the user.

very good. I believe that is the best option for now. If we later
notice that we need to change something to save on certain resources, we
can re-consider this. It is an internal API and thus easy to replace.

> How relevant are the following options to the above plan?
> --keep-tty

That is X server specific. You can ignore it.

> --no-grab

Does not make sense. It mostly a debugging option for X. The grab
keyboard and mouse thing should be replaced by Android's way of
protecting PIN/passphrase widgets.

> --allow-loopback-pinentry

This is quite new and designed to be used by server applications. In
fact. gpg2.1 has no support for it now. The idea is that an application
using gpg-agent for passphrase entry, private key, or card operations
can avoid the use of a pinentry and instead directly send the passphrase
(via a callback mechanism). For example a web mail server could use
this feature instead of resorting to the pinentry-wrapper hack.

> It seems this would be more feasible to implement as a modifier version
> of pinentry/pinentry[-curses].[c,h] Does that sound reasonable, or do
> you suggest a different codebase to use as a starting point?

Please use that code base and create a branch during the development
phase.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel