mozilla-services
When signing omnija, we create invalid zip files
So @catlee noticed from our earlier test of doing an omnija signing:
yeah, zip files have two copies of file metadata: one in the "central" directory, and one that precedes each file in the archive called the "local" header. autograph isn't setting the correct sizes or crc in the local header. the ones in the central directory are fine
This makes it so that the build system code that handles omni.ja files for Firefox can't read or use the files produced by autograph, because it reads and tries to use the localheader too.
I have a workaround (using python ZipFile) which does not enforce this metadata existing correctly, so urgency is not high.
Huh I don't think we're doing anything that isn't idiomatic go in: https://github.com/mozilla-services/autograph/blob/master/signer/xpi/jar.go
Maybe https://github.com/golang/go/issues/28602 is related
@Callek can you link me to an example with incorrect headers?
I was testing with the files from https://drive.google.com/drive/folders/1yqKitxgD2OydARrpemByut2Jkdp9xPUx?usp=sharing (I just removed "anyone at mozilla" sharing setting and left the "specific people")
Huh I don't think we're doing anything that isn't idiomatic go in: https://github.com/mozilla-services/autograph/blob/master/signer/xpi/jar.go
Maybe golang/go#28602 is related
Ah yes, that's probably it. And mozjar doesn't have support for those data descriptors.
Given the upstream issue was wontfixed, is there anything actionable for us here? Are we happy keeping the ZipFile workaround forever?
