UTIL_LOG define is a NOOP when I build dbg-win

[Thom BENTLEY]

I just built my repo fork of omaha (installer).  I've set my installer's ini file to
[LoggingLevel]
LC_CORE=5
LC_NET=4
LC_PLUGIN=5
LC_SERVICE=5
LC_SETUP=5
LC_SHELL=5
LC_UTIL=5
LC_OPT=5
LC_REPORT=5
[LoggingSettings]
EnableLogging=1
LogFilePath="C:\AppUpdate.log"
MaxLogFileSize=10000000
ShowTime=1
LogToFile=1
AppendToFile=1
LogToStdOut=0
LogToOutputDebug=1
[DebugSettings]
SkipServerReport=1
NoSendDumpToServer=1
NoSendStackToServer=1

I had expected building dbg-win to build all the logging in so I could debug an issue I have.
It did help me find out that it is failing on the VerifyHash step.  Just not why because UTIL_LOG messages aren't in the log file.

I'll poke around the code to see what I can find, but if you know, please tell me the secret.

Thanks.

---

The information in this email and any attachments are intended solely for the recipient(s) to whom it is addressed, and may be confidential and/or privileged. Any unauthorized distribution or copying of this transmittal or its attachments is prohibited. If you are not a named recipient or have received this email in error: (i) you should not read, disclose, or copy it, (ii) please notify the sender of your receipt by reply email and delete this email and all attachments.

[Sorin Jianu]

On Tue, Mar 19, 2024 at 8:56 AM Thom BENTLEY <tben...@mdsol.com> wrote:

I just built my repo fork of omaha (installer).

Great news!

Thank you. I suggest writing additional log statements to narrow down the scope where the code is failing.

 

Thanks.

---

The information in this email and any attachments are intended solely for the recipient(s) to whom it is addressed, and may be confidential and/or privileged. Any unauthorized distribution or copying of this transmittal or its attachments is prohibited. If you are not a named recipient or have received this email in error: (i) you should not read, disclose, or copy it, (ii) please notify the sender of your receipt by reply email and delete this email and all attachments.

--
You received this message because you are subscribed to the Google Groups "Omaha Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omaha-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/d7942c56-e13a-4388-83d0-42c2cfd6d309n%40googlegroups.com.

[Sorin Jianu]

I don't know why in your build UTIL_LOG expands to nothing.

In github, I see this, which is similar to the other categories which show up in the log.

#define UTIL_LOG(x, y)         LC_LOG_DEBUG(omaha::LC_UTIL, x, y)

I suggest modifying the source code to confirm whether or not UTIL_LOG logs. Otherwise, if the log statement is

not showing up in the log, it may be because the execution path is not taken.

On Tue, Mar 19, 2024 at 8:56 AM Thom BENTLEY <tben...@mdsol.com> wrote:

--

[Thom BENTLEY]

Thanks.  Did you see my question about some logging still not coming out in the log file?
Do you know why all log messages aren't coming out now that I've created a debug version and provided the log levels listed in this post?

[Sorin Jianu]

On Tue, Mar 19, 2024 at 9:09 AM Thom BENTLEY <tben...@mdsol.com> wrote:

Thanks.  Did you see my question about some logging still not coming out in the log file?
Do you know why all log messages aren't coming out now that I've created a debug version and provided the log levels listed in this post?

Just to check for my understanding, is there a problem with LC_UTIL or the log is not working at all in debug mode?

I am referring to `all log messages aren't coming out` in the sentence above.

To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/9c6990f2-8658-4a97-8e40-4bc609c921c8n%40googlegroups.com.

[Thom BENTLEY]

Sorry, I meant that not all expected messages are coming out.
LC_UTIL / UTIL_LOG aren't.  I've resorted to using CORE_LOG messages since they appear in the log.

[Thom BENTLEY]

It looks like  Base64::Decode is setting the hash size to the SHA256 size of 32.  
It should be using 20 for SHA1 based on the fact we are in the VerifyFileHash method.

  std::vector<byte> hash_vector;
  RET_IF_FAILED(Base64::Decode(expected_hash, &hash_vector));
