Critical Bugs

1. Android Detection Too Broad, Linux ARM64 Confusion

Location: os.rs, line 7 and picker.rs, lines 170-173

Issue: The Android regex is simply (?i:android) without word boundaries, and the special-case filtering only applies when platform.target_os != OS::Android:

1
2
3
4
5

if os_matcher.is_match(&asset.name) {
    if self.platform.target_os != OS::Android && android_re().is_match(&asset.name) {
        debug!("does not match our OS");
        continue;
    }

Problems:

1. The Android regex can match filenames containing “android” anywhere, even as part of another word
2. The logic assumes Linux matches will come first, then filters Android, but both might match
3. A file like myapp-armandroid-linux.tar.gz might be incorrectly filtered

Impact: This caused the bug mentioned in release notes where ubi incorrectly picked Android releases on Linux aarch64.

Fix: Use word boundaries for Android regex: regex!(r"(?i:(?:\b|_)android(?:\b|_))") and ensure proper OS precedence.

2. Exact Match Doesn’t Check Executability 🔴 CRITICAL

Location: installer.rs, lines 368-370

Issue: When an exact filename match is found in an archive, the code immediately returns it WITHOUT checking if the file is executable:

1
2
3
4

if self.archive_member_is_exact_match(file_name) {
    debug!("found {archive_type} file entry with exact match: `{file_name}`");
    return Ok(Some(i));  // Returns immediately, no executable check!
}

This is even documented in the README: “Note that if it finds an exact match, it does not check the file’s mode.”

Impact:

• On Unix systems, if an archive contains both a non-executable script and an executable binary with the project name, the non-executable might be selected
• A malicious or poorly structured archive could have a non-executable data file with the right name that gets selected over an actual executable

Example Failure:

1
2
3

archive/
  ├── myapp (mode 644, data file)
  └── myapp-linux-x86_64 (mode 755, actual executable)

The non-executable myapp would be selected.

Fix: Always check executability, even for exact matches on Unix systems.

3. ARM Regex Too Permissive on macOS

Location: arch.rs, lines 40-62

Issue: The macos_aarch64_only_re() includes just arm as a match:

1
2
3
4
5
6
7

(?:
    aarch_?64
    |
    arm_?64
    |
    arm        // Too broad!
)

Impact:

• Will match armv7, armhf, arm-linux, armchair, etc.
• Could incorrectly select 32-bit ARM binaries on ARM64 macOS
• Recent fix changed from “arm64” to “arm”, making it even broader

Example: A file named myapp-darwin-armv7.tar.gz would match on macOS ARM64.

Fix: Be more specific: require either 64 indicators or use negative lookahead to exclude 32-bit variants.

Significant Bugs

4. 64-bit Filter Uses Naive String Search ⚠️ HIGH SEVERITY

Location: picker.rs, lines 322-335

Issue: The 64-bit filtering uses a simple substring search for “64”:

1
2
3
4
5
6
7
8
9

if !matches.iter().any(|a| a.name.contains("64")) {
    debug!("no 64-bit assets found, falling back to all assets");
    return matches;
}

let sixty_four_bit = matches
    .into_iter()
    .filter(|a| a.name.contains("64"))
    .collect::<Vec<_>>();

Problems:

1. Matches version numbers: myapp-v1.64.2-linux-i686.tar.gz would be considered 64-bit even though it’s i686 (32-bit)
2. Matches years: myapp-2064-edition-arm32.tar.gz would be considered 64-bit
3. Matches hashes/IDs: myapp-build-abc64def-armv7.tar.gz would be considered 64-bit
4. Matches other contexts: sha64, base64, sha256464, etc.

Impact: Can incorrectly include 32-bit binaries in the “64-bit” filter results. While x86_64 can run 32-bit x86 binaries, this breaks down for other architectures:

• On ARM64, should prefer aarch64 over arm32
• On x86_64, should prefer native 64-bit over 32-bit compatibility mode
• The wrong binary might be selected based on alphabetical ordering if both pass through

Example Failure Scenarios:

Scenario 1 - Version number interference:

1
2
3
4
5

Platform: aarch64 (ARM64)
Assets:
  - myapp-v1.64.0-linux-armv7.tar.gz  (contains "64", but is 32-bit ARM!)
  - myapp-v1.63.0-linux-aarch64.tar.gz (no "64" in version, but IS 64-bit!)
Result: Selects the 32-bit ARM binary because it has "64" in version number

Scenario 2 - Build IDs:

1
2
3
4
5

Platform: x86_64
Assets:
  - myapp-linux-i686-build642.tar.gz (contains "64", but is 32-bit)
  - myapp-linux-x86_64.tar.gz
Result: Both pass the filter, then alphabetical sort picks one arbitrarily

Proper Fix - Architecture-Specific 64-bit Detection:

Replace the naive string search with architecture-aware regex matching:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

fn maybe_filter_for_64_bit_arch(&self, matches: Vec<Asset>) -> Vec<Asset> {
    // Only filter on 64-bit architectures
    if !matches!(
        self.platform.target_arch,
        Arch::AArch64
            | Arch::Mips64
            | Arch::PowerPc64
            | Arch::Riscv64
            | Arch::S390X
            | Arch::Sparc64
            | Arch::X86_64
    ) {
        return matches;
    }

    let asset_names = matches.iter().map(|a| a.name.as_str()).collect::<Vec<_>>();
    debug!(
        "found multiple candidate assets on 64-bit platform, filtering for 64-bit binaries in {asset_names:?}",
    );

    // Create architecture-specific 64-bit indicator regex
    let bit64_re = self.arch_64_bit_indicator_regex();

    let sixty_four_bit: Vec<Asset> = matches
        .iter()
        .filter(|a| bit64_re.is_match(&a.name))
        .cloned()
        .collect();

    if sixty_four_bit.is_empty() {
        debug!("no assets explicitly marked as 64-bit found, falling back to all assets");
        return matches;
    }

    debug!(
        "found 64-bit assets: {}",
        sixty_four_bit.iter().map(|a| a.name.as_str()).join(",")
    );

    sixty_four_bit
}

fn arch_64_bit_indicator_regex(&self) -> Regex {
    // Match architecture-specific 64-bit indicators near word boundaries
    let pattern = match self.platform.target_arch {
        Arch::X86_64 => r"(?i)(?:\b|_)(?:x86[_-]?64|x64|amd64)(?:\b|_)",
        Arch::AArch64 => r"(?i)(?:\b|_)(?:aarch64|arm64)(?:\b|_)",
        Arch::Mips64 => r"(?i)(?:\b|_)mips64(?:el|le)?(?:\b|_)",
        Arch::PowerPc64 => r"(?i)(?:\b|_)(?:ppc64|powerpc64)(?:le)?(?:\b|_)",
        Arch::Riscv64 => r"(?i)(?:\b|_)riscv64(?:\b|_)",
        Arch::S390X => r"(?i)(?:\b|_)s390x(?:\b|_)",
        Arch::Sparc64 => r"(?i)(?:\b|_)sparc64(?:\b|_)",
        _ => r"(?i)(?:\b|_)64(?:\b|_)", // Fallback for unknown 64-bit architectures
    };

    Regex::new(pattern).unwrap()
}

Alternative Simpler Fix (if full regex solution is too complex):

Use a more restrictive substring search that requires word boundaries around “64”:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

fn maybe_filter_for_64_bit_arch(&self, matches: Vec<Asset>) -> Vec<Asset> {
    if !matches!(
        self.platform.target_arch,
        Arch::AArch64 | Arch::Mips64 | Arch::PowerPc64
            | Arch::Riscv64 | Arch::S390X | Arch::Sparc64 | Arch::X86_64
    ) {
        return matches;
    }

    let asset_names = matches.iter().map(|a| a.name.as_str()).collect::<Vec<_>>();
    debug!(
        "found multiple candidate assets, filtering for 64-bit binaries in {asset_names:?}",
    );

    // Use a regex that requires 64 to be part of an architecture indicator,
    // not just anywhere in the string
    let bit64_re = regex!(r"(?i)(?:\b|_)(?:\w*64|64\w+)(?:\b|_)");

    let sixty_four_bit: Vec<Asset> = matches
        .iter()
        .filter(|a| {
            let name_lower = a.name.to_lowercase();
            // Must contain "64" with word boundaries, not in version numbers
            // Version number pattern: vX.64.Y or vX.Y.64
            let is_version = regex!(r"v\d+\.\d*64").is_match(&name_lower);

            bit64_re.is_match(&a.name) && !is_version
        })
        .cloned()
        .collect();

    if sixty_four_bit.is_empty() {
        debug!("no 64-bit assets found, falling back to all assets");
        return matches;
    }

    debug!(
        "found 64-bit assets: {}",
        sixty_four_bit.iter().map(|a| a.name.as_str()).join(",")
    );
    sixty_four_bit
}

Benefits of the Fix:

1. Architecture-specific matching prevents false positives
2. Explicitly excludes version numbers like “1.64.0”
3. Requires “64” to be part of an architecture indicator (word boundaries)
4. Falls back gracefully if no 64-bit indicators found
5. More maintainable - uses existing architecture regexes

Testing Required:

• myapp-v1.64.0-linux-i686.tar.gz should NOT match on x86_64
• myapp-linux-x86_64.tar.gz SHOULD match on x86_64
• myapp-aarch64-darwin.tar.gz SHOULD match on ARM64
• myapp-arm64-v2.64.tar.gz SHOULD match on ARM64 (arm64 indicator present, version ignored)

5. MIPS Regex Ordering Issue

Location: arch.rs, lines 122-138 and 158-174

Issue: The mips_re() regex will match mips64 because it just looks for mips:

1
2
3

pub(crate) fn mips_re() -> &'static Lazy<Regex> {
    regex!(r"(?ix)(?:\b|_)mips(?:\b|_)")  // Matches "mips64"!
}

