Re: OT: Which smartphone would you use

[Thomas Hejze]

Am Donnerstag, 21. September 2017, 19:48:34 CEST schrieb Matthias Apitz:

> > Unfortunately their hardware dos not seem to support Ubuntu any more. I
> > found the "Ubuntu Edition" under "obsolete models", even a cyanogen
> > edition, but all their current models run on Android. The rest of their
> > homepage is all marketing gibberish as it is the use, nowadays.
> 
> Look for second hand devices of the BQ "Ubuntu Edition" (BQ does not
> produce nor sell them anymore). Such devices you could reflash to the
> software available at ubports.com

Thanks for the information, but what are the perspectives? Lets hope the 
community has enough endurance, but which hardware to buy in three or four 
years?

Regards
Thomas



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: OT: Which smartphone would you use

[Thomas Hejze]

Am Freitag, 22. September 2017, 10:36:45 CEST schrieb Franck Routier:
> Hi, Jolla did an official port of SailfishOS to Sony Xperia X hardware.



> The only point is the the image is not yet available for purchase,
> but it should be a matter of days...
> 
> See https://blog.jolla.com/sailfishx/

Thanks for the information. I'll keep an eye on it.

Regards
Thomas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Werner Koch]

On Tue, 26 Sep 2017 13:07, andr...@andrewg.com said:

> The gpg command itself should cryptographically verify signatures when
> performing --list-sigs, so that at least it can throw a warning when an

Actually --list-sigs is more of a debug command than a command users
should use to verify a key.  The real command is --check-sigs and it
does what you suggested. 

Unfortunately the man pages describes --list-sigs in detail and only in
the next paragraph --check-sigs is explained in terms of --list-sigs.
it might be better to merge them into one description with a focus on
--check-sigs.

Anyway, it is easy to create keys just for signatures and --check-sigs
would not make a difference.  Look at my key for all those vanity
signature.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpRq4IaKv732.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Tue, 26 Sep 2017 15:14:38 +0200, Kristian Fiskerstrand wrote:
> On 09/26/2017 03:05 PM, Stefan Claas wrote:
> > I'm no expert like all you guys, but my dream would be if Werner
> > and his team could
> > work together with the keybase team, so that we could have WKD
> > support for keybase.  
> 
> WKD is a good step in providing a mechanism for key discovery, but if
> automatically considering such keys valid (either directly or through
> TOFU-model) you reduce the security to security of X.509 root
> certificate PKIX, which many users trusts implicitly already so it is
> a good simplification in many cases. That said I fail to see where
> keybase comes into the picture, maybe you can elaborate a bit on that?
> 
Well, i can't fetch keys from keybase with GnuPG in the command line
like i can do with traditional key servers. On keybase i am in full
control of my pub key, so that nobody can add there unwanted
signatures or a fake "sig3" to my pub key. I could not test WKD yet,
but believe that the same rule applies there too, with protecting
my pub key. If both, WKD and keybase could work as one unit
GnuPG power users could fetch keys via CLI, as usual, or via their
client software and users had the ability too to check also the keybase
Web Interface for additional infos about a user, if they like to do so.

keybase current stats:

Keys: 763,642
Humans: 180,431
Teams: 8,652 (new!)

The figures should not be underestimated imho because i believe
that keybase helps also the grow of GnuPG and is a nice addition for
GnuPG users, me thinks.

Regards
Stefan




-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 03:51 PM, Andrew Gallagher wrote:
> Not getting into an OS flame war here, but not everyone uses Android. 

That doesn't mean it doesn't exist, it just means different user
preferences as represented by the weigths in the decision matrix when
purchasing a new device.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Use of Passphrase Callback

[SHARMA Sandhya (MORPHO)]

Hello,

Does anyone has idea how to implement this.
As I have urgent business need to do it ASAP.

Thanks,
Sandhya

From: SHARMA Sandhya (MORPHO)
Sent: Friday, September 22, 2017 6:21 PM
To: 'gnupg-users@gnupg.org' 
Subject: Use of Passphrase Callback

Hello,

