These are chat archives for fiji/fiji

1st
Nov 2018
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:11
@ctrueden does the updater not work with https?
Curtis Rueden
@ctrueden
Nov 01 2018 20:14
@axtimwalde Nope, because some http URL is hardcoded and it does not follow redirects.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:15
even if I change the URL to https manually?
Curtis Rueden
@ctrueden
Nov 01 2018 20:15
Sure, it will fetch the stuff over HTTPS. But the bootstrapping uses e.g. http://imagej.net/List_of_update_sites.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:17
so fixing all the hardcoded URLs in the updater to https would fix this?
(over time)
Curtis Rueden
@ctrueden
Nov 01 2018 20:17
I think so, but then all the people running Fiji with 1.8.0_66 would no longer be able to update.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:18
is that a bad thing?
Curtis Rueden
@ctrueden
Nov 01 2018 20:18
Yes. Most people are in that situation.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:18
they could download a new version? (I am doing it all the time)
Curtis Rueden
@ctrueden
Nov 01 2018 20:18
If we are going to break Fiji updates for 75% of the userbase, I'd rather just deploy a new version of the updater with fewer warts.
Me too, but I don't think we are the typical scientific user.
Based on conversations I have had with scientists, a lot of them have heavily customized installations—dropped in plugins from IJ1 site, etc.—and needing to "redo" your Fiji is painful.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:20
but they would also break with updates, I think the conservative heavily customized installations never update anyways
Curtis Rueden
@ctrueden
Nov 01 2018 20:20
I think the way forward is to make the Updater smarter, so that it works with both http or https depending on the situation.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:20
I think it shouldn't, http is unsafe and should not be used to distribute binary executables
(if the user does not have the chance to test sanity with checksums obtained through alternative channels)
it also sounds simpler to not make the updater smarter and simply make a hard cut for good, people also install new operating systems or buy new hardware :)
(even typical scientists)
I know that I am repeating myself and I probably annoy you with it, sorry for that! But you have done so much great work to make everything https by now which is fantastic, and I find it sad to stop short of finishing this (in my eyes) very important security improvement
Curtis Rueden
@ctrueden
Nov 01 2018 20:28
Fair enough. You are not annoying me, it's OK. At minimum, though, I think what we want to do is have the Updater check if the version of Java is new enough, and if not, give an error telling user to update it themselves.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:29
Sounds perfect.
Curtis Rueden
@ctrueden
Nov 01 2018 20:29
This Java version check is more generally useful than just for HTTPS. My idea was actually to put this into the imagej-launcher Java code, and keep that component compatible with older Java versions.
In this way, we can eventually go to Java 9/10/11/etc. and then when Fiji starts up, it simply says "You need a newer Java. Please delete Fiji.app/java folder and install Java <whatever-version>" or similar.
We could, if we are ambitious, write a tool that does this automatically for the user, but I think it would be a deceptively high amount of work due to crap like Windows file locking.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:30
that would be very cool
right
Curtis Rueden
@ctrueden
Nov 01 2018 20:31
This has been the plan for quite some time, but you know how it goes. Who is going to do it when. Maybe a good topic to discuss in Dresden in December, now that we have more full-time people onboard.
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:32
sure, I think that would be an easy and simple project that is perfectly in line with the objectives of the denbi project
Curtis Rueden
@ctrueden
Nov 01 2018 20:32
:+1:
Stephan Saalfeld
@axtimwalde
Nov 01 2018 20:32
hey @fjug, are you reading this?
can you make one of your friends implement a java version check + warning in the imagej launcher so that we can end binary software distribution over insecure HTTP for good? I think ImageJ is currently one of the last wide open backdoors for man in the middle attacks to inject executable code that runs with full user permissions in the target platform. Everybody else is using end-to-end encryption (well, may be not Eclipse, but they are crazy)
Florian Jug
@fjug
Nov 01 2018 20:48
Hi @axtimwalde ... thanks for pinging me in here... interesting discussion ideed.
@frauzufall is currently thinking heavily about how to overhaul updater and launcher.
We are currently in the phase of not thinking about limits and collecting ideas and experience. She made big progress recently understanding the current state of update sites etc.
Anyways... long way to go, but in December we hope to be educated enough to have serious discussion about realistic plans and how it can pan out in the real world over time. Curtis will be here to be devils advocate which we see as an amazing chance.
I’d be happy to include you in this discussion too. Interested?
Regarding the concrete plans you discuss above I’m sure we can help doing something to help. (Again, we == @frauzufall... ;)
Florian Jug
@fjug
Nov 01 2018 20:53
)
Stephan Saalfeld
@axtimwalde
Nov 01 2018 21:00
I am primarily interested in stopping distribution of executables over interceptable HTTP. We are almost there. Everything else is secondary and can wait until after this has stopped. To make it more dramatic, ImageJ and Fiji are currently an enormous risk to the integrity of almost all major research institutions. We can stop this now with very little effort. Once this is fixed, we can start doing all kinds of fancy and cool new projects that don't have this problem in the first place.
Florian Jug
@fjug
Nov 01 2018 21:01
I’m with you, no worries!
Stephan Saalfeld
@axtimwalde
Nov 01 2018 21:01
well, it sounds as if you're planning larger overhauls and want to wait until after December which I find irresponsible :)
(enough of the Drama), do you and @frauzufall think that it would be possible to quickly write and add this Java version check and warning dialog now instead of after December, roll it out and then immediately shut down all http update sites?
(or make the updater not accept http update sites because evil)
Florian Jug
@fjug
Nov 01 2018 21:03
Maybe irresponsible... on the other hand... December is in 4 weeks... and the problem persisted for many years by now...
I will speak with her. I’m sure we can do something very soon. Still, she has to give a talk in Paris soon, and we all need to prepare shitloads of things for I2K... she has a family, there is CVPR deadline... you see... 4 weeks are not so long.
Proposal: we chat tomorrow or on Monday... you explain me/us what is missing and how we could fix it. I’m not having a good overview of the status quo and clearly need this. Sounds reasonable?
I’m pretty sure @frauzufall will be excited to help and do whatever she can in November.
@ctrueden , I’d also love to see you in the loop... more eyes see more and I’d like to avoid some updater Fiji scandal that breaks 1000s of Fiji’s or anything like that. Bene?
Stephan Saalfeld
@axtimwalde
Nov 01 2018 21:09
We recently had all ImageJ servers, including the maven repositories, blocked by HHMI IT because the Firewall had blocked the download of an ij.jar that was marked as malicious. False alarm? May be, unfortunately, the IT guys had already burned the file and deleted all useful information to track back who had requested it and from which server location, efficiently eliminating any possibility attempt to validate the issue (I was really mad about this as you can imagine).
I believe that a successful attack TROUGH Fiji would be a much bigger scandal for the project than an issue with the updater (people are used to this).
And now I will shut up! I said what I had to say, and I appreciate all your great work, particularly @ctrueden's!
Florian Jug
@fjug
Nov 01 2018 21:21
As said multiple times. Happy to help as soon as possible. E.g. by having a chat with @frauzufall and myself tomorrow or on Monday. If we shall invest time we have at least to understand what to do, right?
You, Debo, and I to be more clear... (sorry, this chat is happening in parallel to me trying to have an chilled evening with Gaia... ;) )
Deborah Schmidt
@frauzufall
Nov 01 2018 21:43
I agree that it is important and will get to it asap (though, as Florian said, there is little time in November). I was also wondering, could someone not just change the official update site URLs in the Wiki to distribute malicious updates? If that's the case, we were wondering if that list could live on github and if someone wants to add an update site, one could create a PR.
Curtis Rueden
@ctrueden
Nov 01 2018 21:53
Currently, the updater refuses to use the wiki page contents if the first couple of sites do not march hardcoded (HTTP!) values.
@axtimwalde I think your example of the "malicious" (false alarm) ij.jar would have happened even if we had fully switched to HTTPS.
Curtis Rueden
@ctrueden
Nov 01 2018 21:59
@frauzufall But your point is well taken for secondary update sites. Any of those URLs could be changed, sure.
Putting it on GitHub seems reasonable. Anyone who is creating an update site should be able to file a PR, hopefully.
Deborah Schmidt
@frauzufall
Nov 01 2018 22:10
What would be the right repository, https://github.com/imagej/imagej or a new one?
Curtis Rueden
@ctrueden
Nov 01 2018 22:12
Good question. I am not sure. Do we care about it being human readable from a web perspective?
If so, we could serve it on GitHub Pages as part of https://github.com/imagej/imagej.github.io
Alternately, or in addition, we could make https://imagej.net/List_of_update_sites proxy the content from GitHub Pages, in such a way that existing installations still work.
Niko Ehrenfeuchter
@ehrenfeu
Nov 01 2018 22:17
that list could live on github and if someone wants to add an update site, one could create a PR
I really like this idea!
:+1:
Deborah Schmidt
@frauzufall
Nov 01 2018 22:19
@ctrueden Yes showing the content from this imaginary github page on the current wiki page sounds nice. I think I would prefer this file to live on https://github.com/imagej/imagej-updater. Makes sense somehow.
Curtis Rueden
@ctrueden
Nov 01 2018 22:24
OK, so then we make a gh-pages branch of imagej-updater and access it via https://imagej.github.io/imagej-updater/update-sites or similar, and proxy that to the previous imagej.net URL. The downside of preserving compatibility is that we'll have to look carefully at the assumptions the updater code makes about the HTML structure, and ensure that that page conforms to that structure.
Bus ride over—gotta run for tonight. Happy to chat more about it later.
Deborah Schmidt
@frauzufall
Nov 01 2018 22:36
Ah, I was not aware that it needs to be a github page, I thought we could just use a raw file URL since it would be human-readable on the Wiki page. Anyways, I will look into HTTPS and put this update-sites-list issue on my TODO list, sounds manageable, and we can talk about it later.