Am 17.02.2017 um 21:57 schrieb Kristian Fiskerstrand:
> On 02/17/2017 09:46 PM, si...@web.de wrote:
>> Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand:
>>> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
>
>
>>>
>>> That change would also be consistent with
>>> https://git.gnupg.org/cgi-
On 02/17/2017 09:46 PM, si...@web.de wrote:
> Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand:
>> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
>>
>> That change would also be consistent with
>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663
Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand:
> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
>> On 02/17/2017 07:00 PM, si...@web.de wrote:
>>> keyserver hkps://jirk5u4osbsr34t5.onion
>>> keyserver hkps://keys.gnupg.net
>>>
>>> would solve this I guess.
>>
>> No, that'd result in ce
On Fri 2017-02-17 04:42:14 -0500, Justus Winter wrote:
> Well, I tested it on all systems I had access to at that time. I could
> have written a small test program, and asked people to run it on systems
> we don't have access to. But we never got to that point :(
That would be a way to advance t
On Fri 2017-02-17 08:59:52 -0500, Ralph Corderoy wrote:
> There's a few relevant patches by Daniel Kahn Gillmor, e.g. cancelling
> the socket check if inotify(7) can be used.
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032012.html
We're shipping these patches in debian testing an
On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
> On 02/17/2017 07:00 PM, si...@web.de wrote:
>> keyserver hkps://jirk5u4osbsr34t5.onion
>> keyserver hkps://keys.gnupg.net
>>
>> would solve this I guess.
>
> No, that'd result in certificate errors and non-responsive servers
>
That said, you
On 02/17/2017 07:00 PM, si...@web.de wrote:
> keyserver hkps://jirk5u4osbsr34t5.onion
> keyserver hkps://keys.gnupg.net
>
> would solve this I guess.
No, that'd result in certificate errors and non-responsive servers
--
Kristian Fiskerstrand
Blog: https://blog.sumpt
Am 17.02.2017 um 17:31 schrieb Kristian Fiskerstrand:
> On 02/17/2017 01:37 PM, si...@web.de wrote:
>> Is there something I missed or is this unintended?
>
> gnupg does not ship an installed dirmngr.conf, when no keyserver is
> specified it defaults to hkps://hkps.pool.sks-keyservers.net, the
> exi
On 02/17/2017 01:37 PM, si...@web.de wrote:
> Is there something I missed or is this unintended?
gnupg does not ship an installed dirmngr.conf, when no keyserver is
specified it defaults to hkps://hkps.pool.sks-keyservers.net, the
existence of a (I presume) arch installed dirmngr.conf changes this
Stefano,
I meant to reply last night, but didn't fancy writing this out on a
phone keyboard. No need to resend questions - this tends to be a
high-latency list for people in odd time zones, working from home, on
the move etc.
NB all the below is IMHO, YMMV etc. :-D
On 16/02/17 15:04, Stefano Tra
Hi,
gnupg 2.1.18-1 on Arch Linux. I noticed powertop ranking the
gpg-agents, one per user, quite highly, and their impact is multiplied
by their number. strace(1) showed the two-second select(2) timing out
with no syscalls in between, and the forking of two siblings to have a
`GETINFO pid' chat
Hi all,
I'm sort of new to GPG/PGP, I'm not new to the encryption/crypto world and
to computers, however, some concepts are yet not clear to me.
I can't get my head around on how to use GPG in the "correct" way to
guarantee the maximum result. That is: protect, at the best, my privacy and
also don
Some time ago I asked about the unencrypted download of public keys.
The answer was that the current gnupg does use https by default to fetch the
keys.
I found the time to retest this on a new setup and found that gnupg 2.1.18
still uses http connections to fetch the keys.
I uses a newly instal
Daniel Kahn Gillmor writes:
> On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote:
>> That is still wrong. The length of the path of the socket is not
>> limited in any way, the length of the path passed to connect is.
>
> this is a clever approach to *connect* to such a socket,
Yes.
> on so
14 matches
Mail list logo
