Skip to content
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

MUImspChecksum64 not updated by Chocomilk #33

Open
olifre opened this issue Jun 6, 2023 · 15 comments
Open

MUImspChecksum64 not updated by Chocomilk #33

olifre opened this issue Jun 6, 2023 · 15 comments

Comments

@olifre
Copy link

olifre commented Jun 6, 2023

The last Chocomilk run has updated the URL, but not the checksum:
1f731bb

This leads to an installation error (expectedly).

I think the problem is that the regular expression:
https://github.com/open-circle-ltd/chocolatey.adobe-acrobat-reader-dc/blob/1f731bb6aebdd6ebfbdd4b52083273869dda8931/.milk.yml#L24-L27C18
is looking for single quotes, while the replacement inserts double quotes around the hash for the 64 bit flavour.

@aledeniz
Copy link
Contributor

aledeniz commented Jun 6, 2023

The PR #34 fixes the checksum, not the root cause.
It’s possible that all it needs is replacing the double quotes in line 27 with single quotes, but I don’t have a way to test it.

https://github.com/open-circle-ltd/chocolatey.adobe-acrobat-reader-dc/blob/1f731bb6aebdd6ebfbdd4b52083273869dda8931/.milk.yml#L24-L27C18

@pauby
Copy link

pauby commented Jun 7, 2023

I pushed a new version of the package today that fixes the checksum.

@olifre
Copy link
Author

olifre commented Jun 7, 2023

@pauby Many thanks!
@sbaerlocher Do you have time to look at the Chocomilk issue to prevent this issue from popping up again?
Thanks in advance!

@aledeniz
Copy link
Contributor

aledeniz commented Jun 7, 2023

@olifre the new version by @pauby did fix the checksum issue, not the underlying Chocomilk issue.
That said, the package wasn't working even after the checksum was fixed.
I spent almost all day on this, and my view is that the issue may have been caused by Adobe. Their installer (I tested the x64) at some point add a number of parameters, e.g. DISABLE_CACHE and PATCH. The latter causes the issue, as it is referencing a previous version, cached locally. This happens even in a greenfield install. I was able to replicate without Chocolatey involved, just with the deliverables by Adobe.
The only work around I found is to re-attempt the update, I have no idea why, but that seems to work (caveat: tried only 4 times so far, tomorrow I will do more extensive tests).
I have shared the code in PR #36.

@olifre
Copy link
Author

olifre commented Jun 7, 2023

@aledeniz Yes, I know, this is why I pinged @sbaerlocher so he could take a look to fix the underlying issue 😉 .

To add another data point, for me the fixed version of the package worked, i.e. a system having:
2023.1.20143 installed could update just fine to 2023.3.20201.1 afterwards. I did not test with a greenfield install, though.

@pauby
Copy link

pauby commented Jun 7, 2023

I tested a Greenfield install before I submitted the fixed package and it worked.

They're are two additional things that we need to be looked at:

  1. Packages are not being released for all versionsof the Adobe software (that's based on comments, not experience as I don't use the package).
  2. There is no response from contacting the maintainers via the Chocolatey package page. The lack of response, asking with missing versions, looks like the package has been abandoned.

I also have a question. Is there a reason this package does not use the MSI? It may be easier to work with and maintain.

@pauby
Copy link

pauby commented Jun 8, 2023

There appears to be another issue with the package that maybe related to Chocomilk (I'm unsure what that is but I'm assuming it's what you're using to update the package - I love the name though ❤️ ).

If I install package version 2023.3.20201.1 with choco install adobereader:

image

I get version 2023.001.20093 installed.

image

I haven't dug into this package enough, but it downloads the version 2023.001.20093 of the EXE and then the version 2023.003.20201 MSP. The log file indicates it's being run correctly:

2023-06-08 10:11:26,951 4956 [DEBUG] - Running Install-ChocolateyInstallPackage -silentArgs '/sAll /msi /norestart /quiet PATCH="C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx64Upd2300320201_MUI.msp" ALLUSERS=1 EULA_ACCEPT=YES  DISABLEDESKTOPSHORTCUT=1 DISABLE_ARM_SERVICE_INSTALL=1 UPDATE_MODE=0 /L*v "C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\adobereader.2023.3.20201.1.Install.log"' -file 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx642300120093_MUI.exe' -fileType 'EXE' -validExitCodes '0 1000 1101 1603' -packageName 'adobereader (installer)' 
2023-06-08 10:11:26,951 4956 [DEBUG] - Running Get-OSArchitectureWidth -compare '32' 
2023-06-08 10:11:26,951 4956 [INFO ] - Installing adobereader (installer)...
2023-06-08 10:11:26,982 4956 [DEBUG] - Ensuring 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey' exists
2023-06-08 10:11:26,982 4956 [DEBUG] - Ensuring 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey' exists
2023-06-08 10:11:26,998 4956 [DEBUG] - Running Start-ChocolateyProcessAsAdmin -validExitCodes '0 1000 1101 1603' -workingDirectory 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey' -statements '/sAll /msi /norestart /quiet PATCH="C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx64Upd2300320201_MUI.msp" ALLUSERS=1 EULA_ACCEPT=YES  DISABLEDESKTOPSHORTCUT=1 DISABLE_ARM_SERVICE_INSTALL=1 UPDATE_MODE=0 /L*v "C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\adobereader.2023.3.20201.1.Install.log" ' -exeToRun 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx642300120093_MUI.exe' 
2023-06-08 10:11:27,029 4956 [DEBUG] - Test-ProcessAdminRights: returning True
2023-06-08 10:11:27,029 4956 [DEBUG] - Elevating permissions and running ["C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx642300120093_MUI.exe" /sAll /msi /norestart /quiet PATCH="C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx64Upd2300320201_MUI.msp" ALLUSERS=1 EULA_ACCEPT=YES  DISABLEDESKTOPSHORTCUT=1 DISABLE_ARM_SERVICE_INSTALL=1 UPDATE_MODE=0 /L*v "C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\adobereader.2023.3.20201.1.Install.log" ]. This may take a while, depending on the statements.
2023-06-08 10:12:54,482 4956 [DEBUG] - Command ["C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx642300120093_MUI.exe" /sAll /msi /norestart /quiet PATCH="C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\AcroRdrDCx64Upd2300320201_MUI.msp" ALLUSERS=1 EULA_ACCEPT=YES  DISABLEDESKTOPSHORTCUT=1 DISABLE_ARM_SERVICE_INSTALL=1 UPDATE_MODE=0 /L*v "C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\adobereader.2023.3.20201.1.Install.log" ] exited with '0'.
2023-06-08 10:12:54,497 4956 [DEBUG] - Finishing 'Start-ChocolateyProcessAsAdmin'
2023-06-08 10:12:54,497 4956 [INFO ] - adobereader (installer) has been installed.

