VirtualBox.munki change to new parent.

[erikng]

Rather than use a custom processor, we can use Shea's parent recipe which uses native autopkg processors to obtain the URL and version. This reduces the complexity of an audit.

[jessepeterson]

I believe this violates the spirit of autopkg version fetching, however. That is: using a mechanism that as closely matches the native app's version checking as possible.

Not to mention VirtualBox has a storied history about providing 'current' updates. E.g. for a time they were specifically holding back 5.x releases from 4.x users on purpose (even though the website provided current updates), because certain aspects of the upgrade process were not yet hashed out. Historically the core update providers would default to 'waiting it out' allowing the vendor to fix their feed(s) rather than implement alternate download locations. This is consistent with that.

Plus this complicates any given user of this recipe's life if they don't already have @sheagcraig's recipes. :)

[erikng]

@tvsutton so do you mind if I reupload my own recipe?

Jesse has some great points but I want to reduce the use of custom processors as much as I can.

[jessepeterson]

What's the reason for reducing custom processors? Doesn't that effectively neuter the flexibility of autopkg? It's one of its greatest strengths, in my opinion.

BTW, I think you meant to tag @timsutton :)

[gregneagle]

One reason to reduce the use of custom processors is to make auditing recipes easier. A custom processor can do virtually anything, and so custom processors must be carefully audited by autopkg admins if they want to be sure a recipe isn't doing anything "funny"/insecure.

[erikng]

What I mean by this is to only use custom processors when it's 100% needed. I just had to write a processor two weeks ago because there was no way to use the native autopkg processors, but I'm trying to reduce complexity with regards to auditing recipes (see the autopkg-discuss thread).

Thanks for fixing that. As soon as I sent the email I knew it was wrong.

On Jul 20, 2016, at 6:57 PM, Jesse Peterson [email protected] wrote:

What's the reason for reducing custom processors? Doesn't that effectively neuter the flexibility of autopkg? It's one of its greatest strengths, in my opinion.

BTW, I think you meant to tag @timsutton :)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[jessepeterson]

@gregneagle: that seems to imply that the native processors can't do 'virtually anything' or that they they're inherently more trustworthy or something? And I say that as having originally written the 'built-in' processor that @sheagcraig's recipe uses myself in this case! Don't trust that thing, sheesh! :)

[erikng]

While that hasn't come up yet, I would say that the native processors should be trusted more (even if that is somewhat ironic).

As for everything else, I have a lot of thoughts here but perhaps it should be moved to the bigger discussion.

On Jul 20, 2016, at 6:57 PM, Jesse Peterson [email protected] wrote:

What's the reason for reducing custom processors? Doesn't that effectively neuter the flexibility of autopkg? It's one of its greatest strengths, in my opinion.

BTW, I think you meant to tag @timsutton :)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[jessepeterson]

Well, as usual I don't feel that strongly about it. In general I agree security should probably trump most other considerations (and audiability would fit under that moniker) though in this particular case (wrt to updates-as-app-developers-intend-them) we're talking about application/end-user stability. Fairly high up the totem pole of concerns, though again probably falls in line to security concerns. E.g. if it's more secure to give someone a less stable app, then that risk is probably worth it.