Impact: On a 32-bit MIPS platform, it might match 64-bit assets. The code relies on checking mips64 first, but if regexes are applied in wrong order, this fails.

Fix: Add negative lookahead: mips(?!64) or be more careful about ordering.

6. Musl Detection Relies on External Binary

Location: Mentioned in docs; detection happens before picker

Issue: The musl detection runs ldd /bin/ls to check for musl.

Problems:

1. /bin/ls might not exist on minimal systems or non-FHS systems
2. ldd might not be in PATH
3. The command might fail for other reasons
4. Users can’t easily override false negatives

Impact: On musl systems without /bin/ls, detection fails and glibc binaries might be selected.

Fix:

• Check multiple common binaries
• Provide better fallback mechanisms
• Make the override mechanism more discoverable

7. Libc Filtering is Too Lenient

Location: picker.rs, lines 235-258

Issue: The libc matching allows assets without any libc indicator:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

if asset.name.contains("-gnu") || asset.name.contains("-glibc") {
    debug!("indicates glibc and is not compatible with a musl platform");
    continue;
} else if asset.name.contains("-musl") {
    debug!("indicates musl");
} else {
    debug!("name does not indicate the libc it was compiled against");
}

libc_matches.push(asset.clone());  // Pushes even without musl indicator!

Impact: On musl systems, if there’s an asset with no libc indicator and one with -gnu, the code filters out -gnu but accepts the unmarked one, which might actually be glibc-linked.

Example:

• Platform: x86_64-unknown-linux-musl
• Assets: app-linux-x86_64.tar.gz (actually glibc), app-linux-x86_64-gnu.tar.gz
• Result: Selects the unmarked one, which might not work on musl

Fix: When on musl and multiple matches exist, prefer ones explicitly marked -musl.

8. Windows Extension Checking

Location: installer.rs, lines 376-384

Issue: On Windows, the code assumes files are executable without checking extensions properly:

1
2
3
4
5
6
7
8
9

if self.is_windows
    || matches!(
        entry.is_executable().with_context(|| {...})?,
        None | Some(true)
    )
{
    debug!("found {archive_type} file entry with partial match: `{file_name}`");
    possible_matches.push(i);
}

Problems:

1. Trusts that partial matches on Windows are executable
2. Might select data files like myapp.txt if they start with the right name

Fix: On Windows, verify the file has .exe or .bat extension before accepting partial matches.

9. Sorting Tiebreaker is Arbitrary

Location: picker.rs, lines 293-302

Issue: When multiple assets remain after all filtering, the code sorts alphabetically and picks the first:

1
2
3
4
5

Ok(filtered
    .into_iter()
    .sorted_by_key(|a| a.name.clone())
    .next()
    .unwrap())

Problems:

1. Completely arbitrary - depends on naming conventions
2. aaa-tool-gnu.tar.gz beats zzz-tool-musl.tar.gz alphabetically
3. No way to make this deterministic across projects with different naming
4. Can lead to selecting the wrong variant (GNU over musl, etc.)

