Update built dependency to 0.7.1

[soenkeliebau]

Description

Requires some small changes to the code, as the Option struct has been removed in favor of feature flags.

fixes #451

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

Beta Give feedback

1. Changes are OpenShift compatible
2. CRD changes approved
3. CRD documentation for all fields, following the style guide.
4. Helm chart can be installed and deployed operator works
5. Integration tests passed (for non trivial changes)
6. Changes need to be "offline" compatible

Reviewer

Beta Give feedback

1. Code contains useful comments
2. Code contains useful logging statements
3. (Integration-)Test cases added
4. Documentation added or updated. Follows the style guide.
5. Changelog updated
6. Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Beta Give feedback

1. Feature Tracker has been updated
2. Proper release label has been added

[nightkr]

Do we want to submit a PR for this?

[soenkeliebau]

I have opened lukaslueg/built#62 to see if they'd be willing to consider one, but I would say in principle we would like to do that, yes.

[soenkeliebau]

Integration test still running, but looks okay so far I think ..

https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hbase-operator-it-custom/139/

[soenkeliebau]

Test was successful

[lfrancke]

I'm not sure I like this.
What does the SBOM for this look like? We now need to maintain this ourselves.

I want us to think twice before moving to a fork of something.

[lfrancke]

In fact: I think I'm in favor of reverting this.
We have a few more weeks to go and even then we can live with this vulnerability as it's nothing an end-user can control.

[soenkeliebau]

I am sure that I don't like it, but @nightkr and I discussed this and it seemed the "least bad" option that allows us to get rid of the RUSTSEC in our stack right now.

We can investigate moving of built onto another crate or wait if there is an appetite for our fix upstream. Both of which will take time which this workaround could buy us.

I am also happy to revert and wait for feedback on our issue upstream.

[lfrancke]

I would favor reverting just so everything is consistent but we can also keep it in and wait for upstream.
I don't want to maintain a fork. I think I'd rather figure out where the code is used and disable that part of built or instead basically say (in VEX terms) that the code cannot be controlled by users (which is the case as git should only be used during a github action run - which we control - to figure out the current commit/tag etc.)
So, I think we are not affected by this and I don't want to maintain a fork for something we don't need.

In other words: We can get rid of the RUSTSEC by just saying it's not valid here.

[soenkeliebau]

#453

[soenkeliebau]

I think I'd rather figure out where the code is used and disable that part of built

That is exactly what the changed code in our fork does. The issue is, that upstream removed the ability to disable that code.

[soenkeliebau]

Actually, we only use built as a build dependency, so the code is not even present in our shipped artifacts, so in VEX terms we can even say "vulnerable code not present".

[NickLarsenNZ]

Actually, we only use built as a build dependency, so the code is not even present in our shipped artifacts, so in VEX terms we can even say "vulnerable code not present".

Perhaps it is a non-issue in this case, but in general, even a build-time vulnerability can impact built artifacts. Just wanted to point it out so we don't get too comfortable ignoring build-time vulns.

[soenkeliebau]

Very true, and hopefully at some point it'll go away when we can upgrade again.