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

be stricter about rejecting invalid configurations for remotes

Browse source 
This is a first step toward that goal, using the ProposedAccepted type
in RemoteConfig lets initremote/enableremote reject bad parameters that
were passed in a remote's configuration, while avoiding enableremote
rejecting bad parameters that have already been stored in remote.log

This does not eliminate every place where a remote config is parsed and a
default value is used if the parse false. But, I did fix several
things that expected foo=yes/no and so confusingly accepted foo=true but
treated it like foo=no. There are still some fields that are parsed with
yesNo but not not checked when initializing a remote, and there are other
fields that are parsed in other ways and not checked when initializing a
remote.

This also lays groundwork for rejecting unknown/typoed config keys.
This commit is contained in:
Joey Hess 2020-01-10 14:10:20 -04:00
parent ea3f206fd1
commit 71ecfbfccf
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
45 changed files with 395 additions and 224 deletions
Download patch file Download diff file Expand all files Collapse all files

11
doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment
View file

@ -6,18 +6,21 @@
I was thinking about implementing this today, but the shattered attack got
in the way. Anyway, it seems like most of a plan:
* Make RemoteConfig contain Old or New values. enableremote and initremote
set New values; Old values are anything read from git-annex:remote.log
* Make RemoteConfig contain Accepted or Proposed values. enableremote and initremote
set Proposed values; Accepted values are anything read from git-annex:remote.log
(update: done)
* When a RemoteConfig value fails to parse, it may make sense to use a
default instead when it's Old, and error out when it's New. This could
default instead when it's Accepted, and error out when it's Proposed. This could
be used when parsing foo=yes/no to avoid treating foo=true the same as
foo=no, which some things do currently do
(eg importtree, exporttree, embedcreds).
(update: Done for most yes/no and true/false parsers, surely missed a
few though, (including autoenable).)
* Add a Remote method that returns a list of all RemoteConfig fields it
uses. This is the one part I'm not sure about, because that violates DRY.
It would be nicer to have a parser that can also generate a list of the
fields it parses.
* Before calling Remote setup, see if there is any New value in
* Before calling Remote setup, see if there is any Proposed value in
RemoteConfig whose field is not in the list. If so, error out.
* For external special remotes, add a LISTCONFIG message. The program
reponds with a list of all the fields it may want to later GETCONFIG.