Impact: Unpredictable behavior when multiple variants exist. The selected asset might not be optimal.

Fix: Add better heuristics:

• Prefer tarballs over zip
• Prefer explicit libc matches over unmarked
• Consider file size (larger = more likely to be feature-complete)
• Make the selection criteria more explicit

Minor Issues

10. Partial Match Case Sensitivity

Location: installer.rs, lines 410-420

Issue: The partial match checks case insensitively for the extension but case sensitively for the prefix:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

fn archive_member_is_partial_match(&self, file_name: &str) -> bool {
    if !file_name.starts_with(&self.exe_file_stem) {  // Case sensitive!
        return false;
    }
    if self.extensions.is_empty() {
        return true;
    }
    self.extensions
        .iter()
        .any(|&ext| file_name.to_lowercase().ends_with(ext))  // Case insensitive!
}

Impact: An archive with MyApp won’t match if looking for myapp, even though the extension matching is case-insensitive.

Fix: Make prefix matching case-insensitive too, or document the case-sensitivity requirement.

11. No Validation of Extension Parsing

Location: picker.rs, lines 121-123

Issue: Extension parsing errors are silently ignored:

1
2
3
4
5
6
7

match Extension::from_path(Path::new(&a.name)).with_context(|| {...}) {
    Err(e) => {
        debug!("skipping asset with invalid extension: {e}");
        false  // Just skips silently
    }
    ...
}

Impact: If there’s a bug in extension parsing, valid assets might be silently skipped without clear errors to the user.

Fix: Accumulate skipped assets and report them in debug mode or if no assets match.

12. --matching Only Applied When Multiple Matches

Location: picker.rs, lines 338-355

Issue: The --matching filter is only applied when matches.len() > 1:

1
2
3
4
5
6
7

fn maybe_filter_for_matching_string(&self, matches: Vec<Asset>) -> Result<Vec<Asset>> {
    if self.matching.is_none() {
        return Ok(matches);
    }
    // This is called from pick_asset_from_matches which is only called after filtering
    // So if there's only 1 match, this never gets called!
}

Actually looking at the code flow in pick_asset_from_matches (line 270), this is called even with 1 match, but the documentation says it’s ignored with one match.

Impact: User confusion - they set --matching but it might not have the effect they expect if there’s only one platform match.

Fix: Document this behavior more clearly or apply matching earlier in the pipeline.

Edge Cases & Robustness Issues

13. No Fallback When 64-bit Filter Removes All Assets

Location: picker.rs, lines 322-335

Issue: If all assets contain “64” but none are actually 64-bit, they all pass through. But if some contain “64” and some don’t, only “64” ones are kept.

Example:

