Access Labels online instead of in script #457

New Issue

michael · 2026-01-19T18:34:06Z

michael commented

2026-01-19 18:34:06 +00:00

Originally created by @wakco on GitHub.

Due to the nature of this script (to download and install apps), I'm kinda of surprised the Labels are being embedded in the script instead of being made available online somewhere to grab. This would simplify the update process, by allowing labels to be added without requiring a script update, and vice-versa allow building a new version of the script without needing to include 500+ Labels.

This detail is also hampering my adoption of Installomator because there are a few Labels I am unable to use because they are out of date in the release version, due to changes from places such as Github.

I should note, I'm not advocating changing the way the Labels are otherwise managed or approved (it's perfect the way it is), if anything this would allow Labels to be approved faster, accessible to users immediately, and without a script update being required.

PS. I did try to find a similar request/issue but found none, so apologies if I missed one that I failed to find.

Originally created by @wakco on GitHub. Due to the nature of this script (to **download** and install apps), I'm kinda of surprised the Labels are being embedded in the script instead of being made available online somewhere to grab. This would simplify the update process, by allowing labels to be added without requiring a script update, and vice-versa allow building a new version of the script without needing to include 500+ Labels. This detail is also hampering my adoption of Installomator because there are a few Labels I am unable to use because they are out of date in the release version, due to changes from places such as Github. I should note, I'm not advocating changing the way the Labels are otherwise managed or approved (it's perfect the way it is), if anything this would allow Labels to be approved faster, accessible to users immediately, and without a script update being required. PS. I did try to find a similar request/issue but found none, so apologies if I missed one that I failed to find.

michael added the question label 2026-01-19 18:34:06 +00:00

michael closed this issue

2026-01-19 18:34:06 +00:00

michael commented

2026-01-19 18:34:06 +00:00

@acodega commented on GitHub:

Trust only exists in that an administrator is manually downloading Installomator.sh and presumably checked the latest commits, or the administrator is installing the signed and notarized pkg. You could automate things if we had a signed and notarized pkg for labels but then it doesn't seem that different from just having the one pkg for the one script.

What's the issue you are running into, maintaining your own labels, or adding updated labels when there hasn't been a new Installomator release?

@acodega commented on GitHub: Trust only exists in that an administrator is manually downloading Installomator.sh and presumably checked the latest commits, or the administrator is installing the signed and notarized pkg. You could automate things if we had a signed and notarized pkg for labels but then it doesn't seem that different from just having the one pkg for the one script. What's the issue you are running into, maintaining your own labels, or adding updated labels when there hasn't been a new Installomator release?

michael commented

2026-01-19 18:34:06 +00:00

@wakco commented on GitHub:

Note: "This detail is also hampering my adoption of Installomator because there are a few Labels I am unable to use because they are out of date in the release version, due to changes from places such as Github." Was written before noticing v10.0 was released, but the statement will repeatedly stand as time goes on.

@wakco commented on GitHub: Note: "This detail is also hampering my adoption of Installomator because there are a few Labels I am unable to use because they are out of date in the release version, due to changes from places such as Github." Was written before noticing v10.0 was released, but the statement will repeatedly stand as time goes on.

michael commented

2026-01-19 18:34:06 +00:00

@wakco commented on GitHub:

I was hoping to avoid maintaining my own Labels, which oddly enough is part of the point to Installomator in the first place.

I guess I'll just maintain some of my own ones when necessary.

Thanks for the conversation.

@wakco commented on GitHub: I was hoping to avoid maintaining my own Labels, which oddly enough is part of the point to Installomator in the first place. I guess I'll just maintain some of my own ones when necessary. Thanks for the conversation.

michael commented

2026-01-19 18:34:06 +00:00

@wakco commented on GitHub:

As far as the online infrastructure, that is understandable, as for trust, that already exists as it is.

Another thought might be to seperate the labels into a second script that can be updated/released far more often, than the main script that does the work, then the main script can simply ask that script?

Or as the Labels are already hosted right here on GitHub, perhaps access them directly?

All I'm saying is, I believe the one script approach was fine when there were less than 100 labels, but now it's just making it all the more complicated than it needs to be.

@wakco commented on GitHub: As far as the online infrastructure, that is understandable, as for trust, that already exists as it is. Another thought might be to seperate the labels into a second script that can be updated/released far more often, than the main script that does the work, then the main script can simply ask that script? Or as the Labels are already hosted right here on GitHub, perhaps access them directly? All I'm saying is, I believe the one script approach was fine when there were less than 100 labels, but now it's just making it all the more complicated than it needs to be.

michael commented

2026-01-19 18:34:06 +00:00

@scriptingosx commented on GitHub:

This is a good question. Let me explain the motivations here:

This is intentional. The script does what it does as root so we have to take care to know what we execute.

If we downloaded the labels from somewhere, we would have to have a process of verifying the server and verifying that no-one but approved people have modified the labels. There would be several ways of achieving this, but they all require extra infrastructure and workflows.

When we put all the data in the script, the script itself is the trusted source of data and no extra verification is needed.

To be fair, we are moving the trust question to "someone not us" here. You can trust the script you put in your management system, because, well you did verify what the script does before you put it there, right? Having the script all in one file, makes the verification easier for you, too. If we downloaded the labels from elsewhere, you couldn't verify them. You wouldn't know which code is executed on all of your clients as root. That's a lot of trust...

A workflow like this would also preclude admins of extending the functionality of Installomator with your own labels.

As it is, there is nothing keeping you from updating the labels you need before they are merged into the main repo.

@scriptingosx commented on GitHub: This is a good question. Let me explain the motivations here: This is intentional. The script does what it does _as root_ so we have to take care to know what we execute. If we downloaded the labels from somewhere, we would have to have a process of verifying the server and verifying that no-one but approved people have modified the labels. There would be several ways of achieving this, but they all require extra infrastructure and workflows. When we put all the data in the script, the script itself is the trusted source of data and no extra verification is needed. To be fair, we are moving the trust question to "someone not us" here. You can trust the script _you_ put in your management system, because, well _you_ did verify what the script does before you put it there, right? Having the script all in one file, makes the verification easier for you, too. If we downloaded the labels from elsewhere, _you_ couldn't verify them. You wouldn't know which code is executed on all of your clients as root. That's a lot of trust... A workflow like this would also _preclude_ admins of extending the functionality of Installomator with your own labels. As it is, there is nothing keeping you from updating the labels you need before they are merged into the main repo.

michael commented

2026-01-19 18:34:06 +00:00

@scriptingosx commented on GitHub:

Just to clarify: in my opinion, the option (and actually requirement) to maintain your own labels, was intended from the very beginning.

I would recommend you check out autopkg, which takes a different approach and you get community provided recipes updated independent of the tool. However, while you can run autopkg recipes without verifying them, the intention of the tool is that you really should verify updated recipes before using them. There is an entire workflow in that project for that, that you have to actively disable if you want to "trust blindly."

I am flattered that you trust us, the Installomator contributors, blindly, but we are, after all, just "some guys on the internet" and you really should not.

@scriptingosx commented on GitHub: Just to clarify: in my opinion, the option (and actually requirement) to maintain your own labels, was intended from the very beginning. I would recommend you check out autopkg, which takes a different approach and you get community provided recipes updated independent of the tool. However, while you _can_ run autopkg recipes without verifying them, the _intention_ of the tool is that you really _should_ verify updated recipes before using them. There is an entire workflow in that project for that, that you have to actively disable if you want to "trust blindly." I am flattered that you trust us, the Installomator contributors, blindly, but we are, after all, just "some guys on the internet" and you _really_ should not.

michael commented

2026-01-19 18:34:06 +00:00

@scriptingosx commented on GitHub:

Also, we have already split the labels from the functional code in the main repo, which makes it easier to maintain and merge. the assemble.sh script puts everything together for testing and releasing a new version. A single script file is still easier to use and deploy.

Again, I think these are good questions. I do not at all blame you for asking them. But we have thought about these things and I want to explain our motivations and goals.

@scriptingosx commented on GitHub: Also, we have already split the labels from the functional code in the main repo, which makes it easier to maintain and merge. the [`assemble.sh` script](https://github.com/Installomator/Installomator/tree/main/utils) puts everything together for testing and releasing a new version. A single script file is still easier to use and deploy. Again, I think these are good questions. I do not at all blame you for asking them. But we have thought about these things and I want to explain our motivations and goals.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Installomator/Installomator#457