Integrate pinentry-mac into pinentry

Hans-Christoph Steiner hans at guardianproject.info
Wed Feb 25 15:28:09 CET 2015



Werner Koch:
> On Sun, 22 Feb 2015 16:13, patrick at enigmail.net said:
> 
>> That's a _very_ good idea!
> 
> Seconded.
> 
>> I'd say that this should be OK. Automake should probably simply be
>> able to determine that it's compiling for OS X and then use the XCode
>> project.
> 
> Nope.  That that is a bad idea.  The build system is based on standard
> Makefiles generated via automake and autoconf and I am strongly against
> any other build systems.  We have this discussion every few years
> related to Windows and I do not want to repeat this.  It is important to
> be able to cross-build everything using a free (and audit-able platform).
> Form my understanding Xcode is a non-text proprietary thing like Visual
> Studio projects for Windows.
> 
> If there is a sound reason why _autoconf_ can't work on that platform, a
> dedicated config file might be acceptable (cf. the VMS port).  But for a
> BSD based OS I can's see a compelling reason.
> 
>>> 4. pinentry-mac allows the calling app to define a custom message 
>>> to show. This is implemented using PINENTRY_USER_DATA. We allow 
>>> placeholders like %KEYID and %USERID. To fill the placeholders, we
>>>  parse the description from pinentry. This works in the most
>>> cases. The reason for this feature is, to allow some more
>>> informative and readable messages. e.g. We can tell the user for
>>> which email/file, he enters the passphrase. What do you think about
>>> that? Is this a desirable feature for pinentry?
>>
>> I think this is a desirable feature of pinentry in general. Other
>> tools could profit from it as well.
> 
> This violates the security barrier of gpg-agent.  Any application could
> trick a user into doing things he does not want.  For keys controlled by
> gpg-agent the shown key identification should come from gpg-agent
> without any user overridable string.
> 
> It is a different thing to allow additional information to be displayed.
> If there is a need for it it can be added but it should be specified in
> the gpg-agent/pinentry protocol.

I'm not sure this provides any real protection, and it does make for a worse
UI, which generally translated into worse security.  A malicious app could
just make a custom pinentry app that looks however it wants, and basically
make a phishing interface that also interacts with gpg-agent.  If you don't
trust your locally installed apps, there is not much you can do about it in
the software.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81



More information about the Gnupg-devel mailing list