• Platform: x86_64
• Assets: app-v1.64-i686.tar.gz, app-v1.64-x86_64.tar.gz
• Both contain “64”, both pass through
• Then alphabetical sort picks one

Impact: Can still select wrong architecture even after “64-bit filtering.”

14. Zip and 7z Archives Don’t Track Executability

Location: archive.rs, lines 100-103, 160-163

Issue: These archive formats don’t preserve Unix executable bits:

1
2
3
4

fn is_executable(&self) -> Result<Option<bool>> {
    // Zip entries do not mark whether something is executable.
    Ok(None)
}

Impact: On Unix, partial matches from zip files are always accepted (because None is treated as executable), even if the file isn’t actually executable in the archive.

Fix: On Unix, after extracting from zip/7z, verify the file is executable or try to make it executable.

15. Race Condition in Tarball Iteration

Location: installer.rs, lines 129-138

Issue: The code iterates through the tarball twice - once to find the best match, then again to extract it:

1
2
3
4
5
6
7

// First iteration to find index
let mut arch = tar_reader_for(downloaded_file)?;
let entries = arch.entries()...
if let Some(idx) = self.best_match_from_archive(...) {
    // Second iteration to extract
    let mut arch2 = tar_reader_for(downloaded_file)?;
    for (i, entry) in arch2.entries()... {

Impact:

• If the file is modified between iterations (unlikely but possible)
• If the archive is malformed, the second iteration might behave differently
• Performance cost of reading the archive twice

Fix: This is noted in comments as necessary due to API limitations. Could cache the path and then use tar’s by-name extraction if available.

Recommendations

High Priority Fixes

1. Fix 64-bit filtering logic - Use architecture-specific regex matching instead of naive string search for “64”
2. Add executable check for exact matches - Critical for security and correctness
3. Improve ARM regex specificity - Prevent matching 32-bit ARM variants
4. Fix Android detection - Use word boundaries

Medium Priority

5. Better musl detection - Add fallbacks and try multiple binaries
6. Smarter tiebreaker - Use better heuristics than alphabetical sort
7. MIPS regex fix - Prevent mips_re from matching mips64

Low Priority

8. Case-insensitive partial matching - More forgiving for users
9. Better error messages - Show what was skipped and why
10. Document limitations - Especially around zip/7z executability

Testing Recommendations

Unit Tests Needed

1. Test 64-bit filter with version numbers - myapp-v1.64.0-linux-i686.tar.gz should NOT be selected on x86_64
2. Test 64-bit filter with correct indicators - myapp-linux-x86_64.tar.gz SHOULD be selected on x86_64
3. Test Android filtering with various Linux ARM64 asset names
4. Test exact match with non-executable file
5. Test ARM regex with armv7, armhf variants
6. Test musl filtering with unmarked binaries
7. Test partial match case sensitivity

Integration Tests Needed

1. Test full asset selection with real-world release patterns
2. Test with archives containing multiple executables
3. Test cross-platform with various naming conventions
4. Test error cases (no matching assets, ambiguous matches)

Property Tests

1. Asset selection should be deterministic given same inputs
2. Selected asset should always be compatible with platform
3. Filtering should monotonically decrease candidate set

Conclusion

The asset selection logic in ubi is generally well-structured but has several bugs that can lead to incorrect asset selection, particularly around:

• 64-bit architecture detection (using naive string search instead of architecture-aware matching)
• Architecture matching for ARM variants and Android/Linux disambiguation
• Executable detection in archives (exact matches and zip/7z formats)
• Tiebreaking when multiple valid options exist

The most critical fix needed is improving the 64-bit filtering logic to use architecture-specific regex patterns instead of a simple substring search for “64”, which can match version numbers and other non-architecture contexts.

Most of these issues can be fixed with more precise regex patterns and better filtering logic. The codebase is well-tested but would benefit from additional tests covering the edge cases identified here, particularly around version numbers interfering with architecture detection.