Modify

Opened 8 months ago

Last modified 8 months ago

#16858 new enhancement

Moving jmapviewer to a separate repository

Reported by: michael2402 Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: hack-weekend-2018-10 Cc:

Description

Currently, jmapviewer is hosted on the OSM SVN repository and included as svn:external.

We want to get rid of svn:external

  • Include it in JOSM using ivy instead of snv:external (the ivy patch is ready to be applied for this)

We want to make it an independent project

  • Convert jmapviewer to a git repository
  • Move the repo to our gitlab server created in #16857
  • Change the build script to use gradle instead of ant (not relly needed, but we want an easy project to start and use the same build system for everything)

-- Moving to gradle allows us to have the same maven config for all projects.

  • Set up continuous integration there
  • deprecate the old SVN repo (delete / archive / remove all links)

Attachments (0)

Change History (9)

comment:1 Changed 8 months ago by floscher

JMapViewer contains two translatable strings:

  • Background Terms of Use
  • Opening link not supported on current platform (''{0}'')

These strings should be added to https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/i18n/specialmessages.java until the continuous integration of the new jmapviewer project generates a *.pot file in continuous integration.

comment:2 Changed 8 months ago by stoecker

Hmm. Actually I feel we should go the other way round. The project #15229 is the goal to modularize the JOSM core to make it more useful for outside use. The map viewer was an essential component of JOSM and went that path a lot earlier, so it could be used outside.

It started as the slippymap plugin and got redesigned as own library. Then the plugin was integrated in core and then development of the library was taken over by JOSM core developers. As there was always demand for keeping it usable outside JOSM it stayed that way although that sometimes needed additional care.

When the whole JOSM core is going that way, maybe it is time to re-integrate the component into the core as module?

comment:3 Changed 8 months ago by michael2402

Currently, we don't have a module system for core (and we won't have a full one for at least one year).

Our goal was to just integrate it the same way we want to do with other self-built dependencies (gettext, svgSalamander, ...). So acually the goal is to move source code away from the single JOSM repository instead of adding it.

comment:4 in reply to:  3 ; Changed 8 months ago by stoecker

Currently, we don't have a module system for core (and we won't have a full one for at least one year).

When infrastructure decisions are taken 1 years is nothing I consider relevant.

Our goal was to just integrate it the same way we want to do with other self-built dependencies (gettext, svgSalamander, ...).

I'd be more willing to agree to such an idea if you could show a plan how to solve the security implications of distributed source code.

So actually the goal is to move source code away from the single JOSM repository instead of adding it.

Security implications left aside:
To which advantage? Singular projects are fine if they are independently managed, but the reality looks different. After some time the maintainers loose interest and JOSM has to take over maintaining. Doing that at a lot of different places only adds a lot of additional work to the JOSM core members. Have a look at all the places where we already have to take care. Why should it be a good idea to add more?

comment:5 in reply to:  4 Changed 8 months ago by michael2402

A long-term goal of the module system is to add the jmapviewer as a JOSM module. For now, we wanted to go that way to make migration with preserving history easier, because the path then would be to migrate JOSM to git do a merge of the two git repository heads.

But for the transition period, jmapviewer would be our testing ground for testing the build / release system and for testing how a sooth transition to a modularized JOSM core is possible, since it currently is the only JOSM module that is already available.

comment:6 Changed 8 months ago by floscher

I'd be more willing to agree to such an idea if you could show a plan how to solve the security implications of distributed source code.

When discussing this at the HackWeekend we agreed to only use artifacts from our own infrastructure ( https://josm.openstreetmap.de/nexus ).

I think we could also pin the checksum of jmapviewer.jar (so the JOSM build downloads the *.jar and fails if the checksum does not match.
It would also be a good idea to sign the build artifacts on our Nexus with PGP (by the way: AFAIK that's a requirement for artifacts published to Maven Central).

Such additional mechanisms would be a good idea, but if your attack scenario would be that an attacker puts a rogue *.jar file on our Nexus, the attacker would probably also be able to circumvent such mechanisms (by modifying JOSM directly or reading the private PGP key used for signing and publish a rogue *.jar).

comment:7 in reply to:  6 Changed 8 months ago by Don-vip

Replying to floscher:

It would also be a good idea to sign the build artifacts on our Nexus with PGP (by the way: AFAIK that's a requirement for artifacts published to Maven Central).

OK I'll look into this.

comment:8 Changed 8 months ago by michael2402

For the beginning, it would be perfectly fine to have a reference to the JOSM nexus (https) and just pull from there, without any checksums, assuming that our server (where we host git / ...) and our CI runners (that actually generate the artefacts) are safe.

comment:9 in reply to:  8 Changed 8 months ago by floscher

Replying to michael2402:

For the beginning, it would be perfectly fine to have a reference to the JOSM nexus (https) and just pull from there, without any checksums, assuming that our server (where we host git / ...) and our CI runners (that actually generate the artefacts) are safe.

Yes, that's what I meant. As long everything is running on our infrastructure that we have control over, we can trust the artifacts. In case of a potential attack, checks of signatures or checksums wouldn't help much, since such an attack would probably compromise the whole server not only the Nexus repo isolated.

So PGP signing would be nice-to-have but not necessary as long as everything is on the same server. Version pinning using a checksum wouldn't be needed.

Replying to Don-vip:

OK I'll look into this.

With Gradle this can be done using the Signing plugin, the josm-atlas plugin already signs their releases.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to michael2402
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.