12 ms·
> When you press this button, That has not been my experience signing anything. I cant judge about the math behind the encryption, but the interface side of th
by otikik 8y ago
> When you press this button,
That has not been my experience signing anything. I cant judge about the math behind the encryption, but the interface side of things has always seemed ... lacking.
Use PGP for this. No, now it is called GPG instead. We thought it was funny. Pass this optional command line argument if you want extra security. Why would we want that as a default?. Enter a passphrase - it is recommended! Except no one uses them. Or they do. Have you installed gpg-agent? Ok so you have a public key now. Before you send stuff to this person you should celebrate a Key ceremony with them and interchange keys physically. Now add your key to your program. Ok so your commits are signed using your key now. If you want to sign a tag, however, you will need to pass this extra flag when creating the tag.
To be fair, that last one is mostly git CLI being consistently inconsistent [1]. But it still another spoke on the wheels.
Encryption needs to be easy in order to be mainstream. Otherwise it will be relegated to the minority which can jump through its interface hoops.
[1] Yes, I am going to be eaten by a hobgoblin any second now http://stevelosh.com/blog/2013/04/git-koans/#the-hobgoblin http://stevelosh.com/blog/2013/04/git-koans/#the-hobgoblin
- rjmunro 8y agoYou don't need to encrypt or sign anything. Organisations who email you like your bank and Paypal need to. You just need your email client to show a tick when it has verified a signature, which many already do with S/MIME.
- c22 8y agoIsn't this what DMARC is supposed to give us? Big companies like my bank and paypal run their own domains so they can use SPF/DKIM to authenticate their communications (and TLS to protect them in transit). Individually signed emails are only really useful for individuals.
- rakoo 8y agoNo, because SPF/DKIM/DMARC only says that the mail server at bank.com did send this email. What I want to know as a recipient is if it was the correct bank.com, and not baank.com. Because baank.com can also have SPF/DKIM/DMARC.
- c22 8y agoHow is this any different than a PGP signature? If you don't bother to check the sender then it doesn't matter how encrypted or signed the message is.
- rakoo 8y agoIf you don't bother to check the sender then you're not using pgp the way it's supposed to. pgp wants you to assign trust to identities, explicitly or not, after which pgp will automatically tell you whether you're talking to the right person or not. That's something SPF/DKIM/DMARC doesn't have for a very simple and legitimate reason: it's not a technical issue, it's a people's issue.
- c22 8y ago> ...it's not a technical issue, it's a people's issue. Exactly. Any solution you can come up with for baking PGP authentication into email can be applied also to DMARC, so if your primary use case is authenticating reputable businesses why not back the tech that's already seeing adoption by said businesses? Obviously it'd be great if all digital messages were effectively authenticated using strong cryptography. I imagine at some point we'll get there, probably through a combination of maturing technology and better educated users.
- rakoo 8y agoSaying "I trust you" is baked in in pgp. There's no such thing for DMARC because that's not its goal: DMARC and co are on the sender side for it to say "look it's really me", but that's not what we want. What we want would be a way to instruct our MTA to say "I trust these guys, the others go to the trash/spam"
- c22 8y agoI feel like we're talking past each other here. There's no reason an MTA couldn't allow you to designate the senders you trust and send the rest to spam. You could do the same by integrating PGP. The key exchange problem is the same, but DMARC handles this by tying the key to the domain. So if the email comes from bank.com and bank.com is also where you do your online banking you can be reasonably confident your bank sent the message. If we used PGP to do this then your bank would have to publish their public key somewhere and you would have to manually check that it's valid (served over https? printed on a card handed to you by the bank manager?) and configure it into your email client. This is exactly the user experience nightmare that causes "no one signing their emails". Obviously this sort of verification is required if you want truly authenticated communications with individuals, many of whom may share a domain, but if you simply want to verify that the organization you're talking to is who they say they are then the domain name is a suitable proxy.
- isostatic 8y ago"verified a signature" How do you know that's your bank's signature and not from "h-s-b-c.com" How does granny know?
- pas 8y agoYour email client should show you if you have encountered that identity (identities of course can and should rotate keys, etc, and identities should be also signed by the keys that correspond to the certs signed by the CAs for the website/service). At first you don't know much about it, but it's a signal. If you continue to bank with HSBC and you get emails from them, you'll be able to spot a fake and the email client can say that it's a likely fake. No need to say anything else when you can't say otherwise.