Created attachment 150994 [details] www/qupzilla update to 1.8.5 and split into -qt4 and -qt5 variants QupZilla 1.8.5 release finally adds an option to disable use of SSLv3 entirely. The attached patch is from svn diff after `svn mv www/qupzilla www/qupzilla-qt4` and `svn cp www/qupzilla-qt4 www/qupzilla-qt5` Newer QtWebKit used by Qt5 variant supports WebGL and spellcheck also works. However, KWallet integration is commented out in Qt5 variant until KF5/KDE5 lands in the ports tree.
Created attachment 151547 [details] cleaned up patch for 1.8.5 update and port split svn diff output included a removal of all the files in old port dir that should have been copied and moved, so the patch has been cleaned up. The new patch file is just the changes that would follow the svn mv and svn cp commands previously noted.
Created attachment 151765 [details] Modified diff Hi, I have tested your patch and fixed a pair of minor problems: - Moved around some keywords to avoid portlint warnings. Please always use portlint on a port before submitting patches. - The QT5 version of the port missed two USE_QT5: concurrent and sql-sqlite3_run (it fails to start without the last one) - Both ports missed a file in the plist: %%DATADIR%%/themes/linux/images/goto.png Can you test thee ports and approve this revised patch? Thanks!
Created attachment 151782 [details] improved patch Thanks for reviewing. I have updated my patch based you your feedback. Neither concurrent nor sql-sqlite3 are mentioned in PH 6.11.2. The former appears to be new to Qt5, but the latter was present in Qt4 and should be needed just the same for both ports. I had all Qt deps present due to installing the meta-ports so hadn't noticed the dependency on concurrent, the Qt5 port ran just fine for me using the same Qt deps as the Qt4 port. The dependency on sqlite3 in both ports was likely missed because that would have already been pulled in on most systems. I added the sqlite3_run dep in both ports to be on the safe side. The one file added to pkg-plist should have been in original patch, added now. I noticed that in addition to re-ordering bits of the Makefile to quiet portlint, you also changed the MASTER_SITES from a https:// to a http:// address. I see no reason for that change.
I forgot to mention the MASTER_SITE change, sorry. portlint generates a warning with an explanation about https download URLS: WARN: Makefile: no ftp/http mirror in MASTER_SITES for users behind a proxy. it is suggested that at least one plaint http/ftp site is provided for download for users with restricted internet access. Since https isn't mandatory for github I changed that. It is just a public distfile, there's no personal information involved, is there a specific reason why https should be preferred?
People still use proxies that can't do HTTPS? *sigh* The MASTER_SITES URL got changed to GitHub when upstream changed the distribution tarball to xz. I put the https URL because that's what I got from upstream on IRC. I think everthing should be going over secured channels regardless of the purpose. Instead of asking why use HTTPS, I must ask why NOT use HTTPS? This is a public distfile, nothing secret inside. In theory using HTTPS and verifying the certificate adds a level of assurance the sources have not been tampered in transit. Are broken proxies still a real issue for more than a few odd cases? If so, then a general solution is needed that allows use of HTTPS and that is a matter outside the scope of this partcular PR.
(In reply to matthew from comment #5) I was not making a statement about SSL with my question, I'm just applying an existing policy(with which I happen to agree, but this is irrelevant). The policy is to avoid, if possible, https for distfiles. Regarding your statement about tampering with the distfile, please note that the ports tree performs a size check and then a SHA256 checksum, so the distfile is checked for integrity anyway before performing decompression.. Anyway since you insist ion it, and the port already uses SSL I'll leave it as is and commit your last patch.
Committed. Thanks!
A commit references this bug: Author: madpilot Date: Sun Jan 18 20:21:35 UTC 2015 New revision: 377345 URL: https://svnweb.freebsd.org/changeset/ports/377345 Log: - Create separate QT4 and QT5 ports for www/qupzilla - Update to 1.8.5 PR: 196302 Submitted by: matthew at reztek.cz (maintainer) Changes: head/MOVED head/www/Makefile head/www/qupzilla/ head/www/qupzilla-qt4/ head/www/qupzilla-qt4/Makefile head/www/qupzilla-qt4/distinfo head/www/qupzilla-qt4/pkg-plist head/www/qupzilla-qt5/ head/www/qupzilla-qt5/Makefile head/www/qupzilla-qt5/distinfo head/www/qupzilla-qt5/pkg-plist
(In reply to Guido Falsi from comment #6) Thank you very much for committing. I did not mean to insist on HTTPS, just to seriously question the reason for HTTP. If it's policy, then the port should conform for now. It is possible to just list both URLs to allow fetch to do a HTTP request if HTTPS has failed, but for those who want TLS that is insecure in that it allows a forced fallback to unencrypted. Seperately, I shall think about how to better handle this. The SHA sums are a single layer of security, TLS downloads are another.