nmap @7.12 Minor portfile fixes

[iamGavinJ (GΛVĪN)]

• Livecheck was picking up BETA versions so I implemented the livecheck.regex
• Switched ${homepage} to the HTTPS version
• Corrected ${master_sites) by removing two old URLs and added one new one
• Removed insecure MD5 and SHA1 checksums
• Added "--with-libpcap=DIR" to configure.args;
  • This may not be necessary but there is some ambiguity whether make was linking from CFLAGS & LDFLAGS. It appears without this switch it may build against its own version included in the distfile which would make the existing dependency irrelevant.

[danielluke (Daniel J. Luke)]

I'll try to take a look at this soon, some notes inline.

Replying to gavin@…:

• Livecheck was picking up BETA versions so I implemented the livecheck.regex
• Switched ${homepage} to the HTTPS version
• Corrected ${master_sites) by removing two old URLs and added one new one
• Removed insecure MD5 and SHA1 checksums

There is no downside to having those checksums in the portfile (as port will check against any/all listed checksums). I need to double-check and see if upstream releases checksums for their releases (as that's usually the reason why we'd keep md5 or sha1 around).

• Added "--with-libpcap=DIR" to configure.args;
  • This may not be necessary but there is some ambiguity whether make was linking from CFLAGS & LDFLAGS. It appears without this switch it may build against its own version included in the distfile which would make the existing dependency irrelevant.

otool output says it links with the one in $prefix on my system - did you actually notice a problem somewhere?

[iamGavinJ (GΛVĪN)]

Replying to dluke@…:

I'll try to take a look at this soon, some notes inline.

Replying to gavin@…:

• Livecheck was picking up BETA versions so I implemented the livecheck.regex
• Switched ${homepage} to the HTTPS version
• Corrected ${master_sites) by removing two old URLs and added one new one
• Removed insecure MD5 and SHA1 checksums

There is no downside to having those checksums in the portfile (as port will check against any/all listed checksums). I need to double-check and see if upstream releases checksums for their releases (as that's usually the reason why we'd keep md5 or sha1 around).

Not sure what you mean regarding upstream releases but i'll take your word for it. I was just imagining a scenario where malicious code could be introduced into the source taking advantage of the known hash collisions but still making the checksum valid. I realise there's a number of very specific conditions which would also need to be setup to make the scenario actually exploitable but I just figured for a security related tool like this, if possible, it would be better than not to deprecate these HMACs.

• Added "--with-libpcap=DIR" to configure.args;
  • This may not be necessary but there is some ambiguity whether make was linking from CFLAGS & LDFLAGS. It appears without this switch it may build against its own version included in the distfile which would make the existing dependency irrelevant.

otool output says it links with the one in $prefix on my system - did you actually notice a problem somewhere?

No issues, I just noticed the --with-libpcap=included vs. --with-libpcap=DIR and thought it wouldn't hurt to be explicit in case the default behaviour changed in the future. Was just trying to be thorough. :)

[danielluke (Daniel J. Luke)]

Replying to gavin@…:

Not sure what you mean regarding upstream releases but i'll take your word for it.

If upstream provides an md5 or sha1 hash, it's useful to be able to have the same hash in the portfile.

I was just imagining a scenario where malicious code could be introduced into the source taking advantage of the known hash collisions but still making the checksum valid. I realise there's a number of very specific conditions which would also need to be setup to make the scenario actually exploitable but I just figured for a security related tool like this, if possible, it would be better than not to deprecate these HMACs.

Macports validates the distfile against all of the hashes in the portfile. For that attack to work, you'd have to generate a malicious file that collides with each hash listed (having a weak hash like md5 or sha1 doesn't stop Macports from using the sha256 checksum).

[iamGavinJ (GΛVĪN)]

Replying to dluke@…:

Replying to gavin@…:

Not sure what you mean regarding upstream releases but i'll take your word for it.

If upstream provides an md5 or sha1 hash, it's useful to be able to have the same hash in the portfile.

Got it.

I was just imagining a scenario where malicious code could be introduced into the source taking advantage of the known hash collisions but still making the checksum valid. I realise there's a number of very specific conditions which would also need to be setup to make the scenario actually exploitable but I just figured for a security related tool like this, if possible, it would be better than not to deprecate these HMACs.

Macports validates the distfile against all of the hashes in the portfile. For that attack to work, you'd have to generate a malicious file that collides with each hash listed (having a weak hash like md5 or sha1 doesn't stop Macports from using the sha256 checksum).

Ah there be my incorrect assumption. I thought checksumming was an 'OR'. Thanks for clarifying.

[chrstphrchvz (Christopher Chavez)]

In 04884ade0dd20e75a3efab79b5926670228e27ae/macports-ports (master):

nmap: use HTTPS homepage

See: #51886