I am Using gnupg on windows and want to use "Passphrase Callback" functionality 
to input password for private key.
My current lines of code is:
error = gpgme_set_pinentry_mode(context,GPGME_PINENTRY_MODE_LOOPBACK);
gpgme_passphrase_cb_t func = _callback;
gpgme_pinentry_mode_t pinMode =  gpgme_get_pinentry_mode(context);
void *pp = 0;
gpgme_set_passphrase_cb(context,func,pp);

and declaration of gpgme_passphrase_cb_t is
gpgme_error_t passphrase_callback(void *opaque, const char *uid_hint, const 
char *desc,int prev_was_bad, int fd)

but breakpoint on this function never hits.
Kindly provide help on this or any example used to implement Passphrase 
CallBack.



Thanks & Regards,
Sandhya Sharma

#
" This e-mail and any attached documents may contain confidential or 
proprietary information. If you are not the intended recipient, you are 
notified that any dissemination, copying of this e-mail and any attachments 
thereto or use of their contents by any means whatsoever is strictly 
prohibited. If you have received this e-mail in error, please advise the sender 
immediately and delete this e-mail and all attached documents from your 
computer system."
#
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 14:39, Kristian Fiskerstrand wrote:
> On 09/26/2017 03:38 PM, Andrew Gallagher wrote:
>> Yes. Unfortunately it's tricky to implement that on a smartphone. We
>> don't have card+phone working in gnupg yet either. We *barely* have
>> gnupg working on phones at all. But that's for another day.
> 
> Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from
> OpenKeychain.. Not that it should be used too much, a smartphone is one
> of the least secure devices around.

Not getting into an OS flame war here, but not everyone uses Android. ;-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 03:38 PM, Andrew Gallagher wrote:
> Yes. Unfortunately it's tricky to implement that on a smartphone. We
> don't have card+phone working in gnupg yet either. We *barely* have
> gnupg working on phones at all. But that's for another day.


Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from
OpenKeychain.. Not that it should be used too much, a smartphone is one
of the least secure devices around.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Credo quia absurdum
I believe it because it is absurd



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 13:49, Kristian Fiskerstrand wrote:
> 
> The users shoudn't browse keyservers at all, so it shouldn't really be
> an issue. Linking to get operation to get the public keyblock is just a
> convenience.

Users shouldn't do it. And yet they still do it, precisely because it is
a convenience.

>> WhatsApp gets the UX *very nearly* right. And since everyone and his dog
>> now uses it that's the new baseline. If it's easier to do it wrong than
> 
> No, that actually is broken by design

It's broken, but it's usable. They've prioritised usability over
security, absolutely. People don't care. They should, but they don't.
We're not going to get them to embrace something technically better if
it's harder to use.

> as it doesn't open up for proper operational security controls, > in 
> particular lack of private key
> separation on smartcard and airgapped computer.

Yes. Unfortunately it's tricky to implement that on a smartphone. We
don't have card+phone working in gnupg yet either. We *barely* have
gnupg working on phones at all. But that's for another day.

> the name of the primary UID of a signature is irrelevant; if we follow
> this argument; (i) until it is verified everything is untrustworthy, so
> (ii) the signature itself shouldn't be shown, nor should any of the UIDs
> for the public keyblock itself, as the self-signature isn't verified

