Include the patched version of aws-nitro-enclaves-cose in the repo and packit enhancements

[mmartinv]

The purpose of this patch is to incorporate the external an patched version of aws-nitro-enclaves-cose into the project's source code to avoid all the hacks of patching and unpatching the spec files, the Cargo.toml and the vendored sources back an forth when packaging as it has been shown to be fragile and is causing (and will cause) problems with dependantbot.

This patch also tries to centralize all the build logic in one file (the Makefile) and simplify the packit configuration.

The summary of changes woud be:

• chore: add aws-nitro-enclaves-cose 0.4.0 crate to the repo
• chore: fix aws-nitro-enclaves-cose errors
• chore: spec changes
• chore: use the new local copy of aws-nitro-enclaves-cose
• chore: add new Makefile targets
• chore: use the new Makefile targets in packit
• chore: remove unused patches and scripts
• chore: skip external crates from analisys
• chore: bump libcryptsetup-rs
• chore: ignore source code and vendor tarballs.
• chore: avoid clippy errors

[github-advanced-security]

devskim found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[runcom]

niiiice 😃 let's make this work!

[runcom]

I guess we can update the SOP document to use these commands too - like git checkout v0.5.2 and then make source && make vendor and then git checkout c10s && centpkg updload file.tar.gz etc etc (maybe for another PR of course)

[mmartinv]

Shouldn't the propose-downstream also work for centos? (except for the corresponding Jira ticket creation)

[runcom]

yeah, but you still have to upload the sources (this is how I read the page on the packit guide as it's not yet implemented to upload sources to the lookaside cache) - also, building isn't taken care of as far as I can tell

maybe I'm wrong :)

[mmartinv]

Yeah, I think you are right, It looks like the automation will not do it for us but there's the option of using the cli according to the warning note.

Mabye something like (after filing the corresponding Jira ticket: RHEL-XXXXX):

git checkout v0.5.2
packit propose-downstream --pr \
                          --dist-git-branch c10s \
                          --resolve-bug RHEL-XXXXX
                          --package fido-device-onboard-centos

[nullr0ute]

This shouldn't really be one massive PR, there's a whole raft of different changes in here, I'm also not particularly happy about pulling an unrelated code base into here due to maintenance and CVEs. I feel it would likely be less work to just move to the latest version of the COSE crate so we don't have to do this malarkey and we'd not have the problem again moving forward.

[mmartinv]

This shouldn't really be one massive PR, there's a whole raft of different changes in here,

I can separate the crate changes from the packit changes if you want but that would mean to move one or two commits only.

I'm also not particularly happy about pulling an unrelated code base into here due to maintenance and CVEs.

Only the RHEL builds will be using the included code base, the Fedora builds are supposed to keep using the upstream patched crate which is rpm packaged in Fedora, so the only difference is that you will be adding the patch in this repo instead of adding the patch in the repo you have in your personal fork for the RHEL builds.

I feel it would likely be less work to just move to the latest version of the COSE crate so we don't have to do this malarkey and we'd not have the problem again moving forward.

It's not, I tried to update and we need changes in the code to implement additional traits for some particular types. Moreover, there are some crate additions in the the updated version so we would need to add some new RPMs to Fedora if we upgrade, not checked the full list of dependencies though. Taking into account that we agreed to migrate to coset crate I don't think the effort to update worth it.