Hi,
I am going to have a lightning talk at FOSDEM about EasyGnuPG:
- https://fosdem.org/2018/schedule/event/easy_gnupg/
- https://slides.com/dashohoxha/easy-gnupg
In case somebody will be at FOSDEM, I invite you to participate.
Regards,
Dashamir
On Thu, Jun 2, 2016 at 10:54 AM, Robert J. Hansen
wrote:
> > There is a new version of egpg, based on GnuPG-2.1.11
>
> ... which apparently has not fixed the "it will nuke your hard drive if
> you have a certain environment variable set" problem I pointed out a
> month ago.
>
Apparently? I remem
Is this really the right place for such announcements?
--
Jonas Hedman
XMPP:n...@nstr.se
PGP Key: 0x5c3989e0616bb08c
Fingerprint: 8F72 C5BE AAFA B4BA 8F46 9185 5C39 89E0 616B B08C
signature.asc
Description: Digital signature
___
Gnupg-u
> There is a new version of egpg, based on GnuPG-2.1.11
... which apparently has not fixed the "it will nuke your hard drive if
you have a certain environment variable set" problem I pointed out a
month ago.
I am not kidding. Use at your own risk.
___
compile the latest version of GnuPG, in order
to use EasyGnuPG. It makes more sense to use what is already
available on Ubuntu out-of-the-box (and this is what users expect).
The main changes are:
- Adapting scripts to match the version 2.1.11.
- Added the command key2dongle (besides key split
Hi,
I have made another release of EasyGnuPG.
Things that have changed since the last time that I posted here are:
- Small fixes and improvements (some of which were suggested here).
- Finished automated testing scripts [1].
- Bash autocompletion [2].
- Making the egpg key-ring the default
On Wed, 30 Mar 2016 10:05, b...@pagekite.net said:
> FYI, on the latest Ubuntu (15.10), that command does not work:
You need 2.1 of course .-)
> https://www.gnupg.org/documentation/manuals/gpgme/UI-Server-Protocol.html,
> it looks like that protocol is only suitable for localhost
> operations, i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Werner,
Thanks for the reply!
Werner Koch wrote:
> > This is one of the complaints/wishes us Mailpile folks had, for
> > some sort of stable socket/stdio-based programmatic API for
> > talking to GnuPG. This sort of interface would make it much m
On Fri, 25 Mar 2016 15:32, b...@pagekite.net said:
> This is a chicken-and-egg problem. Until the tool is made widely
> available, people will not use it - most people don't even know
It is actually a tool to help with gpgme development. However, Ben
Kibbey seems to be using it for some of his s
On 29.03.2016 05:53, Daniel Villarreal wrote:
>> Depending ... the gnupg 2.x executable is still called 'gpg'. I
>> guess it depends on if the distributor wants to keep easy backwards
>> compatibility. On archlinux,.. only one gnupg package ... The
>> executable is called gpg...Regards, Viktor
To
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>> [I] use gpg2 on the [CL] whereas [doco] seems to show gpg.
>> https://gnupg.org/gph/en/manual.html#AEN111
>
> Depending ... the gnupg 2.x executable is still called 'gpg'. I
> guess it depends on if the distributor wants to keep easy backwards
On 28.03.2016 19:16, Daniel Villarreal wrote:
> Should we not strive to use gnupg v2x ? I always try to use gpg2 on
> the command-line, whereas documentation seems to show gpg.
>
> example...
> Encrypting and decrypting documents
> https://gnupg.org/gph/en/manual.html#AEN111
Depending on the syst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/03/16 07:56 AM, keith wrote:
...
> I'm not proud and I am not going to get upset if you decide I am
> the wrong person for the job. Offer's there anyway. Keith
...
Keith,
Don't give up, just try to keep learning. No one is born knowing this
st
There you go. I've already demonstrated how rubbish I am by using my
primary e-mail address rather than my 'registered' one to respond.
Either you will throw your hands up in despair or think 'If this idiot
can be taught to the extent that he can explain things to other
idiots...'
I'm not proud a
I'm a noob. I'm drunk. I'll try. What do you want?
..ulterior motive is I might learn.
Keith
On Fri, 2016-03-25 at 20:50 +, listo factor wrote:
> On 03/22/2016 09:21 PM, Peter Lebbing wrote:
>
> > ... writing good documentation is hard, very hard. In
> > fact, it turned out to be easier to
On Sat, Mar 26, 2016 at 7:51 AM, listo factor wrote:
> On 03/26/2016 03:55 AM, Dashamir Hoxha wrote:
>
>> On Fri, Mar 25, 2016 at 9:50 PM, listo factor
>> wrote:
>>
> >> ... The efforts which concentrate on making it easy might
> >> indeed increase the number of people that use it, but at the
>
On 03/26/2016 03:55 AM, Dashamir Hoxha wrote:
On Fri, Mar 25, 2016 at 9:50 PM, listo factor wrote:
>> ... The efforts which concentrate on making it easy might
>> indeed increase the number of people that use it, but at the
>> expense...
So, maybe they will be safer if they don't use GPG at a
On Fri, Mar 25, 2016 at 9:50 PM, listo factor wrote:
>
> To perform tasks that GPG is designed to accomplish in a safe manner
> is *very, very hard*, and even the best documentation could not change
> that fact. The efforts which concentrate on making it easy might
> indeed increase the number of
On 03/22/2016 09:21 PM, Peter Lebbing wrote:
... writing good documentation is hard, very hard. In
fact, it turned out to be easier to write academical papers on why it is so
difficult to make crypto easy to use than to write documentation that makes
crypto easy to use.
It ~is~ hard, but only
On Fri, Mar 25, 2016 at 04:37:59AM -0400, Robert J. Hansen wrote:
> > And that doesn't even get into the issues involved with selecting a
> > format for producing the documentation in. Consider the following:
>
> Preach it, Brother Ben.
:-D
> And it's not just about formats, it's also about tar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello!
Werner Koch wrote:
> On Wed, 23 Mar 2016 18:48, d...@fifthhorseman.net said:
>
> > I'm entirely open to packaging gpgme-tool separately from the -dev
> > package, if there is a clear and compelling argument for it.
>
> As of now it is not re
On Fri, Mar 25, 2016 at 10:21 AM, Ben McGinnes wrote:
>
> Primary keys MUST be C-usage and MAY be SCA usage, by default they're
> SC, but simply creating an S-usage subkey moves the S function to the
> subkey (by default GPG will select the newest subkey with a given
> capability to perform that f
On Tue, Mar 22, 2016 at 10:56:27PM +, Andrew Gallagher wrote:
>
> IMHO the only thing to do with E-usage primary keys is revoke them
> and start again from scratch. The only reason they are even still
> allowed in GPG is for backwards compatibility, right...?
Right.
Primary keys MUST be C-us
> And that doesn't even get into the issues involved with selecting a
> format for producing the documentation in. Consider the following:
Preach it, Brother Ben. And it's not just about formats, it's also
about targets, because each of these formats works best with different
targets. Do we wan
On Tue, Mar 22, 2016 at 10:21:31PM +0100, Peter Lebbing wrote:
> On 22/03/16 20:53, Dashamir Hoxha wrote:
>
> > the docs are like a maze and not clearly structured
>
> A reasonably fair criticism... writing good documentation is hard,
> very hard. In fact, it turned out to be easier to write acad
On Wed, 23 Mar 2016 18:48, d...@fifthhorseman.net said:
> I'm entirely open to packaging gpgme-tool separately from the -dev
> package, if there is a clear and compelling argument for it.
As of now it is not really stable and as long as there are no well known
users I do not think that a separate
On Wed, Mar 23, 2016 at 6:48 PM, Daniel Kahn Gillmor
wrote:
>
> > In this case, "gpgme-tool" should be packaged on its own, not inside the
> > package "*libgpgme11-dev*".
> > I am refering to this message:
> > https://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029206.html
>
> I'm entirely
On 23/03/16 19:30, Daniel Kahn Gillmor wrote:
> the monkeysphere project encourages the creation of on-disk
> authentication subkeys. While that may be uncommon, i don't think it's
> "really uncommon".
Fair enough :). Things like monkeysphere are exactly where it makes
sense. I have no idea how m
On Wed 2016-03-23 13:42:11 -0400, Peter Lebbing wrote:
> Yes, an on-disk authentication subkey seems really uncommon to me. I would
> completely omit an A subkey.
the monkeysphere project encourages the creation of on-disk
authentication subkeys. While that may be uncommon, i don't think it's
"re
On Tue 2016-03-22 15:11:23 -0400, Dashamir Hoxha wrote:
> On Tue, Mar 22, 2016 at 4:29 PM, Werner Koch wrote:
>
>> FWIW: We even consider to extend gpgme-tool to be a Native Messaging
>> Server for Browsers.
>
> In this case, "gpgme-tool" should be packaged on its own, not inside the
> package "*l
On 23/03/16 16:35, Andrew Gallagher wrote:
> [...] and since you can always enforce use of your A,S subkeys (unlike
> E, where it's out of your hands) this shouldn't cause you any issues if you
> change your mind.
I haven't tried it (it's more work than most "let's try this" things), but I
think i
> On 23 Mar 2016, at 07:27, Dashamir Hoxha wrote:
>
> Is it OK to have a signing primary key? Is it useful?
A signing primary key is fine. I prefer making single-use subkeys for each of
A,E,S but only the E subkey is strictly necessary. You can always generate the
A,S subkeys later if you fin
On Tue, 22 Mar 2016 20:35, dashoho...@gmail.com said:
> I still think that the colons format is a bit difficult to process and not
The colon format difficult? I can do almost everything on the command
line. awk(1) is your friend.
> not as easy as that. For example there is also --passphrase-fd
Viktor Dick:
> In this case, I think you have got a point. I think the gnupg default of
> 'expires: never' is not the best solution, since people who just try it
> out might end up with a public key published to keyservers where they
> have lost the private key.
[...]
> But I still think it might b
On Wed, Mar 23, 2016 at 6:04 AM, Viktor Dick wrote:
>
> Then there is the problem that the user might not notice that his key is
> expired. I remember vagely spending a day trying to find the error until
> I noticed that my subkeys were expired. But this might have been a
> problem with Enigmail,
On Tue, Mar 22, 2016 at 11:56 PM, Andrew Gallagher
wrote:
> On 22 Mar 2016, at 22:10, Dashamir Hoxha wrote:
>
> On Tue, Mar 22, 2016 at 10:21 PM, Peter Lebbing
> wrote:
>>
>> And why is your primary key capable of encryption? One of the reasons for
>> subkeys is so you don't have to use the sam
On 22.03.2016 23:10, Dashamir Hoxha wrote:
> You got this wrong. It does not enforce 1 month expiry. Right after
> creating the key you can change its expiry to 10y, if you wish. But if
> you say nothing, after 1m you will have to renew it (if you still
> remember the passphrase). This is like a sa
On Tue, Mar 22, 2016 at 11:25 PM, Peter Lebbing
wrote:
>
> > What is wrong with that? As long as there is a subkey for encryption,
> > gpg will use the subkey for encryption, even if the primary key is
> > capable of encryption.
>
> That is not up to you! It's up to your peers, or your attackers.
On 22 Mar 2016, at 22:10, Dashamir Hoxha wrote:
>> On Tue, Mar 22, 2016 at 10:21 PM, Peter Lebbing
>> wrote:
>> And why is your primary key capable of encryption? One of the reasons for
>> subkeys is so you don't have to use the same key material for both encryption
>> and signing, since this o
On 22/03/16 15:31, Ben McGinnes wrote:
> What, you mean like "gpg2 --use-embedded-filename"?
No, I meant what it already does, I had it wrong in my head and should
have tried it. I mean that it would be nice if the following were
equivalent:
$ gpg2 -r de500b3e -e file.ext
$ gpg2 -o file.ext.gpg -
On 22/03/16 23:10, Dashamir Hoxha wrote:
> You got this wrong. It does not enforce 1 month expiry. Right after
> creating the key you can change its expiry to 10y, if you wish. But if
> you say nothing, after 1m you will have to renew it (if you still
> remember the passphrase). This is like a safe
Sorry to butt in here but in my first post to the list I mentioned that
I was attempting to use FreePascal/Lazarus to interface with GPG via the
command line but whilst I had managed to get it working with OpenSSL
attempting the same methodology on GPG resulted in a 'hang'.
Now I realise I am a no
On Tue, Mar 22, 2016 at 10:21 PM, Peter Lebbing
wrote:
>
> Your one month expiry thing is not well thought through. Not only will the
> owner
> need to re-sign and redistribute every damn month, but all his contacts
> will
> pretty much always need tor refresh the key before they can use it, /eve
First of all, let me say that I regret that I didn't start my mail with feedback
on your project on a positive note. I think it's good that people spend effort
trying to make things more usable, and I applaud you for it. It would have been
a lot nicer of me to start out with that. There's no excuse
On Tue, Mar 22, 2016 at 3:41 PM, Ben McGinnes wrote:
>
> You might try experimenting with gpgme-tool then, it's one of the
> undocumented/self-documented extras which comes with GPGME. It
> provides a socket interface with which you can interact with portions
> of the GPGME functions, including m
On Tue, Mar 22, 2016 at 10:54 AM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:
> I totally agree, Dashamir I really think you should focus on what you
> think is hard in gnupg? And why?
> Are you sure a new program (and not a simple patch) is the best answer?
>
> At the moment you are sho
On Tue, Mar 22, 2016 at 2:28 PM, Werner Koch wrote:
>
> There are two simple things you need to remember when using gpg in a
> script:
>
> 1. --batch to avoid all interaction.
>
> 2. --with-colons to get a well defined output format. That format is
> not good for humans, though.
>
> Wel
On Tue, Mar 22, 2016 at 2:55 PM, Andrew Gallagher
wrote:
>
> For that we need to be encouraging hackers and tinkerers to experiment
> with novel interfaces; and this is best done by giving them the software
> equivalent of Lego rather than Meccano.
>
I find the Lego analogy very suitable. This is
On Tue, Mar 22, 2016 at 4:29 PM, Werner Koch wrote:
> On Tue, 22 Mar 2016 15:41, b...@adversary.org said:
>
> > provides a socket interface with which you can interact with portions
> > of the GPGME functions, including most of the most common functions.
>
> FWIW: We even consider to extend gpgme
On Tue, Mar 22, 2016 at 04:29:42PM +0100, Werner Koch wrote:
> On Tue, 22 Mar 2016 15:41, b...@adversary.org said:
>
> > provides a socket interface with which you can interact with
> > portions of the GPGME functions, including most of the most common
> > functions.
>
> FWIW: We even consider to
On Tue, Mar 22, 2016 at 3:53 PM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:
> I guess we should start from the desired use case.
> We want a GUI for what? Encrypting? Signing? Managing the web of
> trust? SSH login? Everything?
I think that deciding the desired use case(s) is importan
On Tue, Mar 22, 2016 at 03:45:09PM +0100, Bernhard Reiter wrote:
> On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
> > You know what might, though, if someone were to take up the old GPA
> > project perhaps ... maybe port it to GTK 3 or implement a Qt version.
>
> We have just cleanup an
On Tue, 22 Mar 2016 15:41, b...@adversary.org said:
> provides a socket interface with which you can interact with portions
> of the GPGME functions, including most of the most common functions.
FWIW: We even consider to extend gpgme-tool to be a Native Messaging
Server for Browsers.
Salam-Shal
I guess we should start from the desired use case.
We want a GUI for what? Encrypting? Signing? Managing the web of
trust? SSH login? Everything?
On Tue, Mar 22, 2016 at 3:45 PM, Bernhard Reiter wrote:
> On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
>> You know what might, though, if
On Tue, Mar 22, 2016 at 11:20:40AM +0100, Dashamir Hoxha wrote:
> On Tue, Mar 22, 2016 at 9:56 AM, Bernhard Reiter
> wrote:
> >
> > Any cross plattform approach would work. Python has the advantage
> > that the source code can be changed by an editor an immedeately run
> > and that it works fairly
On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
> You know what might, though, if someone were to take up the old GPA
> project perhaps ... maybe port it to GTK 3 or implement a Qt version.
We have just cleanup and simplified the structure of Kleopatra,
so that is making steps into the d
On Mon, Mar 21, 2016 at 06:38:31PM +0100, Peter Lebbing wrote:
> On 21/03/16 16:49, Dashamir Hoxha wrote:
> > Yes, but the overall number of commands and options supported
> > is 10 times smaller than those of gpg2. Tutorials about egpg are also
> > much shorter.
>
> These things can simply be sol
On Mon, Mar 21, 2016 at 03:05:05PM +0100, Bernhard Reiter wrote:
> Hi Dashamir,
>
> On Friday 18 March 2016 at 09:49:16, Dashamir Hoxha wrote:
> > I am writting some shell scripts for making GnuPG more accessible and
> > easier to use:
> > - https://github.com/dashohoxha/egpg
>
> I like the goal
> On 22 Mar 2016, at 10:40, Paolo Bolzoni wrote:
>
> And besides, it's much easier to build a GUI app in front of a C API
> than a command line application.
This is undeniably true. Unfortunately you first need to learn the API, which
can be a barrier to someone who knows the command line inte
On Tue, 22 Mar 2016 11:20, dashoho...@gmail.com said:
> scripts is terribly difficult. I don't understand why `gpg` does not follow
> the unix philosophy of being easily used in scripts and cooperating easily
> with other commands.
It actually does. There are just two things which differ:
- g
My real question is: what do you think in gpg is not easy enough?
On Tue, Mar 22, 2016 at 11:53 AM, Dashamir Hoxha wrote:
> On Tue, Mar 22, 2016 at 11:40 AM, Paolo Bolzoni
> wrote:
>>
>> And besides, it's much easier to build a GUI app in front of a C API
>> than a command line application.
>
>
> If you want to improve GnuPG's adoption rate, the best path forward
> appears to be to target users who only know how to navigate GUI interfaces.
>
> I don't think the EasyGnuPG authors have thought through their target
> market. It targets users who are comfortable enough
On Tue, Mar 22, 2016 at 11:40 AM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:
> And besides, it's much easier to build a GUI app in front of a C API
> than a command line application.
By no means I want to prevent anybody from starting to build a GUI app...
> This is an important point (using the API), because trying to use `gpg`
> in scripts is terribly difficult. I don't understand why `gpg` does not
> follow the unix philosophy of being easily used in scripts and
> cooperating easily with other commands.
GnuPG is, believe it or not, a lot more lik
And besides, it's much easier to build a GUI app in front of a C API
than a command line application.
On Tue, Mar 22, 2016 at 11:35 AM, Robert J. Hansen wrote:
>> And then, it is not difficult to build a GUI app on top of a
>> command-line tool that works properly. I cannot do it, but somebody
>>
> And then, it is not difficult to build a GUI app on top of a
> command-line tool that works properly. I cannot do it, but somebody
> maybe can do it easily.
Oh, it's *hard*. Look at how long it took Enigmail to get into a state
where it wasn't painful to use -- and there are still, today, parts
On Tue, Mar 22, 2016 at 10:46 AM, Robert J. Hansen
wrote:
>
> I don't think the EasyGnuPG authors have thought through their target
> market. It targets users who are comfortable enough to say "oh, I
> should use the terminal for this!", but not comfortable enough
in scripts and cooperating easily
with other commands.
So, if there are some things to be improved on gpg, this is one of them:
make it more scriptable. Alternatively, make a bash wrapper of Gpgme (which
can be used on bash scripts).
The other option (for EasyGnuPG) is to be reimplemented in Python or R
d
appears to be to target users who only know how to navigate GUI interfaces.
I don't think the EasyGnuPG authors have thought through their target
market. It targets users who are comfortable enough to say "oh, I
should use the terminal for this!", but not comfortable enough to rea
Hi Dashamir,
On Monday 21 March 2016 at 16:49:41, Dashamir Hoxha wrote:
> Hi Bernhard, thanks for having a look at it.
you are welcome! I appreciate all efforts to make GnuPG more accessible,
this is why I am taking a little bit of time to write up some feedback.
> On Mon, Mar 21, 2016 at 3:05
Ok, criticism is always good, although I know from my experience that 90%
of it is wrong.
There is plenty of documentation about gpg out there, both old and new one.
Maybe I am not smart enough, but believe me that I have spent a huge time
with gpg documentation, many years ago and recently, but I
On 21/03/16 20:16, Viktor Dick wrote:
> Actually, it seems that if you omit -o, gpg2 will do exactly this.
Ha! How silly of me. Why the hell did I think it would go to stdout? Once again:
try before you state with confidence.
Thanks for correcting me.
Cheers,
Peter.
--
I use the GNU Privacy G
On 21.03.2016 18:38, Peter Lebbing wrote:
> $ gpg2 -Ar de500b3e -e file.txt
>
> is nicer than:
>
> $ gpg2 -o file.txt.gpg -r de500b3e -e file.txt
Actually, it seems that if you omit -o, gpg2 will do exactly this.
Regards,
Viktor
signature.asc
Description: OpenPGP digital signature
__
On 21/03/16 16:49, Dashamir Hoxha wrote:
> Yes, but the overall number of commands and options supported
> is 10 times smaller than those of gpg2. Tutorials about egpg are also
> much shorter.
These things can simply be solved through new documentation rather than a new
interface. The man page is
Hi Bernhard, thanks for having a look at it.
On Mon, Mar 21, 2016 at 3:05 PM, Bernhard Reiter
wrote:
> Hi Dashamir,
>
> On Friday 18 March 2016 at 09:49:16, Dashamir Hoxha wrote:
> > I am writting some shell scripts for making GnuPG more accessible and
> > easier to use:
> > - https://github.co
Hi Dashamir,
On Friday 18 March 2016 at 09:49:16, Dashamir Hoxha wrote:
> I am writting some shell scripts for making GnuPG more accessible and
> easier to use:
> - https://github.com/dashohoxha/egpg
I like the goal of making gpg2 more accessible.
However I am not sure that you are actually reac
Hi,
I am writting some shell scripts for making GnuPG more accessible and
easier to use:
- https://github.com/dashohoxha/egpg
- http://dashohoxha.github.io/egpg/man/
- https://github.com/dashohoxha/egpg/wiki
It is not finished yet (regarding the features that I have planned to
implement), but
77 matches
Mail list logo
