[TUF autoupdater] Check out latest #1185
Conversation
RebeccaMahany
force-pushed
the
becca/tuf-check-out-latest
branch
from
c4e5f88
to
a4b6235
Compare
|
I was slacking about this. It feels confusing and complex. |
RebeccaMahany
force-pushed
the
becca/tuf-check-out-latest
branch
from
90c3db6
to
0ae45a1
Compare
@directionless I think this is simpler and more lightweight now -- let me know what you think. |
There was a problem hiding this comment.
I think this is mostly okay. (See questions)
this feels much more readable than the prior. I suspect some of this should land in the library manager, and we should call it. Having this iterate files on disk feels wrong. (What happens if we move the library into ram?) But we can iterate there if we want to.
pkg/autoupdate/tuf/library_lookup.go
Outdated
| targets, err := metadataClient.Targets() | ||
| if err != nil { | ||
| return "", "", fmt.Errorf("could not get target: %w", err) | ||
| } | ||
|
|
||
| targetName, _, err := findRelease(binary, targets, channel) | ||
| if err != nil { | ||
| return "", "", fmt.Errorf("could not find release: %w", err) | ||
| } |
There was a problem hiding this comment.
I think this is okay, but it feels weird. These are functions that are hard to follow, and work a lot with github.com/theupdateframework/go-tuf/data. It feels like we should bake them into something like metadataClient. Not sure it's worth it though
There was a problem hiding this comment.
I think there are a couple places in autoupdate.go that feel similar, where it's a lot of work with go-tuf/data. Maybe could be wrapped in a tufReleaseClient (or something) that performs the repeated tasks (update from remote TUF repo to download updated targets, find release target among those targets, find what target it's pointing at, return that target). I could do that here, or add it to the TODOs for a subsequent PR if we want to think about it more.
There was a problem hiding this comment.
Your call. I think this is okay, but it's still murky feeling.
There was a problem hiding this comment.
I'll leave as-is for now, I guess, and think on it
Relates to #954.
This is the next step toward using our new TUF infrastructure: a new implementation of
findNewthat looks at our new update library.Includes some drive-by changes:
kolide_tuf_autoupdater_errorstable that I'm hoping this will resolve.GetChannelVersionFromTufServerto be used bylauncher doctorand by packaging changes for Make launcher available per-architecture #1149How we pick which version of launcher/osqueryd to run
This flowchart is also committed to the docs in this PR.
flowchart TB A[Library lookup] --> B{Do we have a local TUF repo?} B ---->|No| C[Get most recent version from update library] C --> D[Return path to most recent version of executable] D --> H[End] B -->|Yes| E{release.json target metadata exists?} E -->|No| C E --> |Yes| F{Target indicated by release.json\nis downloaded to update library?} F --> |Yes| G[Return path to selected executable in update library] F --> |No| C G --> HFuture work + linked PRs
Subsequent PRs will tackle the following (order is not set in stone):
<binary>/<os>/<arch>/<channel>/release.json, once available (in progress but on hold here: [TUF autoupdater] Include arch in release file path and download file path #1195)findNew); launcher performs library tidying after version selectionPrevious work: