consider not generating/publishing hashes for MARs



2 years ago
3 months ago


(Reporter: bhearsum, Unassigned)


Firefox Tracking Flags

(Not tracked)




2 years ago
Yesterday I learned that the hashes we publish in update responses do not get used ( when signing is on. Given that we sign MARs on all platforms now, should we stop generating and publishing unnecessary hashes?
Do we still need to publish the size of MARs?
Priority: -- → P3
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #1)
> Do we still need to publish the size of MARs?

Tom, Julien, any thoughts on this?
Flags: needinfo?(tom)
Flags: needinfo?(jvehent)
I think MAR signing (and possibly signing the XML documents in bug 1304782) provides sufficient security, so OK to remove the hashes.
Flags: needinfo?(jvehent)

Comment 5

a year ago
Just to make sure I understand, we're talking about the sha512 in the updates.xml file as seen here right:

> <update appVersion="53.0a2" buildID="20170301084303" channel="aurora" displayVersion="53.0a2" installDate="1488381778682" isCompleteUpdate="false" isOSUpdate="false" name="Firefox Developer Edition 53.0a2" serviceURL="" showNeverForVersion="false" showPrompt="false" promptWaitTime="691200" backgroundInterval="0" type="minor" detailsURL="" previousAppVersion="53.0a2" statusText="Nakabinbin na Pag-Install" platformVersion="53.0a2" foregroundDownload="true"><patch type="complete" URL="" finalURL="" hashFunction="sha512" hashValue="8a84dd34cca8306b73c7754d8189d6481a6bd2ac0d84b01be358a97d803fd76cae045350fe3c492aec2d9f91f379b52ebfe4ba57f984af6d8d922caa23fc454e" size="65793254" selected="true" state="failed"/></update>

If so, I agree, no need to do this. 

In the future I think it will be good to have hashes of signed objects in a log (some of my thoughts are at )but that will be in a different place than here and won't need to be sent to the client.
Flags: needinfo?(tom)
Filed bug 1373267 to remove the hashFunction and hashValue attributes from nsIUpdatePatch, etc.

Comment 7

a year ago
We'll have to be careful on the Balrog side to avoid breaking submission tools, and ensure that we continue to serve hashFunction/hashValue to older clients that still require it. I think we'll probably want to continue returning responses that have hashFunction/hashValue in them until we have a watershed that includes the new client code that doesn't require it.

When we do make the switch, we'll have to be careful to avoid breaking the submission tools. We'll probably want a new type of blob that accepts hashFunction/hashValue as an input, but doesn't return it in the XML. Once that's in place, we can update the client tools to stop sending it. We'll probably need to branch that code to ensure that we continue to send it for ESR or other other older branches that still require it.
Component: Release Automation: Other → Release Automation: Updates
You need to log in before you can comment on or make changes to this bug.