fix: ci compile errors

[polymo1]

Closes: #19

I've fixed the build errors, but the test errors aren't passing. Both fixes are provided by VS Code + rust-analyzer.

I also added workflow_dispatch: to the workflow to allow manual runs, which I found to be needed in the scenario of committing to a fork before enabling workflows.

[junepark678]

approving because build error stops it from actually building instead of tests... which seems to be broken

[polymo1]

Noticing an issue in regards to the second test in lib.rs

It panics with:

assertion `left == right` failed
  left: OtherAlg(OtherAlgorithmIdentifier { algorithm_type: ObjectIdentifier { components: [2, 16, 840, 1, 101, 3, 4, 2, 1] }, params: Some([5, 0]) })
 right: Sha1

[polymo1]

It might have been right in front of me, maybe I need to try a Sha1 cert...

Using a Sha1 cert did NOT work.

[polymo1]

I'm lost at this point, it looks like it's prompting for a Sha1 cert, but when using a Sha1 cert the exact same error occurs. I fixed the build errors, it can't get past the test though.

[polymo1]

@JoeMatt thoughts?

[JoeMatt]

Looks like the issue is that the test code is incomplete.

I would suggest removing it or fixing it.

Since I'm new to Rust, I asked an LLM to clean up the warnings VSCode gave me about using unwrap and the parameters, and it gave me this.

    #[test]
    fn sign_app() {
        crate::tests::logger();

        let p12_content = std::fs::read("TODO.p12").expect("Failed to read TODO.p12 file");

        super::sign_app(
            "src/test.app",
            "com.wesbryie.test",
            &p12_content, // Pass the content as a slice reference instead of an owned vector
            "",
        )
        .expect("Signing app failed.");
    }

I replaced the .app and BUNDLE_ID parameters with the values you used in the other test.

I assume this needs the P12?

[polymo1]

In apple-codesign-wrapper/lib.rs I just commented out the test because its giving some oddball error which cannot be solved by me even with the suggestion above. (cc: @JoeMatt )

The check is failing because xcsession.rs expects user input, but I feel that a test should not have user input. Is this safe to comment out?

@JJTech0130 For fetch_anisette_ssc test, I feel it should be commented out because omnisette is obsolete when compared to anisette-server-v3. Do you agree with this? It fails with a directory not found error regarding the anisette_test directory.

[JJTech0130]

Actually, I think that omnisette[storeservicescore] is ideal for use cases where it's just a single instance on-device, and should be kept working if possible-- the only real downside was memory leaks, right?

As for the directory not found error: pretty sure that's the output directory for the anisette.pb file, right? There's some kind of temporary test or build directory created by Rust automatically, right? Maybe you could put it in there?

Another thing, is there anywhere we can move test.app in the repo other than in that main src/ folder? Some kind of test_assets or something folder? Just so that it's clear that it is only an arbitrary test asset.

[JoeMatt]

Actually, I think that omnisette[storeservicescore] is ideal for use cases where it's just a single instance on-device, and should be kept working if possible-- the only real downside was memory leaks, right?

As for the directory not found error: pretty sure that's the output directory for the anisette.pb file, right? There's some kind of temporary test or build directory created by Rust automatically, right? Maybe you could put it in there?

Another thing, is there anywhere we can move test.app in the repo other than in that main src/ folder? Some kind of test_assets or something folder? Just so that it's clear that it is only an arbitrary test asset.

Agreed.

I'm just learning Rust, but it looks like they follow a similar pattern to SPM, where tests go into a /tests folder, etc.

The way this test function is defined, I think, makes it required to be in the same file.

The LLM also suggested refactoring that method into a separate method and file.

Maybe ask a GPT 🙂

I've been using LM Studio with models downloaded from HuggingFace for free local LLM that you can then connect to other IDEs.

[TaeHagen]

I'm not sure if it's merged fully yet, but I implemented Anisette v3 into omnisette, so it's not completely obsolete. The anisette_test directory is used by my v3 impl to store the returned device data/provisioning keys. I don't know what it was for in the older anisette impls, or what omnisette was even supposed to do before v3 lol. That is where I store the anisette.pb file.

Tests can go in a test module, either in a different file or in the same one. Just note them with #cfg[test] and functions with #[test]

[JoeMatt]

How about we shelve that test to get this PR in and make a new ticket to add more test coverage?