I wouldn't go that far. The signature itself is not a signature by "John
Doe " - it's a signature by some (sub)key "0x123456...".
The fact that it may or may not be a (sub)key bound to "John Doe" is
rightly stored elsewhere. My argument is that displaying an unverified
comment that *implies* there is a binding *somewhere else* identifying
this key with a particular ID may be a convenience, but is a)
unnecessary and b) a source of confusion. We can't perform any
verification without downloading the full key of the owner anyway, and
that's done with the fingerprint.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 17-09-26 09:15 AM, Andrew Gallagher wrote:
> On 26/09/17 12:30, Kristian Fiskerstrand wrote:
>> On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
>>> So SKS should just say "unverified signature from 
>>> ". It should not repeat the purported user ID, nor
>>> provide a search link that returns completely unrelated keys
>>> that happen to have the same purported ID.
>> 
>> No, that is also wrong, as it implies that anything is trusted 
>> unless otherwise stated. A malicious actor can claim it is 
>> verified all he/she wants (simply removing the disclaimer).
> 
> Um, did you reply to the wrong paragraph? I did mention
> disclaimers elsewhere, but only in passing (and tongue in cheek).
> My argument is that we shouldn't be displaying unverified
> information at all.
> 
>> The user's default position NEEDS to be that nothing is verified
>>  until it is done locally or by an explicitly trusted third 
>> party.
> 
> Absolutely. None of this is an argument against users having to do 
> things right. But the way to get users to do things right is to 
> train them to do things right from the start - and you do that by 
> railroading them down the straight and narrow and not even have the
> option to do it any other way. That way, if the opportunity to do
> it wrong arises in the future their first instinct will be "this
> isn't how it's supposed to happen". If you can't train people
> personally, you have to write your software so that the software
> trains them.
> 
Why?  Ultimately are we not all responsible for our own actions?
People should be required to make some effort.

> WhatsApp gets the UX *very nearly* right. And since everyone and 
> his dog now uses it that's the new baseline. If it's easier to do 
> it wrong than in WhatsApp, it's broken. If it's harder to 
> understand than WhatsApp, it's broken. If you have to read more 
> instructions than WhatsApp, it's broken.
> 
WhatsApp controls the key material.  *Seems* safe so far but who
knows.  I personally would never put anything truly confidential over
WhatsApp.  And actually people are supposed to verify that they are
messaging who they think they are messaging by doing a comparison of
fingerprints or ids or whatever they are called.  I only message one
person with it so it's been a while since I've had to do it.  But I am
willing to bet lots of users don't do that verification step.  It's a
good UX but not perfect.  Same goes for GPG in my opinion.  It's good
but not perfect.  It never will be and I don't believe any (security)
software will ever have a perfect mix of features for all users and
use cases out of the "box"

> It's no good implementing something correctly if it can be applied 
> incorrectly. Murphy's Law applies.
> 
I don't want my software or its developers acting like my big brother!

>> being able to browse the keyserver directly is too useful for 
>> debugging to completely remove
> 
> Indeed, but is it necessary to display the untrustworthy user-ID
> on signatures? The fingerprint should be sufficient.
> 
> 
> 
> ___ Gnupg-users mailing
> list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

Best Regards,
Duane

- -- 
Duane Whitty
du...@nofroth.com
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZykjZAAoJEOJfpr8UVxtkeY4IAKL6A0KqGm85yzSrEh6Stj5z
sC86fbEtP/xXkrbYdUDVfkEYuj3AqkNL+E4AaJXO0xT8limk4COMRwl8346V9J7O
dzNIjdHAXU0iGrIBxj+CWILyY4qxTnmDar9ef+7lKxFAbJ8pUBJVxzeh0Ci2Al2L
hYXhWBrCyjqHqbMmAB/JaUBJy4BTCHNAFy704rblB2ZbqKAqbQpaTP+Jx14HWCQG
saSZn8qZwbiAnVcX4vUzssOi5Ls81eEU4W5GPGOqw7u5CvyadgXuJB8578B3qjHH
I9JQAIom6xrw3V8USwqsBCO4W9v3+C3fcT1WXivOJsZbKqJDRodjtBrxvKuI1/k=
=oYMp
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 02:15 PM, Andrew Gallagher wrote:
> Absolutely. None of this is an argument against users having to do
> things right. But the way to get users to do things right is to train
> them to do things right from the start - and you do that by railroading
> them down the straight and narrow and not even have the option to do it
> any other way. That way, if the opportunity to do it wrong arises in the
> future their first instinct will be "this isn't how it's supposed to
> happen". If you can't train people personally, you have to write your
> software so that the software trains them.

The users shoudn't browse keyservers at all, so it shouldn't really be
an issue. Linking to get operation to get the public keyblock is just a
convenience.

> 
> WhatsApp gets the UX *very nearly* right. And since everyone and his dog
> now uses it that's the new baseline. If it's easier to do it wrong than


No, that actually is broken by design as it doesn't open up for proper
operational security controls, in particular lack of private key
separation on smartcard and airgapped computer.

