Re: Debian dev-machine best practice? was: keybase.io
Thomas Koch writes (Debian dev-machine best practice? was: keybase.io): I'm planning to improve my paranoia once I become a DD. [...] I'm longing for linux containers to become usable for noobs like me. Than I could move untrusted applications from virtual machines into unprivileged containers (running without root privileges). That sounds like a substantial _reduction_ in your level of security (or, of paranoia, as you put it). The containment security of virtual machines is much better than that of Linux containers. I agree with the reply from Ben Hutchings. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21344.59220.760021.256...@chiark.greenend.org.uk
Debian dev-machine best practice? was: keybase.io
Hi, I'm planning to improve my paranoia once I become a DD. For now I run Debian stable + backports exclusively on the machine having my private key. Everything else runs in a virtual machine with xpra[1] for X. I don't use Skype. [1] xpra package in Debian I'm longing for linux containers to become usable for noobs like me. Than I could move untrusted applications from virtual machines into unprivileged containers (running without root privileges). I was about to automate my setup of kvm+xpra when I learned more about containers and now consider this the best compromise if you don't use a separate offline machine to sign packages. What do you think? Regards, Thomas Koch -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201404251107.57998.tho...@koch.ro
Re: Debian dev-machine best practice? was: keybase.io
On Fri, 2014-04-25 at 11:07 +0200, Thomas Koch wrote: Hi, I'm planning to improve my paranoia once I become a DD. For now I run Debian stable + backports exclusively on the machine having my private key. Everything else runs in a virtual machine with xpra[1] for X. I don't use Skype. [1] xpra package in Debian I'm longing for linux containers to become usable for noobs like me. Than I could move untrusted applications from virtual machines into unprivileged containers (running without root privileges). I was about to automate my setup of kvm+xpra when I learned more about containers and now consider this the best compromise if you don't use a separate offline machine to sign packages. What do you think? I think there are too many local privilege escalation vulnerabilities in Linux, to rely solely on containers as a sandbox mechanism. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Debian dev-machine best practice? was: keybase.io
Thomas Koch tho...@koch.ro writes: I'm planning to improve my paranoia once I become a DD. For now I run Debian stable + backports exclusively on the machine having my private key. Everything else runs in a virtual machine with xpra[1] for X. I don't use Skype. How good is the performance of this for things like Firefox? I've been tempted to switch to this model on all of my systems (only running web browsers inside a VM), since that's probably the largest attack point for a system that doesn't run services, but I know that running Firefox over the network is almost impossibly slow and was wary of doing a bunch of work to get this set up only to discover that the same applies in VMs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761lxuxvt@windlord.stanford.edu
Re: keybase.io
Hello, On Sat, 5 Apr 2014 09:50:23 +0200 Jakub Wilk jw...@debian.org wrote: My point was this attack vector (nonfree code running on the same machine as your OpenPGP key) taken to it's absolute extreme (wine, dropboxd) is still *not* grounds for automated removal from the keyring. It's a popular misconception that the only purpose of wine is to run non-free malware. Of course not! It can also be used to run free software malware too. -- Cheers, Andrew signature.asc Description: PGP signature
Re: keybase.io
On Fri, Apr 04, 2014 at 08:56:50PM -0600, Gunnar Wolf wrote: Right. However, I guess that most uses of the app (other than sending a message saying yes I'm here, this is me) will require pasting the key. Or not? Keybase users, please enlighten me: What do you do with it besides just existing on teh graph? I'm using keybase.io in the same way I use: * pgp.mit.edu * keyring.debian.org * pgp.cs.uu.nl None of those sites have a copy of my private key. My private key resides offline at an encrypted storage on a trusted location. Problem? -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Re: keybase.io
]] Enrico Zini [3] Anyway, there is no activity LED for the microphone. Can I have a panel applet thingie which shows if some process is reading from a microphone or webcam device? Use a physically separate microphone, either a headset or something like http://www.yamaha.com/products/en/communication/usb_conference_speakerphones/pjp-10ur/?mode=model (The latter is an absolutely excellent little conference mike: shows up as an USB audio device, does in-firmware echo cancellation, only downside is its price tag of ~220 USD.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3b1edn5@xoog.err.no
Re: keybase.io
* Paul Tagliamonte paul...@debian.org, 2014-04-04, 20:15: My point was this attack vector (nonfree code running on the same machine as your OpenPGP key) taken to it's absolute extreme (wine, dropboxd) is still *not* grounds for automated removal from the keyring. It's a popular misconception that the only purpose of wine is to run non-free malware. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405075023.ga3...@jwilk.net
Re: keybase.io
On Fri, Apr 04, 2014 at 07:27:36PM -0400, Paul R. Tagliamonte wrote: +1 russ. This is true of the dropbox daemon too. Are we to throw out DDs with dropboxd installed? Wine? ...skype, steam, flashplugin-nonfree[1]. Code git-cloned without checking signatures on tags[2] or doing some auditing[3]. Random cool vim plugins git pulled from random people on github with fancy selfies[4]. ssh -X or -Y to a remote host, then run X apps. I've recently got worried about common practices I see around me, and started considering running a Hardening Debian Development BOF at the next Debian event I'm going to participate. The intention would be to see how to address those issues, but with a strong awareness on usability[5]. Ciao, Enrico [1] for example, https://lists.debian.org/debian-vote/2014/03/msg00246.html skype and adobe can be trusted or course, it's not as if some random government wouldn't have motivation and means to tweak with their code. [2] As if people nowadays signed their tags. Or tagged releases. Or released at all. Who needs QA? Code review? The coolest features are in master, implemented an hour ago. [3] http://underhanded.xcott.com/ [4] luckily, this is disabled by default, but hell if I found a warning about it: https://github.com/scrooloose/syntastic/blob/master/syntax_checkers/html/w3.vim (also found in /usr/share/vim/addons/syntax_checkers/html/w3.vim) [5] https://www.schneier.com/blog/archives/2009/08/security_vs_usa.html -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: keybase.io
* Enrico Zini enr...@enricozini.org, 2014-04-05, 11:40: ssh -X or -Y to a remote host, then run X apps. For you convenience, Debian OpenSSH client sets ForwardX11Trusted to yes by default, making -X and -Y synonymous. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405101119.ga6...@jwilk.net
Re: keybase.io
On 5 Apr 2014, at 00:18, Gunnar Wolf gw...@gwolf.org wrote: Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? The client side crypto stuff can't be done without uploading the private bit. All key base have seen of my key is the output of gpg --export -a -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e7cc08be-64fd-4989-91fb-a0f86d2d1...@debian.org
Re: keybase.io
Enrico Zini enr...@enricozini.org writes: ssh -X or -Y to a remote host, then run X apps. Which requires that host allow remote logins, which creates a different sort of security issue. Also, tunneling a web browser over X is an unbelievably painful experience. I've recently got worried about common practices I see around me, and started considering running a Hardening Debian Development BOF at the next Debian event I'm going to participate. The intention would be to see how to address those issues, but with a strong awareness on usability[5]. If someone would write up a good step-by-step guide for how to isolate one's web browser in a VM running on the same host, so that you can still get reasonable display performance but have a real separation boundary between the web browser and the rest of the system, I for one would be extremely grateful. The same technique would work for things like Skype. I'm sure it's possible, but I don't know enough about the various virtualization systems to be able to figure it out quickly, and I've yet to get interested enough to spend several days figuring out a method. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnwf1rwu@windlord.stanford.edu
Re: keybase.io
On Sat, Apr 05, 2014 at 12:45:53PM -0700, Russ Allbery wrote: If someone would write up a good step-by-step guide for how to isolate one's web browser in a VM running on the same host, so that you can still get reasonable display performance but have a real separation boundary between the web browser and the rest of the system, I for one would be extremely grateful. The same technique would work for things like Skype. I'm sure it's possible, but I don't know enough about the various virtualization systems to be able to figure it out quickly, and I've yet to get interested enough to spend several days figuring out a method. By all means, I'd love that. This is where I got to. Keith Packard assured me that running software in a nested X server like Xephyr is a way to prevent them from accessing the outside X session, and I considered it an interesting way of running skype, as a dedicated user, after checking that my home dir permissions are sound. Still, skype also wants access to hardware like a webcam, and I haven't yet felt like putting in effort to audit udev rules, and figuring out what having access to webcam hardware really allows one to do[1]. [1] Instinctively, that should only be get images out of the webcam; that wasn't the case for firewire[2]. Also, how is the LED light next to my webcam wired? Can the webcam be turned on leaving the LED switched off? [3] [2] And I grew up thinking that video hardware would just drive some video output, while nowadays on a Raspberry PI it'll read FAT filesystems on an SD card, parse config files and boot the system. [3] Anyway, there is no activity LED for the microphone. Can I have a panel applet thingie which shows if some process is reading from a microphone or webcam device? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: keybase.io
* Enrico Zini enr...@enricozini.org, 2014-04-05, 11:40: +1 russ. This is true of the dropbox daemon too. Are we to throw out DDs with dropboxd installed? Wine? ...skype, steam, flashplugin-nonfree[1]. Code git-cloned without checking signatures on tags[2] or doing some auditing[3]. Random cool vim plugins git pulled from random people on github with fancy selfies[4]. ssh -X or -Y to a remote host, then run X apps. Let me add this to the list: Copy anything from a web browser, and then paste it to a terminal application: http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinwyc/what_you_see_is_not_what_you_copy.txt -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405204522.ga1...@jwilk.net
Re: keybase.io
On Fri, Apr 04, 2014 at 07:27:36PM -0400, Paul R. Tagliamonte wrote: This is true of the dropbox daemon too. Are we to throw out DDs with dropboxd installed? Yes, please. We have too many apologists for non-free software as it is. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140406045746.ga9...@scru.org
keybase.io
keybase.io is a thing. This thing lets you, amongst other things, upload a copy of your PGP private key to their servers. This is client-side encrypted. Discuss. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140404135001.ga14...@bryant.redmars.org
Re: keybase.io
On Fri, Apr 04, 2014 at 02:50:01PM +0100, Jonathan Dowland wrote: keybase.io is a thing. This thing lets you, amongst other things, upload a copy of your PGP private key to their servers. This is client-side encrypted. Discuss. FWIU, the client-side encryption is javascript provided by the service so modifiable by the service at will and able to capture/transmit passphrase. DDs interested in this experimenting with this service are encouraged to NOT upload the PGP private key that is registered in the Debian Keyring. If you sign up for the beta and receive an invitation, please consider generating a new, independent PGP keypair for use with this service. For the Debian System Administration Team, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: keybase.io
Am Freitag, den 04.04.2014, 14:50 +0100 schrieb Jonathan Dowland: keybase.io is a thing. This thing lets you, amongst other things, upload a copy of your PGP private key to their servers. This is client-side encrypted. Discuss. Well, this thing raises several red flags just by reading upload ... private key. This alone smells very wrong, because I'm the opinion a private key must never leave my (trusted) system) Reading a little about it, e.g the issue tracker, they *require* the passphrase when you upload the key [1]. With that it is completly out of your control, and if it is client-side-encrypted, for what they need the passphrase in the first place? This makes only sense if they need to access the private key sometime, and then the client-side encryption is snake oil (and you never now if your should be better be recoveked) Also, some reading suggestion: https://github.com/keybase/keybase-issues/issues/489 Disclaimer: Just reading informations, did not try out smth to confirm the info) [1] https://github.com/keybase/keybase-issues/issues/489 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396621998.4155.8.ca...@ithilien.loewenhoehle.ip
Re: keybase.io
On Fri, Apr 04, 2014 at 04:33:18PM +0200, Tobias Frost wrote: Well, this thing raises several red flags just by reading upload ... private key. This alone smells very wrong, because I'm the opinion a private key must never leave my (trusted) system) More than that, it's good practice to never let the private half leave an offline machine, and use that offline high-entropy machine issue signing subkeys which you can take with you on your other machines. I'm not doing this, but it's good practice (and I should start once I can be bothered to generate new keys) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: keybase.io
Luca Filipozzi dijo [Fri, Apr 04, 2014 at 02:02:09PM +]: FWIU, the client-side encryption is javascript provided by the service so modifiable by the service at will and able to capture/transmit passphrase. DDs interested in this experimenting with this service are encouraged to NOT upload the PGP private key that is registered in the Debian Keyring. If you sign up for the beta and receive an invitation, please consider generating a new, independent PGP keypair for use with this service. Right, I strongly agree with Luca here. To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. Not that I will be checking for it (for now, at least). Not that I have even talked about it within the team. But I strongly think it's one of the duties of us as keyring maintainers. (Cc:ing for a reality check ;-) ) signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 03:24:27PM -0600, Gunnar Wolf wrote: Right, I strongly agree with Luca here. I do too To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* It helps my friends that are getting to know OpenPGP find my key, and it *can* be done without having the private half in there, which is the only problem. Thanks, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: keybase.io
Jonathan Dowland dijo [Fri, Apr 04, 2014 at 02:50:01PM +0100]: keybase.io is a thing. This thing lets you, amongst other things, upload a copy of your PGP private key to their servers. This is client-side encrypted. Discuss. As this thread was started at debian-private, I sent some of my replies there. But given Jonathan has moved this (thanks!) to a public list, I'll just copy my mail answering to him (along with his quoted text): Jonathan Dowland dijo [Thu, Apr 03, 2014 at 05:23:31PM +0100]: Sure! I'll try. Thanks a lot for your lengthy and interesting explanation! I think, what they are trying to do, is widen the base of people using PGP by providing tools to do so in browsers. I.e. lowering the barrier of entry. Right. This very first point is what makes me curious. I have been interested in finding user-friendly tools to manage encryption (and its different properties). Sadly, as the tools get better, I get further away from understanding what does a regular user want as a user experience. So my input on the field is less and less relevant ;-) (...) You can also associate yourself with twitter, github and your own personal website. For each method, you use the keybase client to generate some kind of challenge that proves you hold the PGP key that is associated with your keybase.io account, and post that challenge on the site: (...) Within keybase, you can 'track' people, which is a bit like following in a social network, but establishes a cryptographic relationship. I've followed a few folks so far. Right. So I'll now exhibit my ignorance on current day social habits. I understand people following each other on message-posting services, such as Twitter — If you are interested in what I say, you follow me. Or some models (FB) require relations to be bidirectional. But what is following in the context of jmtd.net? (I even struggle to understand social media on Github... I am interested in projects, not in people!) Being me a non-social-networkee, how would I interact with keybase, without caring for the people I supposedly follow? Or, OTOH, I understand this idenitifed your Twitter personna. Now, do you encrypt your tweets? Sign them? How much longer are your Twitter messages when you append a GPG-like signature to them? There's a keybase command-line client with which you can perform all of the above operations. There is also a bunch of stuff in their website, which I can't really use because I haven't uploaded my private key. (When I have time I will generate a new test key and upload that, replacing my real one - and breaking the auth of the twitter,github etc.) Right. What I like so far about this client is that it is *way* more natural (again, for users) than gnupg. And, of course, I expect different GUIs to follow. That can be interesting. Now, maybe this tool could be augmented with intelligence on how to relay a message in the best route possible. I mean, I see you can keybase encrypt jmtd -m 'a secret msg'. What does this give you? A message ready to cut+paste in your favorite form? Or does it get sent via the best possible route to jmtd? Say, maybe I can only establish a trusted path to your account via Twitter, then 'a secret msg' gets posted as three public jibberishy messages on Twitter (and only jmtd can decrypt them). Or does this tool just give you a gpg-signed text to cut+paste to your mail? The keybase web client supports signing, verifying, encrypting and decrypting messages to each other, via your PGP key. The process is done client side, and the key is crypted client side (aat least they say so. I haven't investigated properly), but the encrypted privkey is stored server side. Right. It is all done client side, but... Why does it have to store your private key server-side? signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 05:26:40PM -0400, Paul Tagliamonte wrote: On Fri, Apr 04, 2014 at 03:24:27PM -0600, Gunnar Wolf wrote: Right, I strongly agree with Luca here. I do too Likewise. To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* Likewise. I have signed up to keybase.io largely to kick the tires and see what I make of it. I will absolutely not be trusting any third party with the private half of my key on their servers, even if it's passphrase protected and the crypto carried out at the client side. J. -- Revd Jonathan McDowell, ULC | You non-conformists are all alike. signature.asc Description: Digital signature
Re: keybase.io
Jonathan McDowell dijo [Fri, Apr 04, 2014 at 10:35:41PM +0100]: To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* Likewise. I have signed up to keybase.io largely to kick the tires and see what I make of it. I will absolutely not be trusting any third party with the private half of my key on their servers, even if it's passphrase protected and the crypto carried out at the client side. Urgh... Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140404231813.gf85...@gwolf.org
Re: keybase.io
Gunnar Wolf gw...@gwolf.org writes: Urgh... Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? If Javascript running in a browser has access to your GPG secret key without you explicitly pasting it into the browser, I think you have larger problems -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2gw4r3c@windlord.stanford.edu
Re: keybase.io
+1 russ. This is true of the dropbox daemon too. Are we to throw out DDs with dropboxd installed? Wine? On Apr 4, 2014 7:23 PM, Russ Allbery r...@debian.org wrote: Gunnar Wolf gw...@gwolf.org writes: Urgh... Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? If Javascript running in a browser has access to your GPG secret key without you explicitly pasting it into the browser, I think you have larger problems -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2gw4r3c@windlord.stanford.edu
Re: keybase.io
[I trimmed the To down to -project because I think everyone on the CC is reading that; I certainly am so no need to explicitly CC me.] On Fri, Apr 04, 2014 at 05:18:13PM -0600, Gunnar Wolf wrote: Jonathan McDowell dijo [Fri, Apr 04, 2014 at 10:35:41PM +0100]: To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* Likewise. I have signed up to keybase.io largely to kick the tires and see what I make of it. I will absolutely not be trusting any third party with the private half of my key on their servers, even if it's passphrase protected and the crypto carried out at the client side. Urgh... Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? 2 separate points to make here (as well as the general point Russ and Paul have followed up with about what do we trust in general running on the same machine as your GPG key). Firstly, there are 2 parts to the client side code from keybase.io, as far as I'm aware[0]. The first is they have an in browser implementation which requires your GPG private key to be stored on their server, but has it passphrase encrypted and all of the actual use of the key is through client side browser Javascript. The second is they have a node.js based CLI tool which runs on your personal machine and uses a key stored locally. This actually calls out to GPG to do the crypto. The former I think is a bad idea (because it definitely involves giving keybase the private part of the key). The latter on the face of it sounds acceptable (as long as there's no part of the code that is directly manipulating the key or potentially sending it off machine) and doesn't seem to have any greater issue than anything else that might use a GPG installation. With regards to my particularly situation I have not used the keybase website from any machine that also has my private GPG available to it. This is largely a factor of the way I treat my key rather than any special precaution I have taken around keybase. Once I get my head around the horror of the keybase CLI client being npm tentacles and pulling in a bunch of random stuff that I'm not sure I fully trust I will examine that set of code to convince myself that it's not going to leak my key anywhere and potentially try it out. J. [0] I may be wrong about these and welcome corrections; I have not yet delved into the details of the service and its implementation. -- Evil will always triumph over | .''`. Debian GNU/Linux Developer Good, because Good is dumb.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: keybase.io
On Sat, Apr 05, 2014 at 12:57:50AM +0100, Jonathan McDowell wrote: 2 separate points to make here (as well as the general point Russ and Paul have followed up with about what do we trust in general running on the same machine as your GPG key). Sorry, I wrote that from my phone. My point was this attack vector (nonfree code running on the same machine as your OpenPGP key) taken to it's absolute extreme (wine, dropboxd) is still *not* grounds for automated removal from the keyring. Furthermore, the way *I* set up Keybase was to run the GnuPG commands they requested (clearsigning and decrypting), since they looked safe and sane (and paste the results back in a form. Firstly, there are 2 parts to the client side code from keybase.io, as far as I'm aware[0]. The first is they have an in browser implementation which requires your GPG private key to be stored on their server, but has it passphrase encrypted and all of the actual use of the key is through client side browser Javascript. The second is they have a node.js based CLI tool which runs on your personal machine and uses a key stored locally. This actually calls out to GPG to do the crypto. Thirdly, you can run raw (sane and short) GnuPG commands by hand in the terminal, pasting results back. The former I think is a bad idea (because it definitely involves giving keybase the private part of the key). The latter on the face of it sounds acceptable (as long as there's no part of the code that is directly manipulating the key or potentially sending it off machine) and doesn't seem to have any greater issue than anything else that might use a GPG installation. With regards to my particularly situation I have not used the keybase website from any machine that also has my private GPG available to it. I have, and I seriously doubt my key has been taken. This is largely a factor of the way I treat my key rather than any special precaution I have taken around keybase. Once I get my head around the horror of the keybase CLI client being npm tentacles and pulling in a bunch of random stuff that I'm not sure I fully trust I will examine that set of code to convince myself that it's not going to leak my key anywhere and potentially try it out. Aye. That half is Freely licensed, I believe. https://github.com/keybase/node-client Audits welcome, I'd very much like to be able to trust it. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: keybase.io
Russ Allbery dijo [Fri, Apr 04, 2014 at 04:23:03PM -0700]: Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? If Javascript running in a browser has access to your GPG secret key without you explicitly pasting it into the browser, I think you have larger problems Right. However, I guess that most uses of the app (other than sending a message saying yes I'm here, this is me) will require pasting the key. Or not? Keybase users, please enlighten me: What do you do with it besides just existing on teh graph? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405025649.gb86...@gwolf.org
Re: keybase.io
On Fri, Apr 04, 2014 at 08:56:50PM -0600, Gunnar Wolf wrote: Right. However, I guess that most uses of the app (other than sending a message saying yes I'm here, this is me) will require pasting the key. Or not? Keybase users, please enlighten me: What do you do with it besides just existing on teh graph? I'm not a keybase user; actually, oddly enough, I'm a bit of a critic (or rather, 1990s linux user) with my friends about it (RE: private half usage), so I've not been able to use all of it's features - I just think Keybase was getting a bad rap. Being on the graph is why I'm on it - so that people who do use the keybase CLI can talk about me (or rather: my Key) by the abstract (and easy to remember name) 'paultag'. That's about as far as it goes for me, so I don't know much more, but I wouldn't dismiss the graph as a trivial thing. A strong network effect in the OpenPGP world is nothing but great for us, again, even if this site isn't technically perfect (which I don't think anyone is claiming) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 08:15:10PM -0400, Paul Tagliamonte wrote: On Sat, Apr 05, 2014 at 12:57:50AM +0100, Jonathan McDowell wrote: 2 separate points to make here (as well as the general point Russ and Paul have followed up with about what do we trust in general running on the same machine as your GPG key). Sorry, I wrote that from my phone. My point was this attack vector (nonfree code running on the same machine as your OpenPGP key) taken to it's absolute extreme (wine, dropboxd) is still *not* grounds for automated removal from the keyring. I'm not disagreeing with that; I was agreeing that if you're going to argue about one piece of non-free code then where do you draw the line. What about my network interface firmware? My hard drive firmware? My BIOS? With my keyring-maint hat on I back Gunnar and Luca's statements that people should not be uploading the private part of their keys used for Debian work to the keybase website, and if I am made aware of any private keys in the Debian keyring that are on the site I will treat them as potentially compromised. I am not saying you shouldn't try the keybase website on the same machine as the key lives on, or examine the keybase CLI client, or run the GPG commands manually. At present I have no firm opinion about these actions. Furthermore, the way *I* set up Keybase was to run the GnuPG commands they requested (clearsigning and decrypting), since they looked safe and sane (and paste the results back in a form. I had not noticed that was an option. I've also examined these commands, decided they looked sane and pasted the output back into the form. Firstly, there are 2 parts to the client side code from keybase.io, as far as I'm aware[0]. The first is they have an in browser implementation which requires your GPG private key to be stored on their server, but has it passphrase encrypted and all of the actual use of the key is through client side browser Javascript. The second is they have a node.js based CLI tool which runs on your personal machine and uses a key stored locally. This actually calls out to GPG to do the crypto. Thirdly, you can run raw (sane and short) GnuPG commands by hand in the terminal, pasting results back. I hadn't noticed this was an option; thank you for making me aware of it. The former I think is a bad idea (because it definitely involves giving keybase the private part of the key). The latter on the face of it sounds acceptable (as long as there's no part of the code that is directly manipulating the key or potentially sending it off machine) and doesn't seem to have any greater issue than anything else that might use a GPG installation. With regards to my particularly situation I have not used the keybase website from any machine that also has my private GPG available to it. I have, and I seriously doubt my key has been taken. I agree, I don't think the code is going to maliciously try and steal my key, it just happens that the machines I run browsers on don't have access to my key by default. J. -- Web [ And you can't help my life. But you can hide the knives. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
