Message-ID: <1716158317.625.1369177566022.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_624_119186703.1369177566021" ------=_Part_624_119186703.1369177566021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
As identified in Previous Repository Security Proposals by several authors, t= here is a need to improve the security of the Maven repository ecosystem. W= e have an opportunity to encourage users to consider security (and later ot= her aspects such as licensing) by default, which fits well with Maven's vie= w of development best practices.
There may be a need to reconsider how Maven determines the repositories = to use to make this more feasible. For example:
However, this is not in scope for the initial implementation.
The current work has been done on the matter:
The feature branch in Maven is:
Related JIRA issue(s): http://jira.codehaus.org/brows= e/MNG-2477
Maven will use the following keyrings:
$M2_HOME/conf/pubring.pgp, configured in the installation settings file)
$HOME/.m2/pubring.pgp, configured in the installation settings file)
The Maven installation will contain the keys of several well known indiv= iduals and repositories. Should a user not wish to accept this initial set = of keys, they can simply remove the installation key ring and manually inst= all keys they wish to trust. As described later, a trust store and automati= c retrieval from a key server is not used, but is a future consideration.= p>
The user's Maven directory will initially not include any keys, however = Maven will gradually add accepted keys there. There are two possible ways t= his can be done:
Maven will make no specific requirement on how keys are to be created. I= t is expected that many remote repositories will use a "role key"= for signing all artifacts in the repository for convenience reasons, and t= hat the key is adequately protected. However, some repositories may choose = to allow artifacts to be signed by individuals, in which case the Maven use= r will need to add the key of each individual release manager to their publ= ic key ring (this is likely to be the case for the ASF repo initially).
A plugin will be available from Maven that will aid in adding keys to th= e user's key ring(s).
Keys may be added via a KEYS file, or via a keyserver.
All keys that are retrieved will need to be confirmed first, displaying = the details including fingerprint.
Error messages in the artifact resolution will specifically direct the u= ser in how to use the given plugin to add a key once it is known to belong = to a project (providing the project's web site to show where to validate th= e fingerprint).
This will be present in the super POM using a checksum so that a key is = not required to use it, avoiding the problem of not having the key necessar= y to add the key needed to use the plugin.
Maven will retrieve signature files from the same location as the artifa= ct and other metadata. Note that, as above, the actual keys will not be ret= rieved from the mirror but must be added manually from the source or using = a keyserver.
Signature files can contain one or more signatures (either concatenated,= or a single ascii-armored message with multiple packets). The artifact is = accepted if any of the signatures are found to be valid.= p>
Initially, many of the artifacts in the repository will be unsigned. In = addition, we will continue to receive upload requests that will not (and sh= ould not) sign artifacts. POMs written to be used against Maven 2.0.x shoul= d behave as designed (ie, with modelVersion 4.0.0).
To accommodate this, we should add configuration to the repository defin= itions, for example:
Alternatively, a specfic checksum can be specified on the dependency (se= e below).
Measures should be put in place in the repository sync to ensure new art= ifacts all receive signatures.
There are two alternatives to implementing handling for unsigned artifac= ts.
We should split the central repository along artifacts that are validly = signed and those that are not:
http://repo1.maven.org/central/signed - default included repository with signed, valid artifacts
http://repo1.maven.org/central/unsigned<= /code> - repository with legacy unsigned artifacts that can be included by = users via their build or repository manager (with appropriate white listing= ) as desired
http://repo1.maven.org/maven2- rewrite rul= es onto the other repositories for backwards compatibility
This requires some work on the repository side and so has not been execu= ted yet. In the interim, signature checking is off by default (though in pr= ototyping it was able to be turned on using the technique below).
To balance backwards compatibility while still allowing a strong default= mode, old artifacts can be signed with a specific key issued by the Maven = PMC. This will not be included in the distribution by default, but can easi= ly be added by users that want to explicitly trust these artifacts en masse= . This key can also be used for unsigned uploads via JIRA.
This was used for evaluation during prototyping without impacting the re= pository itself. It is still an option, but carries the concern of giving a= false sense of security by signing artifacts that are not released by us a= nd have never been validated.
The Incubator will sign with key(s) that are not included in the Maven d= istribution by default but that can be easily added. Note that incubator re= leases must not be signed by an individual user since trusting that user fo= r other releases would circumvent this.
As shown above, by default the policy for snapshots is to not require or= check for a signature. It is possible to enable this if necessary.
While it is inconvenient, we should support specification of an exact ch= ecksum of the JAR to use. This could potentially be baked in to releases to= help prevent or at least identify reproducibility problems in the event of= a repository accident as well as malicious replacement. This would be spec= ified as such:
sha1would be the default algorithm.
Maven 2.0.x is able to handle the
requiredChecksum element =
in a dependency as specified as it is an empty element, but not the
ignaturePolicy element. Neither are handled when building a project =
under 2.0.x - this is acceptable at this point.
We will initially add the elements under the "4.0.0"
elVersion on trunk until it handles multiple model versions, where i=
t should be increased to "4.1.0".
On deployment, the
requiredChecksum element can be left int=
act, but the
signaturePolicy element should be removed and the=
modelVersion set to 4.0.0.
Without the use of a keyserver initially, we will rely on Maven upgrades= to revoke pre-distributed keys.
In addition, since old binaries continue to be used over time, once a ke= y is revoked they won't be usable. At this point a user would need to upgra= de, or use the known checksum or a specific exclusion for the dependency. C= are needs to be taken that there wasn't a specific reason for the revocatio= n that the artifact shouldn't be used.
The following are not needed initially, but could be considered for the = future.
By default, all keys in the user's keyring will be accepted. However, to= strengthen a requirement, a project may require that the key be a particul= ar one, or signed by a particular key. The key provided might be either an = email address or the key ID.
Also, in line with the other repository enhancements, the signature poli= cy (and other checksum and update policies) should also be available on the= dependency element.
Maven's repository system does not currently easily support locating the= original source repository of an artifact in a secure way. In the event th= at the above is not available, Maven will still fall back to retrieving the= signature from the repository specified, ignoring any requested mirrors.= p>
However, we should consider implementing improved repository location, i= n conjunction with the other work on imp= roving repository handling. One alternative may be to look into a Repository Switchboard. It may actually b= e desirable for users to declare all required repositories themselves, elim= inating the ability to retrieve them from the POM (particularly transitivel= y), or at least only using this as a suggestion. The user would then opt-in= to repositories, possibly mapping them via the repository manager instead.=
In any case, more direction towards the source repository should be bala= nced by the ability to Mirro= r Repositories conveniently and access them from Maven.
Initially, the user will be required to explicitly add keys to their key= ring that they accept. However, it could become more flexible by downloadin= g from keyservers and choosing to trust a certain key, and also participati= ng in a web of trust.
Maven should prompt when an artifact is downloaded with an untrusted key= , if it is in interactive mode. If it is accepted, then the key is added to= the user's key ring.
The key should be downloaded from a trusted keyserver (as specified in <= code>settings.xml above), not from the repository that the artifact = is being downloaded from.
The other settings driven keyrings are so that a user can participate in= a web of trust (eg, going to an ApacheCon keysigning) and reuse that to tr= ust certain keys.
In addition, this may be used to aid in the management of keys where ind= ividuals sign a release but whether it is used is managed by a single repos= itory key and the trust values associated with it.
Maven should support JARs using the Java security model without the need= for additional verification.
Enhancements should be made shortly after availability of this feature t= o ensure that all new artifacts accepted to the central repository are sign= ed. The unsigned repository can continue to be used for those that are not.=------=_Part_624_119186703.1369177566021--