Add ability to deploy remote packages

[YrrepNoj]

Adding the ability for Zarf to deploy remote packages. This checks if the deployPath given is a URL with a file extension we recognize. If the path is a valid package it gets downloaded to /temp and processed.

This also renames packageName to packagePath to try to show that the variable is more than just a name and could either be a full path to a file or even a URL to some online resource.

Potential Issues To Add After Merge:

• Add more verification checks on the file being downloaded (in addition to the file extension and sha256 check we're currently doing?)
• Add credentials to access the url provided, currently we are only able to download packages that are public.
• Check remote filetype instead of simply checking the file extension.

[YrrepNoj]

/test all

[YrrepNoj]

/test all

[jeff-mccoy]

The PR looks good, though we might want to breakup that Deploy() function a little, it's getting heft. However I do have concerns with this idea overall until we have more SBOM components. If we aren't validating a signature or even SHA hash then we have no way to vet the quality of this content or that it should be trusted. I'm not certain what the right answer is, but I think we should discuss that concern a little before merging. CC @RothAndrew @mikhailswift

[RothAndrew]

The PR looks good, though we might want to breakup that Deploy() function a little, it's getting heft. However I do have concerns with this idea overall until we have more SBOM components. If we aren't validating a signature or even SHA hash then we have no way to vet the quality of this content or that it should be trusted. I'm not certain what the right answer is, but I think we should discuss that concern a little before merging. CC @RothAndrew @mikhailswift

I do find value in this from an ease-of-use perspective, though I definitely do see the security implications.

We could potentially require the user to add a --shasum flag, or add an --insecure flag if they don't want to. That would at least make them internalize that this is not a secure thing to do.

Example:

# Won't work
zarf package deploy https://example.com/some-package.tar.zst
ERROR: --shasum or --insecure required to proceed

# The right way
zarf package deploy https://example.com/some-package.tar.zst --shasum aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f

# The insecure way
zarf package deploy https://example.com/some-package.tar.zst --insecure

We could also require --insecure if they don't specify https://

[jeff-mccoy]

I like that format, think it should be part of this PR before merge @YrrepNoj

[YrrepNoj]

/test all

[YrrepNoj]

/test all

[jeff-mccoy]

lgtm. Only comment on the slice constant problem. We could make it private and use a getter with a by value return, I think that would get after the immutability quality of a constant.

[YrrepNoj]

/test all