File content in result does not match the real file

dolmen commented 9 years ago

With this search http://grep.cpan.me/?q=MANIFEST[^.]+file%3A.t+dist%3DIO-Socket-SSL+file%3Dt%2Fcore.t I get:

IO-Socket-SSL-2.012/t/core.t

local *MANIFH; open MANIFH, "MANIFEST" or die "No MANIFEST?!: $!"; while () {[

local *MANIFH; open MANIFH, "MANIFEST" or die "No MANIFEST?!: $!"; while () {

L, LSQL::Translator This file contains message digests of all files listed in MANIFEST, signed via the Module::Signature module, version 0.27.

SHA1 1adcd25e8be40a3d228f13067e2d17f44f306eeb Changes SHA1 4683a6415d0a7c05e2592d376c068fc848871f09 MANIFEST SHA1 5b662aa37d4dc77e37257eb5565a89bf7cde03cf MANIFEST.SKIP SHA1 a27e5fab21a1952c32a452cd638aa5767fa

SULLR/IO-Socket-SSL-2.012

But the extracts above, do not match the content of t/core.t as I see on MetaCPAN.org or inside the archive.

Is it an indexing issue, or is there a MITM (that would not be so surprising for such a critical module as IO::Socket::SSL)?

dolmen commented 9 years ago

Just to eliminate the MITM case, here is my extract of /S/SU/SULLR/CHECKSUM.gz:

  'IO-Socket-SSL-2.012.tar.gz' => {
    'md5' => 'e8d6584271b8c9421115eede83d42182',
    'md5-ungz' => 'b75ec14240ec7509369df0d457b0c544',
    'mtime' => '2015-02-02',
    'sha256' => '02bd7f17ceb492e396eca6627f50aaa2a3ddfcb5bfa3889ddf145383b0b179d
9',
    'sha256-ungz' => '505065d2cca0f1ce9c15932a231e78223e6ba836b723fa1e0c44a448fd
faf519',
    'size' => 193636
  },

dolmen commented 9 years ago

I notice that SULLR/IO-Socket-SSL-2.013.tar.gz just appeared today... Is it just a coincidence? Anyway, t/core.t in that release does not match what grep.cpan.me shows me...

dgl / cpangrep

File content in result does not match the real file #40