Comments on the module-file format
mr at sun.com
Fri Feb 5 12:07:53 PST 2010
> Date: Fri, 05 Feb 2010 10:55:02 +0100
> From: Patrick Wright <pdoubleya at gmail.com>
> I'd like to quickly note three use cases which come up in real-world
> module distribution, ...
> 1) The module artifact has a checksum by which the repository manager
> (e.g. Maven) can determine if the local copy of the artifact is
> up-to-date. AFAIK, this is to cover the case that an artifact was
> updated in-place.
The hash in a module file's main header can be used for this purpose.
> This in turn can happen if the distributor makes a
> small mistake in packaging, for example, but does not want to rev the
> version number, or within teams, using a single "snapshot" version
> which is regularly overwritten. ...
I share Brian Pontarelli's concerns regarding in-place updates and
snapshot versions, though in a module system -- as opposed to a build
system -- I'm not sure I'd go so far as to forbid them outright.
> 2) An open source project publishes a key by which the artifact can be
> verified as authentic. Most often I've seen this in projects from
> Apache, where the end user is asked to verify the artifact manually
> after download, and the hash is posted on a web page. AFAIK, the use
> case is to verify that the artifact was not swapped or tampered with
> by some third-party on the hosting servers.
This convention is common; it's not specific to Apache. It's susceptible
to the obvious man-in-the-middle attack, however, so you can't completely
> 3) Signed JARs, which we already know about.
> Given the increasing reliance I see in my own team and among my
> colleagues elsewhere on open source software, it seems that having a
> standard, fairly straightforward and at best automated way to handle
> case #2 would be valuable.
That case will be handled automatically. A module-file repository will
have a catalog which includes the hash of every published module file,
and the downloader will check that the hash of a newly-downloaded module
file matches the corresponding hash in the catalog.
More information about the jigsaw-dev