On Tue, 18 Jul 2017 22:49, r...@sixdemonbag.org said:
> random_seed is internal data belonging to the PRNG.
That is right. However we always add at least 128 bit of fresh random
which would be enough - at least on all systems with /dev/random or on
Windows. It is just that we are ultra-conserva
> Ah, you got me ;-) So you are a developer?
In my day job I'm a developer, among other things. However, due to my
taking research funding from the U.S. government in the past, I do not
contribute code to either GnuPG or Enigmail. I find other, non-code,
ways to help the GnuPG and Enigmail teams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/18/17 08:36, Robert J. Hansen wrote:
>> ... shouldn't the focus of GnuPG be on security?
>
> This *is* a security issue.
Since you put it that way, I agree.
> Some ... GnuPG use a ... "random_seed"... must not be backed up or
> shared ...
> Sorry if I'm asking dumb questions
Not a dumb question.
> what would be wrong with sync'ing the whole gnupg directory (or the
> whole user profile / home directory) with rsync/duplicity/whatever ?
There are a number of lockfiles, sockets, etc., that live in the
~/.gnupg directory which shouldn
Am 18.07.2017 um 15:36 schrieb Robert J. Hansen:
>
>> While it would be nice if it were easier to be able to back up easily
>> as you're suggesting, shouldn't the focus of GnuPG be on security?
> This *is* a security issue.
>
> Some versions of GnuPG use a file called "random_seed", for instance.
>
Il 18/07/2017 14:23, Daniel Villarreal ha scritto:
> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"
Security = confidentiality + integrity + availability
If you're not considering availability, you only can have partial security.
BYtE,
Diego
> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"
I have made these observations before, yes.
> While it would be nice if it were easier to be able to back up easily
> as you're suggesting, shouldn't the focus of GnuPG be on security?
This *is* a security issue.
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/17/17 08:54, Robert J. Hansen wrote:
>> I'm not sure if Rob's routine actually backs up local
>> signatures... I couldn't see anything explicit about it with a
>> quick glance at the code. That's fine if you don't use local
>> signatures at
> Please note that while I greatly appreciate that Mr. Hansen wrote a
> program to handle this, I still like having the option of doing things
> manually.
At risk of sounding arch and caustic -- which I'm not; it's just that
reality is going to sound arch and caustic -- go for it: just remember
t
> I'm not sure if Rob's routine actually backs up local signatures...
> I couldn't see anything explicit about it with a quick glance at the
> code. That's fine if you don't use local signatures at all.
The step-by-step process I posted last year didn't, because I don't use
them in my own local po
On 17/07/17 01:50, Daniel Villarreal wrote:
> Are you recommending...
> [...]
> instead of
Yes, instead of, not in addition to. The export-local-sigs will add the
local sigs, the other non-local sigs will still be there as well.
> And this all functions with gpg2 in place of gpg ?
Yes, just use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/14/17 13:56, Peter Lebbing wrote:
> There's an option missing that could cause data loss in its
> absence:
>
> $ gpg --armor --export > pub.asc
>
> I'd make that:
>
> $ gpg --armor --export-options export-local-sigs --export >pub.asc
>
> I
There's an option missing that could cause data loss in its absence:
$ gpg --armor --export > pub.asc
I'd make that:
$ gpg --armor --export-options export-local-sigs --export >pub.asc
If you have made any signatures that are not exportable (so lsign and
friends), they would not be exported othe
13 matches
Mail list logo
