[build2] Using ssh-git

[Bo Lorentsen]

On 11/01/2018 12:43 PM, Boris Kolpackov wrote:
> Bo Lorentsen <bl at lue.dk> writes:
>
>> $ bpkg -v rep-info ssh://git-codecommit.eu-central-1.amazonaws.com/v1/repos/phoenix
>>
>> $ bpkg -v rep-info https://git-codecommit.eu-central-1.amazonaws.com/v1/repos/phoenix
>>
>> My focus will have to be using https as git schema and then find a way to
>> handle credentials in a sane way.
>>
>> I normally use git credential store, and this needs to be set for each new
>> cloning, in the local repo. And as I understand it, bpkg will make a clone
>> (smart if possible), but by doing that it (git) also will prompt for
>> credentials, on every clone attempt (for aws https at least).
> I would like to better understand in what situations you would want
> authorized access to a repository and if we need better support for
> this.
>
> Just to make sure we are on the same page, the above commands query
> a git repository as a version control-based package repository. In
> other words, with bpkg the use of a repository is always read-only.
> In particular, you would not be using this type of access as a way
> to develop the packages (i.e., commit changes) in this repository
> (for that you would normally clone the repository yourself and then
> use bdep instead of bpkg).
This is the case, i like to make package repositories on a closed git, 
and in order to edit this packages I need to use a different git 
cloning, as the repos in the eyes of bpkg is readonly.
> So normally with bpkg a version control-based package repository
> is accessed via a public, read-only URL that does not require
> authorization. But I guess if you want to keep your repository
> private (e.g,. because it is internal to your company), then you
> would need authorization. Is that your use-case? If so, which
> access (ssh or https) is preferable? We probably can add support
> for the ssh:// scheme fairly easily.
This is the case !

If i make a package repository on lets say github, https is super simple 
to use and by all means the preferred.

That would also be the case for AWS, as inserting credentials in the 
URL's could be seen as a fair compromise (as Karen suggested). But 
normally we do not like credentials in the url, and we store these in a 
git credential store, and here starts some of the fun.

The reason that ssh would be nice here, is the fact that once the ssh 
rsa key are in place, on the developer system, the credential situation 
are much more easy to handle (on aws at least), as it works along with 
whatever other ssh communication and git in the dev clones. So even if I 
use bpkg do fetch a rw version of my repos, i understand that it will 
only be readonly to bpkg, and I hope i will not be silly enough to try 
to use it as a dev repos afterwards, but save changes for another clone 
of the package :-)

So, ssh git was only to make it easy to clone when rsa key is already in 
place, anyway.

I think that I will go for the credential in url version, as Karen 
suggested, and just hope that one day I can use ssh as an alternative.

I also think the URL version are more robust when scaling up in a larger 
company, as we could make a key that only have specific readonly access 
to a given set of git repos ARN's. That way the revealed key and 
password is not that sensitive having floating around in all kind of 
manifest files :-)
>
> Yes, the flexibility/complexity tradeoff is the curse of C++ which
> unfortunately also extends to its tooling.
You are right, and build2 are also trying hard to bring all kind of 
things together, and the potential in using the new c++ modules, and a 
streamlined combined build and package system, really make it possible 
to make c++ a much more modern and friendly platform (like glue). So I 
guess, I just need to read on and get my head around it eventually :-)

/BL