if (!crypto.IsValidSize(hash_vector.size())) {  fails since hash_vector.size() returns 32 and hash_size(); in signature.h is likely returning 20.

I'm double checking that theory.

[Sorin Jianu]

The `sha` string listed in a response posted in the other email thread decodes to exactly 32 bytes, which suggests that the

SHA hashes returned by your update server are SHA256.

To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/c80789d4-67ab-4332-a114-fd80b4e08ee6n%40googlegroups.com.

[Thom BENTLEY]

How does the hash generation get configured on the update server?  Also, the value seems to be coming in as a  hash  parameter in the response instead of the  hash_sha256?
<package required="true" hash="EI1Drkn5yIwa9ZbLLprKKyrRAUfx9C0G4tguUlQbmc4=" name="Install-Director-5.0.0.5.exe" size="13445120"/>

The protocol version is 3.0
<response protocol="3.0" server="prod">

Thanks

[Thom BENTLEY]

Also, it seems the wrong path is being taken.   I would expect this code to select  VerifyFileHashSha256 instead of  VerifyFileHash 
HRESULT hr = expected_hash.sha256.IsEmpty() ?
    VerifyFileHash(files, expected_hash.sha1) :
    VerifyFileHashSha256(files, expected_hash.sha256);

[Sorin Jianu]

On Tue, Mar 19, 2024 at 1:44 PM Thom BENTLEY <tben...@mdsol.com> wrote:

How does the hash generation get configured on the update server? 

That is something we don't know. The hash creation is entirely in the scope of the team that manages updates for this project.

Also, the value seems to be coming in as a  hash  parameter in the response instead of the  hash_sha256?
<package required="true" hash="EI1Drkn5yIwa9ZbLLprKKyrRAUfx9C0G4tguUlQbmc4=" name="Install-Director-5.0.0.5.exe" size="13445120"/>

The protocol version is 3.0
<response protocol="3.0" server="prod">

hash must be a sha1, hash_sha256 must be SHA256.

To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/e901ac41-9f23-403a-a32c-ceb339780409n%40googlegroups.com.

[Thom BENTLEY]

I'm not sure what you mean by:  The hash creation is entirely in the scope of the team that manages updates for this project.
I was hoping there is a control to set or look for in the Omaha update server configuration or code.  
This server has been running fine and the older versions stored there will install correctly without this cache/hash issue.

I hope a contributor to the Omaha Update Server has the info we need.

Is this the right group for folks like that?

Thank you very much for all the help so far.

[Sorin Jianu]

On Tue, Mar 19, 2024 at 2:50 PM Thom BENTLEY <tben...@mdsol.com> wrote:

I'm not sure what you mean by:  The hash creation is entirely in the scope of the team that manages updates for this project.
I was hoping there is a control to set or look for in the Omaha update server configuration or code.  

I am a member of the team at Google who created the open source code that has been used to make the updater which you are trying to debug right now.

We operate Google's own update servers, but we have no relation whatsoever with the entity that is running your servers. We have not open sourced our

backends and don't know what code and who is running your update servers.

 

This server has been running fine and the older versions stored there will install correctly without this cache/hash issue.

I hope a contributor to the Omaha Update Server has the info we need.

Is this the right group for folks like that?

There is not such a group at Google or a contributor to an Omaha Update Server project. I've heard that such a project exists (or existed), but it is not a Google project and

I have no information about it.

 

Thank you very much for all the help so far.

You are welcome! I am happy to help. I suggest reaching out to people who manage the backends that the updater is talking to. They'll know.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/dd4b6d86-9424-47dd-be00-acd338369a1an%40googlegroups.com.

[Thom BENTLEY]

Hi Sorin, 

Thanks for the clarification.  Since the client code was a direct fork of the Google repository, I had thought the update server was too.
The code I'm working with is a fork of https://github.com/omaha-consulting/omaha-server/blob/master/README.md

I'll reach out to them since it is they who implemented it as a way to provide the server side of Google's Omaha update protocol.

The company I work for received the fork when Omaha Consulting was hired to provide an update client and server for a product.

Thanks again, 

Thom