Cannot match 'linux' OS to 'ubuntu' binaries

[jkelley-godaddy]

Thank you for making ubi - it is a great tool that works perfectly with most repositories.

We have one repository that is giving us issues when attempting install with ubi via mise because the repository owners seem to have named the linux binaries in a way that ubi doesn't expect.

The https://github.com/aws-cloudformation/cloudformation-guard repository publishes their 'linux' release binaries under the 'ubuntu' name for some reason, for example:

• cfn-guard-v3-aarch64-ubuntu-latest.tar.gz
• cfn-guard-v3-x86_64-ubuntu-latest.tar.gz

This causes the following error when attempting installation:

Failed to install with ubi 'ubi:aws-cloudformation/cloudformation-guard@3.1.2': could not find a release asset for this OS (linux) from cfn-guard-v3-aarch64-macos-latest.tar.gz, cfn-guard-v3-aarch64-ubuntu-latest.tar.gz, cfn-guard-v3-aarch64-windows-latest.tar.gz, cfn-guard-v3-i686-windows-latest.tar.gz, cfn-guard-v3-macos-latest.tar.gz, cfn-guard-v3-ubuntu-latest.tar.gz, cfn-guard-v3-windows-latest.tar.gz, cfn-guard-v3-x86_64-macos-latest.tar.gz, cfn-guard-v3-x86_64-ubuntu-latest.tar.gz, cfn-guard-v3-x86_64-windows-latest.tar.gz

We attempted using --matching-regex ubuntu but that gave the same error, and it's unclear if this would be a good solution as some of our users use macos.

We attempted to use the full URL (ie. https://github.com/aws-cloudformation/cloudformation-guard/releases/download/3.1.2/cfn-guard-v3-aarch64-ubuntu-latest.tar.gz) however our linux CICD runners are using linux aarch64 and most users local machines use linux x86_64 so it would be nice to still have ubi do the selection for os/architecture.

This issue seems similar to #79
Not sure what the right solution is and hoping you could advise on that.

Maybe this is something that could be solved with creative use of an existing flag, or maybe the regex in ubi could be updated.
Another interesting option would be giving a flag that allows users to set the regex for the any os, which would allow users to resolve these mismatches without upstream changes to ubi. Something like --rename-os linux=ubuntu or --rename-os macos=mac in the case of #79 .

Please let us know if we can provide any additional information. Thank you!

[autarch]

Are these releases actually ubuntu-specific, or would they work on any Linux? It the latter is the case, I think it'd be good to ask the project maintainers to consider renaming them.

If they are distro-specific, then maybe ubi needs to be distro-aware, which is a bit of pain but not too hard, at least for a subset of popular distros (Debian, Ubuntu, RHEL, etc.).

[jkelley-godaddy]

Thanks for the response.

In our case were are using ubuntu aarch64 CICD runners, so if the intention for installation to work for ubuntu systems the current result is the error message above.

We have also tested with a local debian system which seems to work, so in this case the binary may not be distro-specific. We will contact the maintainers to see if they can rename the binary.

For other projects it may be nice to give users more options to control how ubi selects binaries to work around issues like this without upstream changes. Users are currently dependent on binaries being named "correctly" but it seems these naming conventions are not universally followed.

[autarch]

I'm guessing the binary is not OS-specific. I think it's worth asking upstream to use "linux" in the name. It's true that we can't control upstream naming in general, but in practice, the heuristics that ubi is using seem to work fairly well. I think that part of the reason this is the case is that a lot of the projects ubi can work for are written in Go or Rust, and the tools that people use to package binaries in these ecosystems use the "right" naming scheme for ubi.

I'm trying to walk a fine line between "make ubi work for everyone" and "don't have too many confusing options for its behavior". I'm a bit reluctant to add even more flags for matching names, since it's already a bit complex. It's not even clear what a new flag to handle this case would look like. It would have to provide a way to preempt the existing OS matching entirely.

[autarch]

I just took a look at the binary for that project. It's a statically linked Rust binary that doesn't even seem to link libc! I can't see how it could possibly be Ubuntu-specific.