Skip to content

Loading…

Consider not storing lists assets on Github #84

Closed
ghost opened this Issue · 3 comments

1 participant

@ghost

As their policy does not encourage it. As more people starts to use uBlock, you might end up with a disabled repository.

https://github.com/blog/1482

Or uBlock could download directly from the original source.

@gorhill

If I link directly to the source, I lose the ability to download only what changed -- this is detected through https://github.com/gorhill/uBlock/blob/master/assets/checksums.txt, and the ability to ensure that the resource was downloaded properly.

I can see there could be a problem if ever the extension become way more popular than I expect. Now I am worried.

I suppose I should fix #6 asap, so that the infrastructure to download the lists from other sources exists. For the critical resources though, I need to still rely on the above checksums.txt file and download directly from Github -- but these critical resources are either small (ex. https://github.com/gorhill/uBlock/blob/master/assets/ublock/filter-lists.json), or either change rarely (ex. https://github.com/gorhill/uBlock/blob/master/assets/thirdparties/publicsuffix.org/list/effective_tld_names.dat).

Thinking about it, I could update the resources every day, and reflecting the result in the checksums.txt file, but download from original sources and still validate the downloaded result against the checksum entry on Github.

@gorhill

Ok, I think I will address this the following way:

The checksums.txt is too useful, I will still rely on it. Aside ensuring download went well, it allows to download only what is changed, so it does save bandwidth for both sides (I could improve this to further download only what is used).

For each resource found to have a new version, the original source URL version will be tried first. If there is an error, or if the checksum doesn't match, the Github repository will be tried. If this also fails (network, error), the current cached copy will be used (that's the current behavior), and if there is no cached copy, the install copy is used (that's the current behavior).

@gorhill gorhill added the fixing label
@gorhill gorhill added a commit that referenced this issue
@gorhill gorhill this is for #84, #70, #53, #36 b82742d
@gorhill gorhill removed the fixing label
@gorhill

Fixed in 0.2.3.2.

@gorhill gorhill closed this
@yfdyh000 yfdyh000 pushed a commit to yfdyh000/uBlock that referenced this issue
@gorhill gorhill this fixes #84 e16dac9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.