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. ----- Mail original ----- > De: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> > À: "Francois Beutin" <beutinf@xxxxxxxxxxxxxxxxxxxxxxx>, git@xxxxxxxxxxxxxxx > Cc: "matthieu moy" <matthieu.moy@xxxxxxxxxxxxxxx>, "simon rabourg" <simon.rabourg@xxxxxxxxxxxxxxxxxxxxxxx>, "wiliam > duclot" <wiliam.duclot@xxxxxxxxxxxxxxxxxxxxxxx>, "antoine queru" <antoine.queru@xxxxxxxxxxxxxxxxxxxxxxx> > Envoyé: Vendredi 20 Mai 2016 16:22:17 > Objet: RE: [Opinion gathering] Git remote whitelist/blacklist > > 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. > > > > -- 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