info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Peep mismatches on GitHub zip URLs
2 views
Skip to first unread message
Erik Rose
May 20, 2015, 2:37:46 PM5/20/15
to dev-webdev
"THE FOLLOWING PACKAGES DIDN'T MATCH THE HASHES SPECIFIED IN THE REQUIREMENTS FILE."
You've probably been seeing that for the past hour or so if you have any peep requirements that pull zip files from GitHub. It appears that GH has changed how it builds zip files, making this a false alarm.
Why believe it's a false alarm? Spotchecking reveals that neither the contents nor the mod dates of the zipped files has changed. Thus, if it's an attack, it's (1) an attack on an unzipper (for example, an exploit of a buffer overflow) or (2) a MITM pretty close to GH's servers, since downloads from the MV office, Jenkins, and another, non-Mozilla datacenter all yield the same, new hashes. The first difference between the archives we compared occurred around the 15K mark, so it's not a simple header difference. That's as deep as we went.
So the recommended amount to freak out is fairly low. I suggest you update your hashes and move on. If you're sufficiently paranoid, you can re-vet the packages, comparing them with known-good versions. Thanks to peterbe for helping me dig into this.
Cheers,
Erik
You've probably been seeing that for the past hour or so if you have any peep requirements that pull zip files from GitHub. It appears that GH has changed how it builds zip files, making this a false alarm.
Why believe it's a false alarm? Spotchecking reveals that neither the contents nor the mod dates of the zipped files has changed. Thus, if it's an attack, it's (1) an attack on an unzipper (for example, an exploit of a buffer overflow) or (2) a MITM pretty close to GH's servers, since downloads from the MV office, Jenkins, and another, non-Mozilla datacenter all yield the same, new hashes. The first difference between the archives we compared occurred around the 15K mark, so it's not a simple header difference. That's as deep as we went.
So the recommended amount to freak out is fairly low. I suggest you update your hashes and move on. If you're sufficiently paranoid, you can re-vet the packages, comparing them with known-good versions. Thanks to peterbe for helping me dig into this.
Cheers,
Erik
Paul McLanahan
May 21, 2015, 11:02:35 AM5/21/15
to Erik Rose, dev-webdev
Just as an FYI, we didn’t see any issues in bedrock because it seems
this really did only affected the “.zip” files. They appear not to
have messed with the “.tar.gz” files, which it turns out is all we use
from Github. Not sure which will remain more stable in the future, but
for now the tarballs win.
- pmac
--
Paul [pmac] McLanahan
Sr. Web Developer @ Mozilla
http://pmac.io
this really did only affected the “.zip” files. They appear not to
have messed with the “.tar.gz” files, which it turns out is all we use
from Github. Not sure which will remain more stable in the future, but
for now the tarballs win.
- pmac
--
Paul [pmac] McLanahan
Sr. Web Developer @ Mozilla
http://pmac.io
Gervase Markham
May 22, 2015, 6:24:12 AM5/22/15
to mozilla-d...@lists.mozilla.org
On 21/05/15 16:02, Paul McLanahan wrote:
> Just as an FYI, we didn’t see any issues in bedrock because it seems
> this really did only affected the “.zip” files.
I just tried installing bedrock dependencies (from dev.txt) yesterday in
> Just as an FYI, we didn’t see any issues in bedrock because it seems
> this really did only affected the “.zip” files.
a virtualenv and got this error...
Gerv
Paul McLanahan
May 22, 2015, 7:10:50 AM5/22/15
to gerv @m.o, mozilla-d...@lists.mozilla.org
On May 22, 2015 6:24 AM, "Gervase Markham" <ge...@mozilla.org> wrote:
>
> On 21/05/15 16:02, Paul McLanahan wrote:
>
> On 21/05/15 16:02, Paul McLanahan wrote:
> > Just as an FYI, we didn’t see any issues in bedrock because it seems
> > this really did only affected the “.zip” files.
>
> > this really did only affected the “.zip” files.
>
> I just tried installing bedrock dependencies (from dev.txt) yesterday in
> a virtualenv and got this error...
There could easily be a wheel version hash we've failed to add to the file.
> a virtualenv and got this error...
I used the --no-use-wheel flag for my test. Ping me on irc with specifics
and I'm sure we can fix it.
0 new messages