-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run new TUF autoupdater side-by-side with notary autoupdater #1081
Conversation
… rolling error count
pkg/autoupdate/tuf_autoupdate.go
Outdated
strippedBinary := strings.TrimSuffix(ta.binary, ".exe") | ||
|
||
// The target is in the form `launcher/linux/launcher-0.13.6.tar.gz` -- trim the prefix and the file extension to return the version | ||
prefixToTrim := fmt.Sprintf("%s/%s/%s-", strippedBinary, ta.operatingSystem, strippedBinary) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Urk. I've lost site of how we track archtecture
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe it's present in the TUF/dl.kolide.co stuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might have dropped it. (oops)
We want to start supporting windows and linux arm64. And I think we'll eventually want to stop shipping universal binaries.
I'm not sure if we should roll it into the platform specification, or think harder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think this is something we'll need. There have been a few times that folks have asked for arm64 on linux / windows. I think number will continue to grow. @RebeccaMahany , do you think this would be difficult to bolt on later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC we'd decided to punt architecture to later when I was working on the endpoint-releaser work.
Here is a fairly simple way I could imagine us implementing this in the future:
- endpoint-releaser begins to publish both to
binary/os/file.tar.gz
andbinary/os/arch/file.tar.gz
- endpoint-releaser begins to maintain a
binary/os/arch/channel/release.json
file to point to architecture-specific releases, in addition to thebinary/os/channel/release.json
it already maintains - launcher's new autoupdater looks for its release in
binary/os/arch/channel/release.json
, falling back to preexistingbinary/os/channel/release.json
if it can't find it for whatever reason
So, I think it wouldn't be too bad?
3d9f769
to
6b6be3f
Compare
e08d16f
to
3418978
Compare
…pdate test for same; add more docs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's going to be room for simplification, but we can use this for now!
} | ||
} | ||
|
||
func NewTufAutoupdater(metadataUrl, binary, rootDirectory string, metadataHttpClient *http.Client, opts ...TufAutoupdaterOption) (*TufAutoupdater, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect we can remove option. But let's go with it and iterate
e3141a2
Relates to #954.
This is part 1 of moving to use our new TUF infrastructure; here, we run our new TUF autoupdater side-by-side with our older notary autoupdater implementation. The new autoupdater only maintains a TUF repo but does not attempt to perform updates yet.
Subsequent PRs will tackle the following (order is not set in stone)
findnew
looks for updates in new location, falling back to old location