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 o
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.
I
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
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 interfac
> 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 ridiculou
> 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 pr
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,
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 instanc
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 stor
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 unde
> 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 Wed, 4 Mar 2015 11:10, pe...@digitalbrains.com said:
>
> [JSON]
>
> [GPGME]
That already exists: gpgme-tool. It creates
output in XML but adding an option for JSON output should be
straightforward.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz
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, 04 Mar 2015 10:50:53 +0100
"Robert J. Hansen" 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 or GCHQ taking i
Werner Koch 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 woul
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 gnu
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]: http://doc.qt.io/qtcreato
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 supposed
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
20 matches
Mail list logo
