Unable to connect to repo using Gitlab Access Token

[desandy]

Does cargo-crev support the use of Gitlab Access tokens?

cargo crev id new --url username:token@url

When I do, I get the following error:

Couldn't clone https:username:token@url remote authentication required but no callback set; class=Http (34)

I can successfully clone the same repo using git and that format.

[dpc]

We probably need a wiki page around initial cloning issues.

cargo crev id new is expecting your public url so you don't want to put tokens in there. Generally you want to use public url initially, and then possibly tweak the details of pushing to it with git crev repo git ...

[desandy]

Thank you very much! Would you be able to provide a full example of how that would work? We are configured to use access tokens for Gitlab, but, I need to create a crev ID.

…

On Tue, Mar 16, 2021 at 12:01 PM Dawid Ciężarkiewicz < ***@***.***> wrote: We probably need a wiki page around initial cloning issues. cargo crev id new is expecting your public url so you don't want to put tokens in there. Generally you want to use public url initially, and then possibly tweak the details of pushing to it with git crev repo git ... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD2H73YK7CLZ3PKZDOMH3DTTD6FHRANCNFSM4ZIOHEGA> .

[dpc]

So first you want to run cargo crev id new --url <publicurl> . <publicurl> is whatever other developers / general public is supposed to use to clone the repository with proofs. URL with RO access.

Then you can use cargo crev repo git ... just like you would use normal git command to setup how to push things. So something like cargo crev repo git remote set-url origin https://scuzzlebuzzle:<MYTOKEN>@github.com/scuzzlebuzzle/ol3-1.git (adapted from some SO answer).

