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
>>
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
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,
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:
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
>
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
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
Am 04.02.2017 um 23:27 schrieb Daniel Kahn Gillmor:
> On Sat 2017-02-04 15:14:50 -0500, sivmu wrote:
>> I suppose this config did not change after upgrading from 2.1.17.
>> Just tested it on 2.1.18 using arch and it still uses http on my setup.
>
> it's not a config change -- it's a defaults
On Sat 2017-02-04 15:14:50 -0500, sivmu wrote:
> I suppose this config did not change after upgrading from 2.1.17.
> Just tested it on 2.1.18 using arch and it still uses http on my setup.
it's not a config change -- it's a defaults change.
in the old arrangement, if you didn't specify a
Am 04.02.2017 um 08:18 schrieb Daniel Kahn Gillmor:
> On Sat 2017-02-04 01:33:56 -0500, sivmu wrote:
>> When using --revc-key or the gpa frontend, I noticed that the
>> target public keys are still downloded using unencrypted http. While the
>> trnasmitted information is generally public, it
On Sat 2017-02-04 01:33:56 -0500, sivmu wrote:
> When using --revc-key or the gpa frontend, I noticed that the
> target public keys are still downloded using unencrypted http. While the
> trnasmitted information is generally public, it doesmake things pretty
> easy for an adversary to collect
When using --revc-key or the gpa frontend, I noticed that the
target public keys are still downloded using unencrypted http. While the
trnasmitted information is generally public, it doesmake things pretty
easy for an adversary to collect metadata such as your contacts.
This is expecially
12 matches
Mail list logo
