Thanks Christian for your response. Le 11/05/2016 12:16, Christian Schwede a écrit : > Hi Fabien, > > thanks for sharing your ideas! > > On 11.05.16 11:53, Fabien Boucher wrote: >> * to create an unique key pair for each repository to replicate >> * to push the private key on SF >> * modify the .ssh/config of the Gerrit user >> * use an alias in the replication.config file >> * to restart Gerrit > > IIRC this is the way others do it as well? Using deploy keys is also the > recommended way by Github, and I think we should follow that one - but I > agree it's cumbersome today in SF and we should try to improve this. > >> It is really cumbersome. We tried to mitigate the overhead via the >> REST API of managesf but as you know it does not work so well and >> thus I'm removing that API endpoint atm. >> >> Playing yesterday with Github I've figured out we should not >> recommend the usage of the deploy key feature of Github (because to >> complex to handle SF side) but instead ask the user: > > If it's too complex on our side today, we should try to improve it > further - IMO that's the benefit of SF, making difficult things easier. > >> * to register the Gerrit's public key inside the owner' keys list or >> inside one of collaborator's keys list here >> https://github.com/settings/keys. In other term someone (a Github >> user) should authorize SF to push on his behalf and SF will inherits >> of the write rights of this user. But there is drawbacks as SF will >> be able to act on other repoq owned by the Github user ... > > Well, I think this is a no-go. For example, if you have some private > repos not maintained by SF you can't use SF anymore. I also don't want > to grant full access to all my repos to any SF instance. > >> * or other suggestion is to recommend the creation of a specific >> Github user with the Gerrit public key registered. This specific user >> should be configured as collaborator or owner of the repositories SF >> will replicate. But the issue here is how to register that specific >> user: SF need its own mail recipient ... > > There can be only a single Github user with that key (because each key > has to be unique in Github), and now this Github user must maintain all > repos that SF wants to replicate.That makes it very difficult if
Yes only one (the Github identify of a SF deployment). > several independent teams or users want to use SF - each of them will > now need their own SF instance. That is a huge overhead then. I didn't get you because today that's the case several teams use our SF deployment with the replication setup and the use of the deploy keys. All the keys are inside the SF node and I did see the benefit to have a bunch of deploy keys instead of only one. > For example, the Gerrit public key is already registered by someone, and > now I want to manage some of my projects using SF. Then I need to figure > out which Github user I need to add as a collaborator, but this might be > not what I want - because it can be misused easily. This Github user is created by the SF admin (manually), it has an username and it is up the repo owner to add this username as a collaborator with write access. > > I don't have a better idea, but not using the Github deploy keys sounds > like a regression. What I propose is just recommendation that could land in the SF documentation. The use of deploy keys can still be used with the on going refactoring, but I haven't wrote any helper scripts. So key provisioning, ssh config change, gerrit restart should be done manually by an admin. Fabien _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
