Disclaimer:
Sorry guys, I first wrote these emails as part of another thread.
(Not enough sleep over the last days of 31C3 ...)
But because IMO this is something important for this list,
please allow me to redistribute it as separate thread, again.
For those who didn't have time to see it yet,
th
OK,
for those who didn't have time to see the talk at 31C3
as a whole and therefore wondering why this is an important talk,
let me point out and quote some content from
>> http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_
Hmm,
if I try to use keyserver.pgp.com as enigmail key server
it neither accepts public keys I want to upload
nor gives responses to searches of emails I know they have.
Am I missing something or does this key server only
work on a manual copy&paste or upload/download base?
My question was about
Hi,
to deal with faked keys, some guys had the idea to use
email verification and let then certification servers
take that as "casual signing".
For example:
- Some guy might create a key using a mail client
- That key is then automatically sent by the email client
to a server, which can be used
Are you or is someone working on DANE support for GnuPG?
Any schedule?
Am 22.07.2014 16:27, Werner Koch schrieb/wrote:
>
> On Tue, 22 Jul 2014 09:40, enigm...@josuttis.de said:
>> More and more we seem to have the problem of faked keys in the
>> key servers. This especially applies to "well known
More and more we seem to have the problem of faked keys in the key
servers. This especially applies to "well known" keys such as
authors of magazines and famous tools.
In addition, I have the problem that I'd like to use a special
reply-to address, which is not listed in the keyservers, but it
sho
Am 25.04.2014 19:43, Bernard Tyers schrieb/wrote:
> At the risk of being flamed, can I suggest asking the users what
> they think?
>
> Nicolai, by the look of it you've carried out some user research.
> I guess so by the "real world" discussion you posted in a message.
>
Well, the "users" I asked
Being off for some days and after reading all these emails
(very happy that there is progress!),
some thoughts:
First of all, MFPA raised:
> "Valid" in this context means that my copy of GnuPG will accept it
> as an encryption key.
For some reason, this for the first time gave "valid" a useful
int
between safe and unsafe mode.
(The unsafe mode is very important to send more
encrypted emails to help those who really need encryption).
Am 23.04.2014 01:03, Hauke Laging schrieb/wrote:
> Am Mi 23.04.2014, 00:50:24 schrieb Nicolai Josuttis:
>
>> In enigmail a user enable
First, thanks to all for helping to clarify the issue (for me)
Here is an example of a real world novice problem based on the current
terminology and what we discuss (a real example from today):
In enigmail a user enabled the option "trust_model always"
(it's currently named there as "Always trus
Before we continue to discuss "trust" and "valid",
allow me again to raise some technical questions regarding
GPG options and values, which I at least didn't understand
by reading docs and (roughly) source code
(but I need a clear understanding to program a frontend on it).
a) What is the effect o
Am 22.04.2014 12:56, Hauke Laging schrieb/wrote:
> Am Di 22.04.2014, 12:25:04 schrieb Nicolai Josuttis:
>
>> So the next question is: Is "trust a key" a valid term?
>
> The better question is: "Is it a useful term?"
>
> I consider this confusion a h
Hi,
please allow me to raise an issue I'd like to have harmonized among all
web mail frontends using PGP and GPG.
The reason I ask is because I am currently adding a feature for
auto encryption to enigmail.
The question is which terminology shall we use IN FRONTENDS
if we use the web of trust and
Thanks a lot for all answers regarding my question regarding GPG and bcc.
Allow me to summarize what I learned for both:
- double checking that I understood everything correctly
- documenting this for others
(I found no place where it is explained;
therefore also the change in the subject)
In
14 matches
Mail list logo