Werner Koch w...@gnupg.org wrote:
I think that one solution would be to have mailpile use a per-session
gpg home dir.
That is an architectural decision.
BTW, gpg-agent has this --extra-socket feature which distinguishes
between remote and local use (modulo some discussed changes). It
On 04.03.15 01:55, Hans of Guardian wrote:
In Android, you can't really have shared libraries. Apps share functionality
at a higher level (aka Activities and Services).
Qt applications can share Qt libraries [1] with an external dependency
called Ministro [2].
[1]:
On 04.03.15 18:21, Bjarni Runar Einarsson wrote:
GPGME proponents will be frustrated to hear that this knowledge actually
makes me feel much better about Mailpile's decision to wrap gpg
directly: it means I've removed two layers of abstraction between my
code and gpg! Win! Although supposedly
Hello,
I am a active use of gnupg and gnupg smart card, and unfortunately my OSS
contributions are to other projects where I do have more experience so I totally
understand any reply to my question.
Currently I use:
* gnupg
* gnupg2
* poldi
And did use:
* scute
It turns out that gnupg and
On 04.03.15 12:48, Werner Koch wrote:
that doesn't tell you about proprietary projects that have chosen not to
use GPGME. I've had clients refuse to use GPGME because of the
licensing, even under the LGPLv2.1. (Foolish, I know.) Other times
And I have had several hints that it was used
On Wed, 4 Mar 2015 00:57, h...@guardianproject.info said:
thread at this point. The bizarre Java wrapper of GPGME was not the
biggest part of the problem of the GnuPG-for-Android port, but it was
nonetheless a real problem. Sure it is possible to use GPGME with
You mean Stefan's decade old
On Wed, 4 Mar 2015 00:50, h...@guardianproject.info said:
If you are interested, you should read the details. Because you are
missing some key details here. I believe they log all PGP encrypted
communication. That would be easy for them to do. I don't know about
HTTPS.
I don't known for
On Wed, 4 Mar 2015 01:43, robe...@broadcom.com said:
I think Peter and the group already adequately answered this: If GPGME
is not providing an interface that meets Android requirements, then
look into how GPGME interfaces to GPG and emulate that interface.
FWIW, EasyPG, the GnuPG interface
On Tue, 3 Mar 2015 21:29, h...@guardianproject.info said:
* Android will kill apps when it needs to, app lifecycle is automatically
managed,
the app has no control over it, and often zero warning is given
That is the same as with Linux. Ever heard of the OOM killer?
* Android was not
On 03/03/15 14:29, Hans of Guardian wrote:
It is actually more difficult to wrap GPGME in Java than to have just
rewritten GPGME in Java. GPGME is a fine API for C/C++, it is a bad
API for other languages. You end up with an API that feels like a C
API forced into the language, e.g. Java,
It can't be that bad:
$ apt-cache rdepends libgpgme11 | wc -l 84
and the majority of problems I hear are by projects which do not use
GPGME. So I wonder a bit about your statement.
You're looking at FOSS projects that have successfully used GPGME, but
that doesn't tell you about
I don't known for sure about encrypted mail but it is known that
https connection information is recorded and stored for future
attacks:
Perhaps. Plausible, even, given storage requirements for connection
information. But storing traffic, when 99.99% of it is good --
that's ridiculous.
On Wed, 4 Mar 2015 01:45, r...@sixdemonbag.org said:
ever hacked on GnuPG has found situations where GPGME isn't a good
solution, sometimes for architectural reasons and sometimes for API
reasons and sometimes for language binding reasons and sometimes for
licensing reasons and... etc.
It
On Wed, 4 Mar 2015 10:57, r...@sixdemonbag.org said:
You're looking at FOSS projects that have successfully used GPGME, but
Sure.
that doesn't tell you about proprietary projects that have chosen not to
use GPGME. I've had clients refuse to use GPGME because of the
licensing, even under
That has not been said.
Not by you, correct. I've heard it from others.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
On 04/03/15 00:55, Hans of Guardian wrote:
[...] what I'm trying to say is that for programming environments
where GPGME does not make sense, there should be the ability to
easily make a native version of what GPGME is doing.
Couldn't this be achieved by writing a C program that, for instance,
On Tue, 3 Mar 2015 16:23, br...@minton.name said:
It breaks mailpile because gpg-agent is not session aware. A user could
be logged in locally, using mailpile, and a remote attacker could access
the web interface of that locally running mailpile instance, which since
it is talking to the
On Wed, 4 Mar 2015 10:50, r...@sixdemonbag.org said:
I don't known for sure about encrypted mail but it is known that
https connection information is recorded and stored for future
attacks:
Perhaps. Plausible, even, given storage requirements for connection
information. But storing
On Wed, 4 Mar 2015 11:10, pe...@digitalbrains.com said:
Your easily written native library
[JSON]
Program written in C
[GPGME]
That Program written in C already exists: gpgme-tool. It creates
output in XML but adding an option for JSON output should be
straightforward.
Shalom-Salam,
On Wed, 04 Mar 2015 10:50:53 +0100
Robert J. Hansen r...@sixdemonbag.org wrote:
The possibility of *every encrypted communication* being intercepted
and stored for later exploitation ... is not real, and we need to stop
treating it as such.
I remember when we used to think this about the NSA
20 matches
Mail list logo
