Private key in repository

[da2x]

https://github.com/haystack/tipsy/blob/5d68566/chrome-extension/key.pem

This must be removed. A new key must be generated. Anything relying on this key must be resigned with an actual private key.

Chrome Web Store will not allow you to update the extension in the store with a different key. The current extension cannot be updated, so please distribute a notice to existing users on how they can manually remove the current extension and install a new replacement extension.

[rht]

ACK

[karger]

If I understand correctly, there's no way to replace the signing key in an extension---we have to make a new extension with a new signing key---and get all current users to switch, which will be a mess.

Might it make sense to publish a new extension with secret signing key, but continue to update both the old and the new as code evolves? Although really we only want the new to be visible in the app store---can we hide the old while still giving current users the benefit of updates?

[da2x]

I’d recommend you publish a new extension with a new signature.

When that is done, you publish one last update to the old extension with messaging and links to the new extension. Maybe add a data export and import option? In the update, change the name and icon of the extension. X icon and "Tipsy (delete this extension)" for the name. That way people would easily tell the difference between the new and old (that should be deleted) in their extension manager.

You MAY get another answer if you contact Google. If I remember correctly, then Google actually replaces your key with their own as part of the publishing process. If that is the case, you may be able to get them to accept a new key. However, as your extension has less than 100 000 users, I would not expect Google to be at all interesting in making special accommodations.

[da2x]

See also purging a file from your git repository's history. The damage is already done, but removing the key would still be a good idea.

[rht]

If the course of action is to migrate the extension ID (refreshing the priv key), btw this sounds like a chance to bundle in some non-backward-incompatible changes (the storage db, for instance, while keeping the serialized data format intact).

If I remember correctly, then Google actually replaces your key with their own as part of the publishing process.

As much as this might the case, the generated priv key should still be derived from the uploaded .pem file. If I were google, I wouldn't put an extra rule (in a server that can be taken down) that allows patches such as to deny the old .pem and use the new .pem, yet in the end leaving the key field in the manifest file intact. It should be crypto from one end to another, as far as package signing is concerned. // Occam's razor

[tbranyen]

I've seen other extensions that are open source committing this key. Why exactly do we need to remove this? I understand privacy concerns, but what is the specific attack vector we are preventing by removing this key?

As far as I know Google has very strict publishing rights, so sure someone could sign and distribute a *.crx file as an imposter Tipsy, but they could do that already. Users should go through the Chrome webstore.

[karger]

In particular, you need to be able to log in to the publisher account to publish the extension, so knowledge of the extension key doesn't seem to create an attack vector.

…

On 02/15/2017 07:25 PM, Tim Branyen wrote: I've seen other extensions that are open source committing this key. Why exactly do we need to remove this. I understand privacy concerns, but what is the specific attack vector we are preventing by removing this key? As far as I know Google has very strict publishing rights, so sure someone could sign and distribute a |*.crx| file as an imposter Tipsy, but they could do that already. Users should go through the Chrome webstore. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#101 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFpXnBhEUqi_Vv2BWXSJbRFfUwJavqEks5rc5d8gaJpZM4MB95G>.

[rht]

(hmmm...one case: with DNS-spoofing, an attacker could redirect the user to a chrome webstore server with a correctly-signed-but-tampered package)

[da2x]

“The private key is used to sign each version of the extension and must be secured from public access. Be careful not to include your private key within your extensions!”
https://developer.chrome.com/extensions/packaging

[da2x]

http://www.computerworld.com/article/2504931/desktop-apps/yahoo-leaks-private-key--allows-anyone-to-build-yahoo-signed-chrome-extensions.html

[tbranyen]

Okay this part is worrying:

Google Chrome automatically checks for extension updates by querying update URLs specified by
developers. If attackers can forge the DNS (domain name system) responses received by the browser,
they can force it to install a rogue digitally signed extension update from a server under their control.

Since we're dealing with payments, it makes sense to lock this down. 👍 Thanks for the explanation!

[da2x]

Signed extensions can’t be sideloaded, but they can be side-upgraded. Signed extensions can also access data from other extensions signed with the same key. (Not sure if this was only in dev or if this feature ever made it to public builds.)

[da2x]

I’m not being a dick on purpose. 😝
Private keys are private for a reason.