Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

self-update could recognize a personal GitHub token for higher rate limits #3738

Open
n8henrie opened this issue May 4, 2022 · 1 comment
Labels
type: feature enhancement improving existing features

Comments

@n8henrie
Copy link

n8henrie commented May 4, 2022

Output of restic version

restic 0.13.0 compiled with go1.18 on linux/amd64 

What should restic do differently? Which functionality do you think we should add?

restic self-update should optionally accept a personal GitHub token (via flag or env var) to increase the rate limit and avoid users getting the inability to update. Apparently someone sharing my IP has made enough requests that I can't update from 0.13 to 0.13.1 with the built-in mechanism.

What are you trying to do? What problem would this solve?

./restic self-update
writing restic to /home/restic/bin/restic
find latest release of restic at GitHub
Fatal: unable to update restic: unexpected status 403 (403 Forbidden) returned, message:
  API rate limit exceeded for 2XX.REDACTED. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

Did restic help you today? Did it make you happy in any way?

Absolutely! Found more silent corruption issues (#1999) that otherwise would have gone unnoticed, and now it looks like debug examine is (maybe?) merged into master and available in 0.13.1 (af3de70) so I don't have to do my own debug build this time! This kind of silent corruption might have just gone noticed with a less meticulous program -- thank you restic devs!

@MichaelEischer MichaelEischer added the type: feature enhancement improving existing features label May 7, 2022
greatroar added a commit to greatroar/restic that referenced this issue Jun 6, 2022
When given a buf that is big enough for a compressed blob but not its
decompressed contents, the copy at the end of LoadBlob would skip the
last part of the contents.

Fixes restic#3738.
@andreaso
Copy link
Contributor

andreaso commented Jun 12, 2022

So, here is what the absolute minimal solution would look like, where I simply hard coded a GitHub Access Token.

diff --git a/internal/selfupdate/github.go b/internal/selfupdate/github.go
index 637f6765..4372b242 100644
--- a/internal/selfupdate/github.go
+++ b/internal/selfupdate/github.go
@@ -60,6 +60,7 @@ func GitHubLatestRelease(ctx context.Context, owner, repo string) (Release, erro
 
        // pin API version 3
        req.Header.Set("Accept", "application/vnd.github.v3+json")
+       req.Header.Set("Authorization", "token ghp_SecretSecretSecret")
 
        res, err := ctxhttp.Do(ctx, http.DefaultClient, req)
        if err != nil {
@@ -119,6 +120,7 @@ func getGithubData(ctx context.Context, url string) ([]byte, error) {
 
        // request binary data
        req.Header.Set("Accept", "application/octet-stream")
+       req.Header.Set("Authorization", "token ghp_SecretSecretSecret")
 
        res, err := ctxhttp.Do(ctx, http.DefaultClient, req)
        if err != nil {

UI wise, do we need/want a proper flag for the GitHub Access Token, or are we fine with just an environment variable?

Personally I'm leaning towards the latter, given that proving an Access Token here is hardly ever needed, and nothing we want to risk encouraging people to do unless they actually really need to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature enhancement improving existing features
Projects
None yet
Development

No branches or pull requests

3 participants