This action doesn't create releases so the action refs doesn't point to a known tag.
If this zizmor findings is not ignored, then continuous integration pipeline is broken.
This commit fixes an endian (little) for the counter
representation of the counter used in the AES-CTR counter.
This is so that, the random bytes generated are the same not matter
the endian of the system.
A test case with known answers is added, as well as make command
to run the test in an emulated big-endian arch using the `cross`
utility.
This also include a small refactor where now the block cipher
do not encrypt `AesIndex`. This is done as it makes more sense
(AES encrypts bytes, not numbers), so this allows to move and centralize
the concept of endian as well a centralize where batch created.
With recent enforcing of the least permissions for GITHUB_TOKEN, pull-request from external contributors would trigger systematic error (i.e. on repository checkout) in the continuous integration pipeline.
Allowing contents:read fixes this behavior.
If a step is cancelled, it is not considered as failure by GitHub. So if a user cancelled a task or if a job timed out, then no Slack notification was sent and devs weren't able to track down these events.
Referencing current branch using github.head_ref is a leftover
from handling pull_request_target event. This event being removed,
there is no need to be specific and we can instead use
'github.workflow_ref' which is more robust.
We use large GitHub hosted runners to run CI pipeline for external
contributions. This avoids possible secret exposition due to usage
of pull_request_target event. It also removes a layer a complexity
to ensure such secrets are not exposed.
The flow would be improved since tfhe-rs maintainers won't have to
relaunch failed jobs individually, thanks to the "approve and run"
button in GitHub user interface.
Running against last remote commit would induce undesired behavior,
especially on pull-request approval.
For example a change in integer layer could occur in the
pull-request commits list but the changes aren't contained in the
last remote commit. Then, on approval, aws_tfhe_integer_tests.yml
workflow would be skipped although it should run regarding the
base commit.
User permission checking is done after the should-run, when there
is such step, rather than before it. This way, only workflows that
should run would fail id triggering actor is not allowed to launch
it. Thus a repository maintainer would have to re-run only a
handful of jobs that would effectively run afterward
(i.e relevant code has changed and setup-instance would be called).
This approach allows checkout public and private repository, like
Slab, without to worry too much about secret leakage under certain
circumstances (e.g. under pull request from forks).
The token has just read access on selected repositories.
Default 'Ref' displayed in message relies on github.ref value. On
pull_request_target, it's the base_ref, instead of head_ref, that
is set as value for github.ref.
We cannot change 'Ref' field directly. As a workaround, we hide
'Ref' in the message and display the head_ref directly in
SLACK_MESSAGE.
This would skip 'check-user-permission' job if the event
'pull_request_target' is emitted and CI files have changed.
It avoids overlapping of 'pull_request' and 'pull_request_target'
events. CI changes would only be tested on 'pull_request' for
Zama own pull requests.
To be able to run CI for external contribution, through forked
repository, and be able to test CI modification in a development
branch, we need to discriminate pull request events. For the
former 'pull_request_target' event is needed to have access to
GitHub secrets. 'pull_request' event is required for the latter
otherwise the workflow would be pulled from the HEAD of the base
branch and thus wouldn't contain changes from the developer.
This induces a failure if the job has to run AND if the triggering actor isn't a member of the zama-ai organization. That would help tfhe-rs maintainers to re-run only workflows that are supposed to run.
The reference is selected based on the event emitted.
We also now use token with restricted permission to check out the repository.
Previously pull_request and pull_request_target events were both
emitted thus leading one cancelling the other because of
concurrency group name format.
Since external contribution needs to be allowed we only need
pull_request_target event.
Since the addition of pull_request_target event, github.ref context
object return name of the base branch. So when a workflow was
triggered on the base branch during an execution in a pull request,
the latter would be cancelled.
Using github.head_ref, when available, fixes this behavior.
On any other event than pull_request or pull_request_target,
github.ref will still be used and work as before.
If a contributor that open a Pull Request from a fork is not part
of the repository collaborators, then the workflow using
check_triggering_actor subworkflowwill exit with a failure.
It could be re-run later by a collaborator who has a write access.
This allows reviewers to read the code proposition before running
the CI, ensuring no secrets are leaked outside the repository.