After that cargo crev publish should use the https + token access, while all other users will use <publicurl> to download updates from a given public identity (url).
`

[desandy]

Thank you so very much!

So first you want to run cargo crev id new --url . is whatever other developers / general public is supposed to use to clone the repository with proofs. URL with RO access.

This confuses me. The publicurl would be our Gitlab repo with the access token requirement? Would we need another repo?

One final question, when other developers need to pull down crev reviews from the same repo that uses Gitlab tokens, will they have any issues using cargo crev repo fetch or cargo crev update?

My apologies, but, this is very new to me.

[dpc]

This confuses me. The publicurl would be our Gitlab repo with the access token requirement? Would we need another repo?

You'll be creating reviews that other people should be able to download. Either general public or company wide. Ideally this URL should not require an access token. Is the problem here that you require access token even for cloning such repo.

If that's the case we might need to work on some ways to support such a usecase. But I would advise to create some form of a read-only view into that repo. All the information in it is semi-public. Even if you don't want to share it with general public, there still not going to be anything all that secret or propriaty in there. Unless you put that accesstoken in there of course, which we want to avoid.

[dpc]

The url we're talking about is this one https://github.com/dpc/crev-proofs/blob/0ca8ee7d01637bc0fa3dfc6381e10aa7e01b10d2/FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE/reviews/2018-12-packages-Ua7DxQ.proof.crev#L7 (example from my repo).

As you can see it is put in there in every proof I create, so it's not desirable to put any secrets in there.

[dpc]

There is a --nourl option for ID creation, but it's new and I'm not sure how far it is possible to make it work.

[desandy]

Ok. So, I am told that the repo is now "public", although it is only accessible to our own company, and available via HTTPS.
However, I continue to receive the same error when I attempt to setup a new id.

Couldn't clone https:<company url> remote authentication required but no callback set; class=Http (34)
Any suggestions on how to debug this issue? As I stated earlier I can clone the repo using git clone successfully.

Our repo is behind a VPN if that makes a difference.

The idea here is to have a crev repo that is only accessible to our internal network. We would love to use cargo-crev for this if we can get this to work.

[dpc]

Hmmm... remote authentication required but no callback set suggests that authentication is required still.

but no callback set suggest that in the libgit2 library we could set a hook and actually ask for the creds to use . https://docs.rs/git2/0.13.17/git2/struct.RemoteCallbacks.html#method.credentials maybe. Ping @kornelski for awarness.

@desandy can you double check that manual git clone https://publicurl works without asking for anything?

[kornelski]

The repo URLs related to a Crev ID are considered public information. They will be attached to reviews you make and everyone will be able to see this URL. Do not put any auth in your Crev ID's URL. It will leak!!!

[kornelski]

--no-url only allows creation of a temporary Crev ID with no known URL, but it doesn't remove URL requirement. You will be forced to add a URL as soon as you use any feature related to URLs.

[kornelski]

I've removed the --no-url option completely, and updated help to clarify that all URL options only accept public HTTPS URLs. URLs that aren't publicly-readable by anyone are not supported.

[dpc]

@kornelski Any idea how to support teams that want to use crev internally and don't want to (maybe yet) publish these proofs? It might be quite common for them to use e.g. ssh urls for everything.

[kornelski]

On a technical level, we'd need to support auth in git, but AFAIK ssh auth in libgit2 is unreliable anyway. Cargo itself routinely relies on git-fetch-with-cli fallback option. We may need to add a similar fallback. I think it'd be worth implementing git cli fallback in a separate crate, as an extension trait for git2, because crates-index crate also needs this.

From project perspective, I have mixed feelings about supporting private Ids:

• private reviews of public crates.io crates aren't helping the community. I want to encourage sharing them. Is there a strong case for keeping them secret?

• if someone has private crates I understand they'd like to keep their reviews private, but I'm not sure if that's a good use of crev. Companies usually just do regular code reviews and have internal trust/permission structure. Why mix WoT into this?

[dpc]

private reviews of public crates.io crates aren't helping the community. I want to encourage sharing them. Is there a strong case for keeping them secret?

It does expose which libraries you reviewed, so which ones you might be using in which versions. Some companies might be scared of that. And better have people use something internally than not at all, IMO. If they want to share (which we encourage) I doubt trying to force them via technical limitations will do much to reach that goal. Developers might get familiar with crev because they used it internally, and then spread knowledge and use it for benefit of the community elsewhere.

Why mix WoT into this?

I think even for purely internal stuff crev will save a lot of hassle developing procedures and tooling, etc., given it simple yet flexible model.

I think supporting ssh is not most necessary, but maybe we could have an option to put a different URL into the publicid, and different into remote of local git repo. Maybe we could even just always strip the pass part from any http(s)://user:pass@... urls ... , and use pass only for git repo. This way cargo crev id new --id <http://user:pass@rest> will just work, people will not accidentally leak their tokens, and companies can put that command in their internal documentation, etc. and things will just work for everyone.

The "not leaking secrets" part seems particularly beneficial. At very least we should probably detect it and print an error to warn them and point to whatever steps they should take to get what they need working.

[desandy]

Hello, I completely understand your concern about sharing reviews. However, some business models have the need for such secrecy. Financial institutions, cryptocurrency platforms -- really any organization that deals primarily with currency fall into this category. Those in that category must mitigate the risk associated with information disclosure regarding specific technologies and crate usage, in addition, any comments regarding compatibility with internally created solutions would be disastrous. Code reviews are essential but I believe that cargo-crev could be used as an essential part of an internal trust structure for Rust dependencies. Supply-chain attacks and weaknesses have been shown to have devastating consequences, and I believe that cargo-crev is missing an opportunity to lend itself to this critical area by only supporting public repositories. While internal usage would limit publishing crate reviews to an internal network, existing reviews available to the public would certainly be helpful. Thank you for taking the time to consider my request and I hope that made sense.

…

On Fri, Mar 19, 2021 at 4:24 PM Kornel ***@***.***> wrote: On a technical level, we'd need to support auth in git, but AFAIK ssh auth in libgit2 is unreliable anyway. Cargo itself routinely relies on git-fetch-with-cli fallback option. We may need to add a similar fallback. I think it'd be worth implementing git cli fallback in a separate crate, as an extension trait for git2, because crates-index crate also needs this. From project perspective, I have mixed feelings about supporting private Ids: - private reviews of public crates.io crates aren't helping the community. I want to encourage sharing them. Is there a strong case for keeping them secret? - if someone has private crates I understand they'd like to keep their reviews private, but I'm not sure if that's a good use of crev. Companies usually just do regular code reviews and have internal trust/permission structure. Why mix WoT into this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD2H73YLYCLSAUBCC7L3TQ3TEO6JVANCNFSM4ZIOHEGA> .