> That is true but to me the main point is that if there is malicious > code running within your desktop machine, you have bigger problems > than your Launchpad account.
Sure; the question I'm trying to answer is whether malicious code running on your desktop machine also means bigger problems for lots of innocent people. > Can you unpack the logic there? Do you mean that if malicious code > gets onto an Ubuntu system of a user who can write to the main archive > or a popular PPA, it can propagate to thousands of other machines. > That is true, but orthogonal to whether there is an API to manipulate > credentials. I'm not sure what you mean by "API to manipulate credentials". I don't know whether you mean "API to upload a new GPG key" or "API to create a new OAuth token without user input". Forgive the verbiage that follows; I want to be really precise about this. Let's take Bob to be a user who can write to the main archive of a popular PPA, and let's stipulate that Bob has malware on his computer. OK, what are the scenarios? 1. The current scenario. There is no API to upload a new GPG key and no API to create a new OAuth token. Can the malware on Bob's computer reproduce itself in the PPA? I guess, but it would have to include a keylogger (to sniff the passphrase to Bob's existing GPG key) or something fairly sophisticated. 2. There is an API to create a new OAuth token, but no API to upload a new GPG key. This is identical to scenario #1. The malware can exploit the API to create new OAuth tokens for itself, but it can't use the API to do what it really wants to do--reproduce. 3. There is an API to upload a new GPG key, but no API to create a new OAuth token. Now an exploit is trivial. The malware can grab Bob's existing OAuth token, impersonate one of his other applications, and upload a new GPG key. We can stop this from working by making "upload a new GPG key" require a single-purpose, one-use OAuth token. 4. There is an API to upload a new GPG key, and an API to create a new OAuth token. Now it doesn't help to require a single-purpose, one-use OAuth token, because the malware can create new OAuth tokens whenever it wants. The only way to plug the trivial exploit is to prohibit "create a new OAuth token" from creating the kind of OAuth token that can be used to upload a new GPG key. If we take the hard line that once there's malware on your system, you're screwed, then all four of these scenarios are identical--the difference between "fairly sophisticated exploit" and "trivial exploit" is not worth considering. I don't know if this is what you mean by "[The existence of an exploit] is orthogonal to whether there is an API to manipulate credentials." Is it? If we take this hard line, then there's no reason to make WRITE_SENSITIVE_DATA tokens temporary or prohibit the OAuth token generator from generating them--we're just making the malware's job marginally easier. I think users are likely to need WRITE_SENSITIVE_DATA fairly rarely, so I don't have a problem with requiring these tokens to be acquired through the web browser. But: 1. The reaction to 'tokens through the web browser' has been incredibly negative. Others have spent a lot of time hacking around it, and I've spent a lot of time trying to broker and implement a compromise. Reintroducing the browser at (what will appear to the end-user as) random intervals isn't good for the user experience--you could argue it's worse than our current strategy of using the browser all the time. 2. If we really consider scenario 4 and scenario 1 equally insecure, we might as well go for the superior usability of scenario 4. Leonard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