> 
>> being able to browse the
>> keyserver directly is too useful for debugging to completely remove
> Indeed, but is it necessary to display the untrustworthy user-ID on
> signatures? The fingerprint should be sufficient.

the name of the primary UID of a signature is irrelevant; if we follow
this argument; (i) until it is verified everything is untrustworthy, so
(ii) the signature itself shouldn't be shown, nor should any of the UIDs
for the public keyblock itself, as the self-signature isn't verified,
and (iii) and the keyserver can't verify it as it isn't a trusted part
of the infrastructure so the user can't know that it isn't a malicious
operator running the specific server.

The only logical consequence from (i)-(iii) is to remove keyservers from
the mix and let users do bilateral exchanges (good luck with revocation
distribution), for the simple reason that SOME users can't do things
right, it has to destroy any chance of a proper security for others.
Which incidentally is similar to a lot of other over-simplification and
interconnections throughout the world, but that is a separate
discussion. Finding the least common denominator and simplify everything
to the absurd, no matter the consequences.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Great things are not accomplished by those who yield to trends and fads
and popular opinion."
(Jack Kerouac)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 12:30, Kristian Fiskerstrand wrote:
> On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
>> So SKS should just say "unverified signature from ". It
>> should not repeat the purported user ID, nor provide a search link that
>> returns completely unrelated keys that happen to have the same purported ID.
> 
> No, that is also wrong, as it implies that anything is trusted unless
> otherwise stated. A malicious actor can claim it is verified all he/she
> wants (simply removing the disclaimer).

Um, did you reply to the wrong paragraph? I did mention disclaimers
elsewhere, but only in passing (and tongue in cheek). My argument is
that we shouldn't be displaying unverified information at all.

> The user's default position
> NEEDS to be that nothing is verified until it is done locally or by an
> explicitly trusted third party.

Absolutely. None of this is an argument against users having to do
things right. But the way to get users to do things right is to train
them to do things right from the start - and you do that by railroading
them down the straight and narrow and not even have the option to do it
any other way. That way, if the opportunity to do it wrong arises in the
future their first instinct will be "this isn't how it's supposed to
happen". If you can't train people personally, you have to write your
software so that the software trains them.

WhatsApp gets the UX *very nearly* right. And since everyone and his dog
now uses it that's the new baseline. If it's easier to do it wrong than
in WhatsApp, it's broken. If it's harder to understand than WhatsApp,
it's broken. If you have to read more instructions than WhatsApp, it's
broken.

It's no good implementing something correctly if it can be applied
incorrectly. Murphy's Law applies.

> being able to browse the
> keyserver directly is too useful for debugging to completely remove

Indeed, but is it necessary to display the untrustworthy user-ID on
signatures? The fingerprint should be sufficient.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
> So SKS should just say "unverified signature from ". It
> should not repeat the purported user ID, nor provide a search link that
> returns completely unrelated keys that happen to have the same purported ID.

No, that is also wrong, as it implies that anything is trusted unless
otherwise stated. A malicious actor can claim it is verified all he/she
wants (simply removing the disclaimer). The user's default position
NEEDS to be that nothing is verified until it is done locally or by an
explicitly trusted third party.

Any kind of disclaimer is actually doing the user a dis-service and
supporting a subset of the user base that lacks sufficient
experience/knowledge to do anything securely to begin with, which is the
root cause of the issue; the solution isn't a disclaimer it is more
education.

Fwiw I don't recommend anyone to directly link to vindex etc on
keyservers, you'll notice that https://sks-keyservers.net only links to
get operations for similar purposes (if you find a (v)index link it is a
bug and you should report it separately), but being able to browse the
keyserver directly is too useful for debugging to completely remove. It
is a reason it is done on port 11371 for hkp and I would encourage only
accessing it through a local client, but other than that it isn't much
to do on the keyserver side.

But the lesson here is that in order to avoid misuse by an unexperience
userbase the protocol has to be a binary obfuscated mess instead of
trying to re-use well-established protocols in text form, just in case
the user walks into the maze for some reason.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"If you don't drive your business, you will be driven out of business"
(B. C. Forbes)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users