search

mozilla-services / autograph

Mozilla's digital signature service
https://hub.docker.com/r/mozilla/autograph/
Mozilla Public License 2.0
152 stars 34 forks source link

When signing omnija, we create invalid zip files #278

Open Callek opened 5 years ago

Callek commented 5 years ago

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.

g-k commented 5 years ago

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?

Callek commented 5 years ago

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")

catlee commented 5 years ago

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.

jvehent commented 4 years ago

Given the upstream issue was wontfixed, is there anything actionable for us here? Are we happy keeping the ZipFile workaround forever?