Support for downgrading/revoking a version? about taps

[lukpueh]

Great question, @jvilimek! TUF actually does not have any semantics for package versions. As far as TUF is concerned, the version of a package is just part of its name and downgrading from "my-package-v2" to "my-package-v1", is just a change of package (i.e. target).

What TUF does care about is the version of the corresponding metadata, so that the client always has a fresh view of the repository, even if that fresh view includes an older package than the previous view.

[lukpueh]

Another improvement (or earlier mitigation of the production issues) would be A/B testing or rolling deployment (10%... 20%... 50% of clients...) or rings (beta/pre-release/early-adopters/slow-ring...).

This sounds very reasonable. Though, I don't think any of this needs a TAP, which is the formal process for specification changes. Instead I would discuss this as part of deployment considerations / best practices. We have an open issue here: theupdateframework/specification#91

[jvilimek]

I do understand now. We need to implement this by ourselves in our client(s). Thanks for your patience with me and for the quick answers!

[jvilimek]

Great question, @jvilimek! TUF actually does not have any semantics for package versions. As far as TUF is concerned, the version of a package is just part of its name and downgrading from "my-package-v2" to "my-package-v1", is just a change of package (i.e. target).

What TUF does care about is the version of the corresponding metadata, so that the client always has a fresh view of the repository, even if that fresh view includes an older package than the previous view.

Thanks for the quick reply! Let me elaborate on this a bit:

What is now the principle the TUF client knows there is a version it needs to install? AFAIK it installs the latest version, right?

This is the current structure of TUF json:

{
    "signatures": [...],
    "signed": {
        "_type": "targets",
        "expires": "2024-01-12T14:59:21Z",
        "spec_version": "1.0",
        "targets": {
            "some-namespace/1.0.1019/some-file.zip": {
                "hashes": {
                    "sha512": "4060b38ab...074d30f83cc82"
                },
                "length": 35673351
            },
            "some-namespace/1.0.1019/other-file.yaml": {
                "hashes": {
                    "sha512": "fe0403da52...198ec2be92dbb33"
                },
                "length": 807
            },
            ...
      }
}

How about changing this a little bit:

{
    "signatures": [],
    "signed": {
        "_type": "targets",
        "expires": "2024-01-12T14:59:21Z",
        "spec_version": "2.0",
        "targets": {
            "some-namespace": {
                "current_version": "1.0.1019", // <<<-- this we can change even downwards
                "all_versions": [
                    {
                        "version": "1.0.1019",
                        "status": "active", // valid | revoked | not-supported | ...
                        "some-file.zip": {
                            "length": 35673351,
                            "sha512-hash": "4060b38abc...01f83cc82"
                        },
                        "other-file.yaml": {
                            "length": 807,
                            "sha512-hash": "4060b38abc...30f83cc82"
                        }
                    }
                ]
            }
        }
    }
}

(for backward compatibility, you can keep targets.json and introduce a new targets2.json?)

[jvilimek]

Another improvement (or earlier mitigation of the production issues) would be A/B testing or rolling deployment (10%... 20%... 50% of clients...) or rings (beta/pre-release/early-adopters/slow-ring...).

This sounds very reasonable. Though, I don't think any of this needs a TAP, which is the formal process for specification changes. Instead I would discuss this as part of deployment considerations / best practices. We have an open issue here: theupdateframework/specification#91

have you send a correct link? This one navigates to an issue "Secondary literature with detailed rationale and recommendations"?

[trishankatdatadog]

Hey @jvilimek, thanks for reaching out. Firstly, would you please elaborate on your exact issue? Is it about different versions of TUF metadata (according to the specification), and which versions of these metadata or the spec that clients support? For that, you may wish to see TAP 14. Does this help, or are you looking for something else?

[JustinCappos]

I'll also chime in that Uptane (which is a variant of TUF) has a centralized party that controls what versions of software are pushed out to different clients. So looking there may also answer many of your questions...

…

On Tue, Oct 17, 2023 at 10:45 AM Trishank Karthik Kuppusamy < ***@***.***> wrote: Hey @jvilimek <https://github.com/jvilimek>, thanks for reaching out. Firstly, would you please elaborate on your exact issue? Is it about different versions of TUF metadata (according to the specification), and which versions of these metadata or the spec that clients support? For that, you may wish to see TAP 14 <https://github.com/theupdateframework/taps/blob/master/tap14.md>. Does this help, or are you looking for something else? — Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD3BKCL7VNKPV3TG5H3X72K2LAVCNFSM6AAAAAA6DPIEYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRWGU3TANBUGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jvilimek]

Hey @jvilimek, thanks for reaching out. Firstly, would you please elaborate on your exact issue?

Thanks @trishankatdatadog for the reply. Sure, I will elaborate. By production issue I mean the following:

• we are using TUF for deploying plugins among our clients. This plugin sends some data to our services in the cloud.
• let's say we have deployed version 1.0 to DEV, STG, and to PROD environment (=among all our clients)
• we start deploying (and testing) version 1.1 to DEV, then STG ... no issue is found.
• then we deploy this version to PROD and suddenly our services in the cloud start crashing and/or are overloaded.
• we want to revert the deployment and re-install version 1.0 among our clients (on all environments)

Sure.. you can argue that we should have found the issue in the DEV or STG environment. But no testing process is 100% successful and cases like this just happen.

[jvilimek]

I'll also chime in that Uptane (which is a variant of TUF) has a centralized party that controls what versions of software are pushed out to different clients. So looking there may also answer many of your questions...

Thanks, we will check this for sure!

[lukpueh]

What is now the principle the TUF client knows there is a version it needs to install? AFAIK it installs the latest version, right?

Actually, no. TUF (that is, its metadata format and client workflow specification) simply do not know anything about artifact versions. Currently, a client application using the TUF updater needs to already know what artifact (version) it wants.

You might find this write-up about artifact discovery in TUF interesting: https://docs.google.com/document/d/1rWHAM2qCUtnjWD4lOrGWE2EIDLoA7eSy4-jB66Wgh0o

have you send a correct link? This one navigates to an issue "Secondary literature with detailed rationale and recommendations"?

Oh, I maybe wasn't clear. I was trying to say that your proposal seemed to me like a specific deployment recommendation, and that we have an open issue, which points out how great it would be if we had a collection of specific deployment recommendations as secondary literature to the specification.