Coprorate repositories in Azure DevOps cannot be cloned

[PowellDean]

I am trying to clone a repository stored in my company's Azure DevOps subscription. I receive the following error message:

Error
Error: The object long-string-of-random-characters-snipped could not be decoded or wasn't found.

I receive the same error trying both SSH and HTTPS addresses. I am able to clone my personal GitHub and Codeberg repositories with no issue.

Is this an Azure DevOps security issue?

[Byron]

Thanks a lot for reporting!

It's a known issue with the way gitoxide, the crate that clones repositories, handles packs that "shouldn't be". All the details are in the tracking issue, but in short, a fix means to provide an entirely new and in all likelihood slower implementation of cloning which is more similar to the one Git uses.

Is this an Azure DevOps security issue?

Definitely not.

[PowellDean]

Thanks for the quick reply. I completely understand the "probably won't fix" rationale given in the linked issue. I am also aware the workaround is to just clone the repository locally and import it (which I can confirm did work). Unfortunately, in a corporate setting such as the one I'm in, the word "workaround" for a fundamental function like cloning a remote will kill any chance I have of introducing the tool.

You can close the issue if you like. I won't be able to proceed any further with test-driving the application.

It's an interesting tool though. Thanks for the opportunity to look at it.

Best Regards,
Dean Powell
Edmonton, Canada

[Byron]

Thanks for the kind words!

The issue should stay open as I believe it will be fixed eventually, and I hope your next test will be more successful :).

[Caleb-T-Owens]

🤔 We could move from gitoxide to shelling out to the git executable like we do with fetch and push. It would allow us to also make use of askpass for SSH keys with passwords

[Byron]

🤔 We could move from gitoxide to shelling out to the git executable like we do with fetch and push.

Yes, definitely. Since the current implementation also doesn't use progress or can be interrupted, it's not very suited for huge repositories to be cloned, so the performance benefit of gitoxide over Git won't matter much either.

It would allow us to also make use of askpass for SSH keys with passwords

gitoxide also uses ssh (the program) as transport and I'd think that credential handling associated with it works similarly. But I wouldn't bet on it either as I haven't tested that specifically, nor did I test more advanced setups.

[Caleb-T-Owens]

I'll add it to my todo list for the new year, unless @krlvi wants to take a look at this himself sooner given that it's very much onboarding related?

[PowellDean]

I can help with any testing. Our repositories are usually quite small, but we have a lot of them spread across several AZDO instances. Thanks, all! Dean

…

On Sat, Dec 21, 2024, 2:34 p.m. Caleb Owens ***@***.***> wrote: I'll add it to my todo list for the new year, unless @krlvi <https://github.com/krlvi> wants to take a look at this himself sooner given that it's very much onboarding related? — Reply to this email directly, view it on GitHub <#5848 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGPPCS6EEYEWMBB3P3ZBMT2GXNIBAVCNFSM6AAAAABTZD3MZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGI2DMNBSGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>