Dropbox download/munki recipes every so often appears to install beta version instead of production version

[fseesink]

Describe the problem
I have used the Dropbox munki recipe for years now, with a setup configured for both managed installs and updates. But in the past 6 months or so, I at one point noticed my systems were running a beta version! That was unexpected, as I have never requested or in any way participated in the beta (nor do I want to). Removing that was also an annoyance, but I got things resolved eventually.

Then this morning I found that, yet again, the version of Dropbox that this recipe downloaded/installed is the beta version! Nowhere is this mentioned. I would expect there to either be a flag or some indication in the recipe that users are getting the beta vs. production version. I did not and do not wish to participate in the beta program. And I absolutely have NEVER signed up or requested it.

Now I don't know if this is some oddball thing on Dropbox's end, as their .DMG has a small (< 1MB) installer which then I guess pulls down the latest. All I know is that this is the 2nd time I found the version of Dropbox is the beta.

Preferences contents
BE SURE TO SANITIZE ANY SENSITIVE DATA SUCH AS PASSWORDS OR ADDRESSES.
Provide or link to a gist of the output of defaults read com.github.autopkg, or the contents of your external --prefs file.

https://gist.github.com/fseesink/f387e1921e2204c9cb848520f3890d1e

AutoPkg output
BE SURE TO SANITIZE ANY SENSITIVE DATA SUCH AS PASSWORDS OR ADDRESSES.
Provide or link to a gist of the output of autopkg run -vvvv <RecipeName>, or any other command you are running. Please include as much data as possible.

https://gist.github.com/fseesink/a94f59e7bcffc0a35944d9c73c21221f

Expected behavior
A clear and concise description of what you expected to happen. What specific part of the recipe or AutoPkg run did not behave correctly?

I expected the Dropbox download/munki recipes to download/update the production version of Dropbox, NOT the beta version.

Version (please complete the following information):

• OS version: 13.6.1
• AutoPkg Version: 2.7.2

[AllPurposeBen]

I've been seeing this lately too.

I wrote a little test script to prove it out: https://gist.github.com/Addigy-BenM/f4826887fd14426065c2333e3e15c4ae

It's curl'ing the header for the download URL in the current download recipe and looking for the URL that it redirects to change from the known good current stable build (https://edge.dropboxstatic.com/dbx-releng/client/Dropbox%20204.4.5420.dmg as of today) and loops over that every 20 seconds, logging when it doesn't match. I'll see a mismatch every few minutes, seemingly randomly. I'd get the URL for the most current beta instead of stable. I've had a few colleagues run this and they see the same behavior.

This doesn't seem to be an autopkg problem, something goofy with Dropbox's CDN. I've seen it from several geographic locations too, so not just a stuck local CDN problem and apparently it's been happening for a while. I haven't tried bringing it up to Dropbox but as I'm fetching installers for customers and don't have a paid Dropbox account myself, I assume I'd have a hard time getting them to pay this attention to this.

---

I think I found a fix though. If I add a parameter to the known download URL to explicitly specify the stable build, my script returns the known good stable URL every time in my testing.

https://www.dropbox.com/download?plat=mac&full=1&build=stable

I can PR a branch that has this adjusted URL and also makes that download URL and the build type (stable or beta) input variables that can be overridden (the URL is hardcoded in the recipe currently). Hopefully the above test script is enough proof of the issue and the fix for the PR to be approved. It is kind of intermittent so just running the AP recipe randomly might take a while to pickup a failure.