id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
15624	[Patch draft] It would be far too easy to hijack a plugin with malicious code	ris	team	"(apologies if there is already a bug on this subject, I couldn't find it)

Right now, all a malicious actor would have to do is replace a link to a relatively popular plugin on https://josm.openstreetmap.de/wiki/PluginsSource and potentially thousands of users would have their josm ""automatically upgrade"" to it. Possibly the change could be disguised by just using a very-similarly-named github user.

I see this as quite a real problem and could be something that harms JOSM adoption, even if it doesn't ever happen to get exploited. I suspect it might not pass an organization's thorough IT audit and could preclude its use in large organizations or government bodies. Just this month I was proposing to an NGO implementing some tool they wanted as a JOSM plugin, and as a professional I really have to consider whether I would want to expose their systems to this risk.

Clearly, following java's trodden-path of jar signing and requiring all plugin authors to have jar-signing-capable PKI certificates would be a significant burden (or would it if you were able to be your own pseudo-CA and bundle your own root certificate with josm?), but it might also be possible to use java's jar-signing mechanism to implement a form of TOFU which would go a long way towards settling the hijacking worry (josm would show a warning if trying to upgrade a plugin that was signed with a different key?).

What are peoples' thoughts on this?"	enhancement	new	normal		Plugin			plugin jar signing certificate tofu security