[external CI]: Update xmss-acai/xmss-fsai & add xmss-common-spec,xmss-spec,xmssmt-spec and xmss-spec-extra

[ruipedro16]

No description provided.

[fdupress]

Let's first see how long the jobs take, then decide on how they are split.

[fdupress]

I think the failure is due to the external repo (formosa-crypto/formosa-xmss) using ssh+git to specify the submodules.
Since the submodule repo is public, we could also specify it using the https+git URL.

I am honestly surprised and confused by the fact that: 1) this succeeds in the formosa-xmss CI but fails here, and 2) this fails with a host key verification issue here. I'll re-run failed jobs before recommending action on the remote side.

[fdupress]

Thanks, @ruipedro16.

So now we get to the useful failure: we need to bring Jasmin's eclib into play somehow.

The easiest thing to do would be to add an optional field to the external CI job configuration to specify a version of eclib to use (by tag, branch or commit); the external CI job would then go and fetch it. For the time being, we could also take from the external job a path it expects eclib to be set up in. (In the long run, we'll want a proper notion of importable library.)

@strub Do you see another way of doing this?

[ruipedro16]

should I add eclib as a submodule for now?

[fdupress]

The issue with adding it as a submodule is that we'll also then need to add the namespaced idir to the easycrypt.project, which means that the version from the submodule will always be selected when checking, even if a global configuration exists pointing at a different jasmin eclib.

The issue with not adding it as a submodule is that, at the moment, the best we can do is clone jasmin-compiler in the CI and add the namespaced include to the config or command-line option in the CI only. I can't do that easily in the CI script without making assumptions about the repo's structure.

I think the crux of it is that we really want to have libraries that install themselves register that they exist into the easycrypt configuration in one way or another. (So in this case, Jasmin could tell easycrypt, when it is being installed, that eclib lives at a particular path (for example ~/.opam/switch/lib/jasmin/eclib, if installed via opam) and should be namespaced as Jasmin.) This can be overridden by local and command-line options, so we'd be in a healthy place, where the default works, but the user has ultimate control over which library is used without having to edit a version-controlled file.

Until we have that, I will likely go with option 2: clone jasmin-compiler and point EasyCrypt to it for eclib directly in the external CI script.