Add chrome PURL-TYPE

[mixmix]

This adds support for Chrome Browser Extensions

The examples I've given have been acquired sampling the chrome store through scraping + querying an updated "updatecheck" API that chrome itself uses to poll for updates

[pombredanne]

After the merge of PR #514, PURL types are now defined in JSON:

• See #514

With the new approach... we can then go either way:

1. you update your PR to use the new approach, OR
2. I/we will update your PR and merge so you do not bear the pain :angel:

If you do not reply, we will update! Thanks for your understanding !

[mixmix]

Thanks @pombredanne ! I've had a go reformatting this PR I added some tests, but was unclear how to run those. I ran make conf && make check and got some passes but then an Exit 1 with no error message so unclear how to improve

I also note README.dev.rst is perhaps out of date (there is no make docs or make generate)? I ran make gendocs

[mixmix]

Please feel free to take what's here and adjust it as you see fit. I'll look back here every few days to answer any questions too

Thanks for your work 🍍 🐟

[mixmix]

@pombredanne (or someone else), is there anything I can do to unblock merging this?

[pombredanne]

@pombredanne (or someone else), is there anything I can do to unblock merging this?

@mixmix Thanks! It would be awesome to have someone from Chrome to have a quick look on this. Could reach out there? @di gentle ping... you may be able to help too?

[mixmix]

I filed a "developer feature request" in this chrome_webstore/contact form

Hi I've filed a PR to register a Package URL (PURL) spec for Chrome Webstore packages. https://github.com/package-url/purl-spec/pull/522 I'd like to get input from the Chrome Webstore team to make sure the format I've suggested feels aligned.

I'm searched for other ways to contact that team but couldn't find any @pombredanne

[mixmix]

Response TL;DR ~= "message Chrome Extensions Google Group"

(full reply)

Hello Mix,

Thank you for contacting Chrome Web Store Developer Support.

In regards to your inquiry, as much as I'd like to provide the answer you're looking for, unfortunately I cannot give you a hard answer due to legal related matters.

I would stress that review is ultimately responsible for determining compliance and that we do not offer pre-submission assessments. It's generally best to implement the best solution that will make it work, and then if there's a problem with it after submitting then the review team will let you know. Please review the Chrome Web Store Program Policy and Developer Agreement and see if it contradicts any policies. Please see here regarding User Data.

In the meantime, I would highly recommend posting in our Chromium Extensions group. Members of Chrome's extensions development team and Product team also post there and answer developer and development related questions. They'll be able to offer some additional insights based on your use case. We greatly appreciate your understanding.

Kind regards,

Catherine

Chrome Web Store Developer Support

Message posted to group: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/jR7mqtIwQ3A

[patrickkettner]

Hiya! Patrick from the Chrome Extension team - happy to do whatever, but unsure what is being asked.

[mixmix]

Hi @patrickkettner I'm essentially asking if you can see any problems with the following as standard ways to reference chrome extensions as purls (package URLs):

• pkg:chrome/[email protected]
• pkg:chrome/[email protected]
• pkg:chrome/[email protected]
• pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk@1
• pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk < means latest

We have the chrome extensionId as the "name", because that's the UID. The version is non-semver, and I've chosen to support what is shown on the extension pages as a version, and what we see in the manifest.json. Internally I noticed you seem to normalize to something like \d+(\.\d+){0,3 (i.e. 1 to 4 dot-seperated numbers), but I've not used those because purls are going to be something user-entered often

[patrickkettner]

That all SGTM. The only thing that comes to mind is that similar to how nodejs can specify engines, extensions can set a minimum_chrome_version. Is it worthwhile to define qualifiers or anything like that to ensure the user isn't requesting a version that they can't use?

For what its worth, the Edge marketplace and mozilla add-on store would share identical logic to what you created

Regarding the note "There is currently no documented API for querying different versions of a package - there only seems to be responses on the latest version. To this end the version component of a chrome purl can be optional.", that is correct as of today (but in theory could change one day). Only the latest version of an item is publicly available, but specifying a URL may be a good way to ensure an update isn't unexpected?

[mixmix]

I think the idea of an engines query in interesting. Is this what the prodversion query is used to resolve on the updatecheck API? (we're guessing from the outside!). I think if that's what you're doing then adding support for engines could cool. Would love to hear from PURL maintainers if that's a pattern that's supported elsewhere (cc @pombredanne)

To be concrete @patrickkettner , would you expect the purl would then be something like

• pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk?engine=107.0.01 => the latest version that supports this

[mixmix]

Only the latest version of an item is publicly available, but specifying a URL may be a good way to ensure an update isn't unexpected?

@patrickkettner can you clarify more. Are you saying you think it would be good to NOT have pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk as a generic "references latest version" PURL, because it may lead to unexpected updates? I think I would normally agree, but it also seems chrome extensions do un-announced updates as the norm, so in this context discussing the latest is generally what you will be doing?

[mixmix]

@patrickkettner , polite bump on this ❤️

[patrickkettner]

Appreciate it!

think the idea of an engines query in interesting. Is this what the prodversion query is used to resolve on the updatecheck API?

Sorry, I think my suggestion was not clear. I was making an analogy between how nodejs has the engines field in package.json. This allows a project to say "only run this code in node version N.NN". In a similar manor, a Chrome Extension have the minimum-chrome-version, which lets a project say "this cannot run on versions of Chrome lower than N.N.N.N". I was suggesting that if someone was using the PURL, they may want to say something like "because I am in a deployment that must support ${OLDER_VERSION_OF_CHROME}, can I make sure that the extension is NOT going to break because of my chrome version?".

In practice this could look like

pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk?minimum_chrome_version=107.0.01

where the chrome extension being downloaded would only resolve if

• it has no minimum_chrome_version in it's manifest.json, or
• the version set in it's manifest.json minimum_chrome_version is less than or equal to the value specified (107.0.01)

Are you saying you think it would be good to NOT have pkg:chrome/dlpngalgnefjeiefhmpklpfiohadpglk as a generic "references latest version"

No, not saying that. I think for most people it works great. But for some folks that want extreme control, and they want to manually opt-in/review every update, that could be useful.

[mixmix]

I think your suggestion of minimum_chrome_version is interesting. I'm hesitant to add it to this spec without clarity about how/ whether this actually works with any of the google APIs at the moment.

A little scouting + experimenting surfaced:

1. In updatecheck API, varying prodversion gets you from results to no result...

• chose from this list over version tags
• very unclear what no results means, would need to test against a known long-running extension which has updated it's "minimum_chrome_version"?

2. Doesn't seems Chrome allows you to download old versions?

• maybe I missed a link, but I only found blogs talking about building your own from a Chromium Release at a tag?

I'd like to propose we shelve this (put "minimum_chrome_version" on hold) unless we can clarify if there is any feasible way for users to use it currently. Once there is, then we should definitely consider adding this. This would also allow us to proceed with merging this I hope

[patrickkettner]

Apologies for making this confusing.

minimum_chrome_version is not exposed as an API. It is a value in the manifest.json file of the CRX extension. If it was supported, the file would need to be parsed and that value extracted. There is no public API to download old versions of an extension. However using the minimum_chrome_version can prevent an extension from being updated if requested.

in short, your current existing proposal is good from my point of view.

[mixmix]

@pombredanne I think all outstanding comments/ question have been resolved on this @patrickkettner if you'd like to leave a review confirming your position on this that might help accelerate this getting merged