mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2021-03-16 15:12:33 -04:00
parent 7dabbe4520
commit 34a49661d4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 25 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/presence_of_AWS_creds_ruins_access_to_public_urls/comment_1_9222f76d21e8260327b4f127cc90782d._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2021-03-16T18:57:55Z"
content="""
git-annex initremote caches the AWS creds locally in a file
(.git/annex/creds/uuid) and that caching must be what's happening.
I suppose with an autoinit of this particular repo.
It may be that autoinit should avoid sucking in such information, since the
user may not expect it. And also what if two S3 repos were auto-initted,
probably the creds would only work for one. There is support in the API
that remotes could use to avoid such behavior during auto-init, but not
in the external special remote protocol.
The S3 remote currently always uses S3 protocol when there are creds,
even for read operations; when there are no creds it goes on to check if
it can determinte a public url, and uses that instead. If it instead
preferred public urls, your use case would work even with the creds.
Could break other use cases though, eg if there was a public url
recorded but it didn't work and the API did, also versioned repos maybe.
So not sure I like that second approach, it seems better to use the creds,
so long as the user knowingly provided them.
"""]]