Removing auto-updater for Alfred Gallery
vitorgalvao opened this issue · comments
When the Alfred Gallery is live, added workflows will be updatable from within Alfred itself. As part of that, a prerequisite for inclusion will be that workflows not auto-update themselves. This is to avoid a confusing interaction of crossed updates and for security reasons, as Gallery workflows go through a number of checks.
Typically I’d submit the PR for this, but you’re using a bespoke method for the info.plist and didn’t want to mess up your organisation. Making a new release helps to speed up the process, but if you prefer to wait let me know and I’ll ping you once the Gallery is live.
Can you provide some more information on how this feature will work? What do we need to do to support it? How will releases work with it?
Can you provide some more information on how this feature will work?
Alfred itself will check for updates from the Gallery, so users will have the option to update without having to run the workflow.
What do we need to do to support it? How will releases work with it?
You don’t need to do anything to support it, your process won’t change. You’ll still make releases as usual and we’ll detect when those are out and queue them up for a new review and update in the Gallery.
If you ever need to make a hotfix for someone to test, you can. Then after you make the new release, even that user will be able to update from within Alfred to the version you intended.
To clarify, the process would work like?:
- We upload an asset to a GitHub release, e.g. https://github.com/jsumners/alfred-emoji/releases/tag/v2.0.1
- The gallery will see the new release via https://github.com/jsumners/alfred-emoji/releases.atom
- The gallery will look for a specifically named asset
- If the asset is found, send notifications to users that have it installed
If that is the case, the change here will be a simple one: remove all of the release checking and auto-updating code (obsoleting #95). It will, however, be another major change. So we'd need to coordinate when to publish such a release. At least as much to be able to put something like "future releases will be available via the Alfred Gallery starting on 2023-01-31".
Close. 1 and 2 are correct, but on 3 there will be a step for automated and manual reviews of the changes (the checks mentioned above). Once that’s done, the version in the Gallery will be updated. Users will then be able to check for updates from Alfred.
This intermediary step is another layer of protection for users who install from the Gallery. It does mean the update won’t be available immediately, but for the vast majority of cases an update isn’t that pressing. In a case where a release does need to be expedited, contacting us is the way to go so it can be prioritised.
It will, however, be another major change.
Not necessarily. Even if a user has the workflow installed from your releases, Alfred will detect that it is available in the Gallery and offer to update from there. For the workflows I develop I’m just removing OneUpdater from the new versions and changing the download link to instead point to the Gallery page (as opposed to GitHub releases), nothing else.
Not necessarily.
It's a major change in how this workflow functions. It'll be released as v3.
but on 3 there will be a step for automated and manual reviews of the changes
I don't understand. Will the gallery not be looking for <something>.workflow attached to the release? How will your end get the package?
Alfred will not download the workflow directly from this repo. After review the workflow will be signed and rehosted. This prevents the case where e.g. a bad actor would compromise your account and replace the released workflow, or that a suddenly dead repo would break downloads too.
😕
Do you realize the task you are setting for yourself? Complicated workflows, such as this one, require a build process. So for each workflow you include in the gallery, and for each release of all of those workflows, you will have to build a custom release. At a minimum, this is another point toward needing a more developer friendly workflow development process (as mentioned in #89 (comment)).
Assuming all of that works well, I'm not sure I can sign off on that. It would mean there is room for changes between what we release here, and what gets distributed in the gallery. We would not be able to support downloads from the gallery due to that simple fact.
We won’t be rebuilding the workflows. We’ll grab your release, the .alfredworkflow file you post, and rehost that one with a signature which ensures that no tampering happened since review, as well as availability. What users will get is the same package as if they had downloaded directly from GitHub.
It’s similar to submitting an app to the App Store. Technically Apple could change it, but they wouldn’t make malicious or breaking changes. In that same vein, there’s no reason for Alfred to deliberately break your workflow.
If it makes you more comfortable, you can hold off until the gallery is live and then you’ll be able to both see how it works, and decide if you want your workflow to be included.
Alfred Gallery is now in early access. See a draft of how this workflow would show up. Installation and download are disabled, but you can navigate to other pages to check how that part works.
We’ll grab your release, the
.alfredworkflowfile you post, and rehost that one with a signature which ensures that no tampering happened since review, as well as availability.
I'm still not clear how this happens.
It happens manually. The downloaded workflow is reviewed and a signature is generated so Alfred can check against it and know the downloaded packaged is the same as what was reviewed.
Are you able to shed some light on what’s confusing? I’ve reread the quoted explanation a few times and don’t understand what specifically you find unclear.
This process seems like one step forward and two steps back:
- It's fantastic that your team is working to resolve the discoverability and update problems for workflows (step forward)
- Releases get slowed down by a manual process (two steps back)
I'm really uneasy about removing an automated process in favor of a manual one. I'm particularly uneasy about adding a third party human into the process.
A manual process which exists for user security. Plus, it is a process which finds basic flaws and improves workflows. Case in point, the two PRs I’ve sent for this very workflow. It’s far from the only case which has directly benefitted from the process. It results in users getting more reliable workflows with a better understanding of what they can trust.
I'm particularly uneasy about adding a third party human into the process.
A third-party human which is a first-party in what relates to Alfred. Again, there’s little difference from submitting an app to the App Store except the reviewer knows how to program and handholds you with what exactly needs improving, down to sending code fixes and explaining the reasoning for stuff.
Plus, it is a process which finds basic flaws and improves workflows. Case in point, the two PRs I’ve sent for this very workflow.
Um, one of your PRs addressed handling of shell input as a result of the lack of complete documentation on Alfred's part. The other was adding a new feature. Neither were a "flaw" in this workflow, per se.
It’s far from the only case which has directly benefitted from the process. It results in users getting more reliable workflows with a better understanding of what they can trust.
This is now setting you up as the arbiter of what is and is not "good".
Again, there’s little difference from submitting an app to the App Store
I don't know why you keep bringing up the App Store. I do not have to deal with the app store except to install a few bits of software that choose to only distribute through it. I really don't care what their processes are.
except the reviewer knows how to program and handholds you with what exactly needs improving, down to sending code fixes and explaining the reasoning for stuff.
Again, this sounds a lot like you are setting yourself up as the ultimate authority on what can and cannot be done. Until this is no longer the case, I think we will be okay with our current distribution mechanism.
Neither were a "flaw" in this workflow, per se.
Correct. I wasn’t calling them that. They were general improvements.
This is now setting you up as the arbiter of what is and is not "good".
Not so. I sent pull requests. We could have discussed them further and you had final say in merging. I strive to always make the pull requests make sense for the workflow in question and work with the creator to have it merged.
Plus, your choice to distribute the workflow yourself is never compromised. Nothing changes if you continue as you were.
Anyway, thank you for the fast replies. Do ping me if you change your mind. Have a great week.