proxied exporttree=yes versionedexport=yes remotes are not untrusted

This removes versionedExport, which was only used by the S3 special
remote. Instead, versionedexport=yes is a common way for remotes to
indicate that they are versioned.
This commit is contained in:
Joey Hess 2024-08-08 15:13:12 -04:00
parent 5c36177e58
commit 3ea835c7e8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
16 changed files with 23 additions and 53 deletions

View file

@ -189,8 +189,9 @@ the special remote can reply with `UNSUPPORTED-REQUEST`.
a list of settings with descriptions. Note that the user is not required
to provided all the settings listed here. A block of responses
can be made to this, which must always end with `CONFIGEND`.
(Do not include settings like "encryption" that are common to all external
special remotes.)
(Do not include config like "encryption" that are common to all external
special remotes. Also avoid including a config named "versioning"
unless using it as desribed in the [[export_and_import_appendix]].)
* `CONFIG Name Description`
Indicates the name and description of a config setting. The description
should be reasonably short. Example:

View file

@ -153,13 +153,6 @@ support a request, it can reply with `UNSUPPORTED-REQUEST`.
Indicates that `IMPORTKEY` can be used.
* `IMPORTKEYSUPPORTED-FAILURE`
Indicates that `IMPORTKEY` cannot be used.
* `VERSIONED`
Used to check if the special remote is versioned.
Note that this request may be made before or after `PREPARE`.
* `ISVERSIONED`
Indicates that the remote is versioned.
* `NOTVERSIONED`
Indicates that the remote is not versioned.
* `LISTIMPORTABLECONTENTS`
Used to get a list of all the files that are stored in the special
remote. A block of responses
@ -178,10 +171,9 @@ support a request, it can reply with `UNSUPPORTED-REQUEST`.
block of responses. This can be repeated any number of times
(indicating a branching history), and histories can also
be nested multiple levels deep.
This should only be used when the remote supports using
"TRANSFER RECEIVE Key" to retrieve historical versions of files.
And, it should only be used when the remote replies `ISVERSIONED`
to the `VERSIONED` message.
This should only be a response when the remote supports using
"TRANSFER RECEIVE Key" to retrieve historical versions of files,
and when "GETCONFIG versioning" yields "VALUE TRUE".
* `END`
Indicates the end of a block of responses.
* `LOCATION Name`

View file

@ -33,22 +33,6 @@ Planned schedule of work:
* Working on `exportreeplus` branch which is groundwork for proxying to
exporttree=yes special remotes. Need to merge it to master.
* Versioned exports are not untrustworthy. But checking that for a proxied
remote would need to construct a Remote using the special remote's config.
For eg S3 (the only versioned one currently), that would need the S3
creds to be set in the environment.
For an external special remote that uses the (currently draft) extension,
the program would need to be installed to check how it responds to
VERSIONED.
Constructing a special remote in order to use it proxied does not seem
feasible.
versionedExport could be changed be a pure function from
ParsedRemoteConfig. But that would not help with external special remotes.
## completed items for August
* Special remotes configured with exporttree=yes annexobjects=yes