> Otherwise, any application [which knows only username/email] has
> to be know also the specific keyid to override gpg's default
> selection (which I'm guessing is the first key in the keyring);
> this seems wrong...
It is wrong. You should file a bug with the software package which is
mistakenl
On 05/07/2016 07:20 PM, Rick van Rein wrote:
> I do like the idea of harvesting CPU-internal data, but do not feel free
> of worries about this implementation style. There should be a more
> accurate model of its entropy before I'd trust it. But once it has
> this, the principle might expand to i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Monday 9 May 2016 at 12:14:09 AM, in
, Scott Mcdermott wrote:
> (aside: the default key selected for a userid should
> probably be
> the later key anyways, I would think, under the
> assumption that
> one always want to use the newer key, n
I have multiple keys for the same userid. When using:
gpg --sign --user em...@address.foo
gpg-2.1.11 is always choosing the wrong one. The 'default-key'
setting is ignored (as documented) due to presence of '--user'.
Does this mean there is no way to tell gpg to automatically sign
with a p
On 8 May 2016, at 13:54, Dashamir Hoxha wrote:
>
>> On Sun, May 8, 2016 at 2:09 PM, flapflap wrote:
>> I really don't think that bash is the right language here...
>
> But if you want to automate some tasks on the command line, bash seems to be
> the perfect choice.
By hand, yes. If you are
On Sun, May 8, 2016 at 2:09 PM, flapflap wrote:
>
> I really don't think that bash is the right language here...
But if you want to automate some tasks on the command line, bash seems to
be the perfect choice.
___
Gnupg-users mailing list
Gnupg-users@g
On 08/05/16 14:09, flapflap wrote:
> (for that reason, most unix tools
> accept a "--" argument to interpret all following args as input/file
> names, not as commands)
This includes gpg2. The complexity of the gpg2 command line means some
things require a good ordering of options and commands, whi
Robert J. Hansen:
> And at that point I decided that I *will not* test this code. If
> WORKDIR is set in the user's environment before they start egpg, egpg
> will shred and rm -rf $WORKDIR. This could have terrifying consequences
> for my doctoral thesis, and even worse if someone has WORKDIR se
> Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it?
I have tried very hard to be polite in my criticisms, but you seem to be
under the unreasonable belief that politeness means I am amenable to
working with you on it.
I do not want to be involved with this in any way, excep
> > Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it?
>
I think that this is a better fix:
https://github.com/dashohoxha/egpg/commit/ff331e1db8f28a9521c2603f84fde1c9412702bd
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http:/
On Sun, May 8, 2016 at 10:48 AM, Robert J. Hansen
wrote:
> > Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it?
>
> I have tried very hard to be polite in my criticisms, but you seem to be
> under the unreasonable belief that politeness means I am amenable to
> working with
On Sun, May 8, 2016 at 9:56 AM, Robert J. Hansen
wrote:
>
> I found a potentially *system-destroying bug* in literally the *very
> first function I inspected*. I've been very circumspect in my
> criticisms until now, Dashamir, because I really want to encourage
> people to hack on things. But it
> Or is it totally a worthless idea.
I think this code, in its current form, is genuinely dangerous, and
should not be recommended to anyone.
> Are you sure you used the right branch for testing?
I didn't test it. What I saw while reading your code gave me such the
heebie-jeebies I *won't* test
13 matches
Mail list logo
