> > > On May 20, 2016 10:22 AM, Francois Beutin wrote: > > > We (Ensimag students) plan to implement the "remote whitelist/blacklist" > > > feature described in the SoC 2016 ideas, but first I would like to be > > > sure > > > we > > > agree on what exactly this feature would be, and that the community sees > > > an > > > interest in it. > > > > > > The general idea is to add a way to prevent accidental push to the wrong > > > repository, we see two ways to do it: > > > First solution: > > > - a whitelist: Git will accept a push to a repository in it > > > - a blacklist: Git will refuse a push to a repository in it > > > - a default policy > > > > > > Second solution: > > > - a default policy > > > - a list of repository not following the default policy > > > > > > The new options in config if we implement the first solution: > > > > > > [remote] > > > # List of repository that will be allowed/denied with > > > # a whitelist/blacklist > > > whitelisted = "http://git-hosting.org"; > > > blacklisted = "http://git-hosting2.org"; > > > > > > # What is displayed when the user attempts a push on an > > > # unauthorised repository? (this option overwrites > > > # the default message) > > > denymessage = "message" > > > > > > # What git should do if the user attempts a push on an > > > # unauthorised repository (reject or warn and > > > # ask the user)? > > > denypolicy = reject(default)/warning > > > > > > # How should unknown repositories be treated? > > > defaultpolicy = allow(default)/deny > > > > > > > > > Some concrete usage example: > > > > > > - A beginner is working on company code, to prevent him from > > > accidentally pushing the code on a public repository, the > > > company (or him) can do: > > > git config --global remote.defaultpolicy "deny" > > > git config --global remote.denymessage "Not the company's server!" > > > git config --global remote.denypolicy "reject" > > > git config --global remote.whitelisted "http://company-server.com"; > > > > > > > > > - A regular git user fears that he might accidentally push sensible > > > code to a public repository he often uses for free-time > > > projects, he can do: > > > git config remote.defaultpolicy "allow" #not really needed > > > git config remote.denymessage "Are you sure it is the good server?" > > > git config remote.denypolicy "warning" > > > git config remote.blacklisted "http://github/personnalproject"; > > > > > > > > > We would like to gather opinions about this before starting to > > > implement it, is there any controversy? Do you prefer the > > > first or second solution (or none)? Do you find the option's > > > names accurate? > > > > How would this feature be secure and made reliably consistent in managing > > the > > policies (I do like storing the lists separate from the repository, btw)? > > My > > concern is that by using git config, a legitimate clone can be made of a > > repository with these attributes, then the attributes overridden by local > > config on the clone turning the policy off, changing the remote, and > > thereby > > allowing a push to an unauthorized destination (example: one on the > > originally intended blacklist). It is unclear to me how a policy manager > > would keep track of this or even know this happened and prevent policies > > from being bypassed - could you clarify this for the requirements? > > > > Cheers, > > Randall > > > > -- Brief whoami: NonStop&UNIX developer since approximately > > UNIX(421664400)/NonStop(211288444200000000) > > -- In my real life, I talk too much. > > > > I agree that we cannot have a completly secure and reliable > way to forbid a push to the wrong remote. This is not what > our feature is trying to do, we assume that if a programmer > tweaks his config file and changes the rules he knows what > he is doing and we won't try to prevent it. > Our goal is to implement a safeguard against accidental push, > the feature will work only if the programmer wants it to. In the end we decided to implement the first solution described above. We chose this version because we think there could have been conflicts between the global and local config files. Moreover, we think using two different lists for denied/allowed remotes is more intuitive and user-friendly, and it will allow the user to use "advanced" options such as: denied = "http://git-hosting.org"; allowed = "http://git-hosting.org/exception-repo"; to deny a push to git-hosting.org EXCEPT to git-hosting.org/ exception-repo We are unsure about the behavior to adopt in case of a conflicting config file (for example a remote is in both the allowed and the denied lists). The programm would print a warning message and: - follow the defaultpolicy OR - ask for confirmation OR - reject the push As of now we are inclined to implement the "ask for confirmation" option. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html