#51886: nmap @7.12 Minor portfile fixes --------------------------+------------------------------ Reporter: gavin@… | Owner: opendarwin.org@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: nmap | --------------------------+------------------------------ Comment (by gavin@…): Replying to [comment:2 dluke@…]:
I'll try to take a look at this soon, some notes inline.
Replying to [ticket:51886 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. :)
-- Ticket URL: <https://trac.macports.org/ticket/51886#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X