On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green > <12861109+dellgr...@users.noreply.github.com> wrote: > >> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be >> able to cross compile javafx for arm hard float. Up to now the upstream >> distribution versions have been debian and raspbian wheezy, but these are >> now end of life and have been archived to servers that have different domain >> names. >> >> Tried to change to use jessie but this generates a whole load of __THROWNL >> errors, so for now have updated the domain names to point to new servers so >> that wheezy packages can still be retrieved and cross compilation succeeds. >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >> >> ---------------- >> >> Commits: >> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource >> domain names for wheezy >> >> Changes: https://git.openjdk.java.net/jfx/pull/8/files >> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: > >> 231: http://archive.debian.org/debian/ wheezy main armhf \ >> 232: libatk1.0-dev \ >> 233: libatk1.0-0 \ > > The use of `http://` URLs to download artifacts is strongly discouraged, > since it isn't secure. Is there a valid `https://` URL that can be used > instead? I note that just substituting `http` with `https` in the above URL > does not work. > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: > >> 391: $DESTINATION \ >> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >> 393: libraspberrypi-dev > > Same comment hear about using an `https` URL if possible. > > I don't have any particular issue with this change. It does highlight an > existing problem where we are still using an `http` URL rather than `https`. > That may or may not be something we can solve here. In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. PR: https://git.openjdk.java.net/jfx/pull/8