Exited with 0 indicates the installer completed successfully. I would hope that if the patch was not being applied correctly, it wouldn't exit with 0. But maybe the comment above indicates /PATCH is no longer working as it should?

This may be better in a separate issue so as not to pollute this one. I'll leave that for you to decide if you want to split them.

@aledeniz
Copy link
Contributor

aledeniz commented Jun 8, 2023

@pauby if you look at the log in C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\adobereader.2023.3.20201.1.Install.log and search for "PATCH=", you will find that the command line is reported as being run with 2 PATCH= parameters (in my scenario also with 2 DISABLE_CACHE parameters and 2 REBOOT parameters). I gave an example in one of the comments for the PR #36.
Unfortunately only the second PATCH parameter is honoured.
IMVHO this is an issue on the Adobe side.
Both PR #36 by myself and PR #37 by @conitrade-as are attempts to work that around re-applying the target update after the install phase.
I have tested PR #36 in 200 computers, it seems working fine for my scenarios, I am now testing PR #37, which could be preferable as it is more aligned with the previous code and coding style.

Yes, I believe it is a separate issue. Seen from another point of view: PR #36 is an attempt to fix #31, which would also fix #32, while PR #37 is an attempt to fix #32 , which would also fix #31.

@threechord82
Copy link

Is there a simple way to solve the problem of @pauby (by giving any parameters or the like)?
We use Choco to manage almost 500 computers that now all have version 093 installed and stand out in the security check. (CVE-2023-26423 etc)
Of course I could build my own package again, but exactly to minimize such steps we decided to use Choco.

@aledeniz
Copy link
Contributor

@threechord82 I have tested both PR #36 and PR #37 and I have upgraded successfully 364 computers while attempting the upgrade on 627. The main issue for the failure is that in most of those 263 computers 2023.3.20201.1 had already been attempted, so choco believes that has already been upgraded. We are planning to re-apply PR #37 on those 263 computers with --force, we are currently testing that work around.

@regexaurus
Copy link

I also have a question. Is there a reason this package does not use the MSI? It may be easier to work with and maintain.

@pauby, I may have misunderstood your question, and I may well be wrong about this, but I think at least some minor point releases of Acrobat Reader for Windows are MSP only...?

@pauby
Copy link

pauby commented Jun 15, 2023

@regexaurus if that is the case, it makes sense.

Just to be clear are you saying the only way to get those point releases is with the MSP? They are not released as an MSI?

@regexaurus
Copy link

I believe that is correct, but unfortunately I'm unable to point to official Adobe documentation/policy that states this.

@aledeniz
Copy link
Contributor

aledeniz commented Jun 16, 2023

@pauby the documentation is here.

Adobe uses terms as "base installer" for the exe and "update" for the msp.

The documentation suggests there should be a full installer ("Latest full installer") at get.adobe.com, but AFAIK that link doesn't work (it just redirects to https://www.adobe.com/). It may be a location based issue (perhaps it may work for people logging from the USA?).

Their release notes only list the msp files.

@aledeniz
Copy link
Contributor

@pauby @regexaurus:

We had 2 calls with Adobe about the fact that their installer doesn't appear to support the PATCH parameter.

My understanding of the outcome is that:

  • They do not support the strategy used by the adobereader package to install in a greenfield computer. In detail, calling the exe of v 2023.1 (the baseline) with the patch of version 2023.x in the PATCH of the command line will fail. The PATCH command will not be honoured. When using an exe baseline and a msp patch they expect these to be executed consecutively (first the exe and then msiexec with the msp). They do that internally in their Setup.exe.

  • The exe of every version is available shortly after the msp, even if not explicitly published in the release note. The Adobe engineer explained all we have to do is to replace some bits on the URI used by the adobereader package to download the baseline (e.g. replacing 2300120093 with 2300320201 will get https://ardownload2.adobe.com/pub/adobe/acrobat/win/AcrobatDC/2300320201/AcroRdrDCx642300320201_MUI.exe and so on).

  • If the maintainers of the adobereader package, or even better Chocolatey, were to reach them out, they seemed open to have a look at the issue(s), as they do understand this package is used for millions of computers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants