Re: Maven 3.4.0 Release

[Robert Scholte]

Hi,

what is the status on this? Can we expect a release this year?

I think the open issues are:
is maven-resolver ready to replace aether?
AFAIK some dependency management changes have been reverted, are all  
others indeed bugfixes and safe to keep in this release?


Here are the current release notes:


Release Notes - Maven - Version 3.4.0

** Bug
* [MNG-4463] - Dependency management import should support version  
ranges.
* [MNG-5359] - Declared execution in PluginMgmt gets bound to  
lifecycle (regression)
* [MNG-5368] - UnsupportedOperationException thrown when version range  
is not correct in dependencyManagement definitions

* [MNG-5387] - Add ability to replace an artifact in mid-build
* [MNG-5527] - Dependency management import should support relocations.
* [MNG-5538] - mvn start script causes cygwin warning
* [MNG-5567] - Zip files are not included in classpaths at all
* [MNG-5629] - ClosedChannelException from  
DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using  
"&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces -  
missing quotes

* [MNG-5836] - logging config is overwritten by $M2_HOME/lib/ext/*.jar
* [MNG-5837] - Syntax error in bin/mvn on Solaris SPARC
* [MNG-5849] - maven can not be found when current directory is  
drive/root at least on windows 7 64bit
* [MNG-5852] - "mvn" script invokes /bin/sh but requires /bin/bash  
functions
* [MNG-5863] - default pom's release-profile should invoke source  
plugin with goal "jar-no-fork" instead of "jar"
* [MNG-5868] - Adding serval times the same artifact via  
MavenProjectHelper (attachArtifact) does not produce a failure
* [MNG-5935] - Optional true getting lost in managed dependencies when  
transitive

* [MNG-5939] - Problem doing release when sources are generate as well
* [MNG-5958] - java.lang.String cannot be cast to  
org.apache.maven.lifecycle.mapping.LifecyclePhase

* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn fails when the current directory has spaces in  
between

* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-5971] - Imported dependencies should be available to  
inheritance processing
* [MNG-5981] - Plexus lifecycle could be activated too late during  
overlapping parallel requests
* [MNG-5984] - Maven core extension resolution ignores repositories  
from activeByDefault profiles in settings.xml

* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6029] - Duplicate conditional and body in  
MetadataResolutionResult.java

* [MNG-6041] - Option -l does not disable colorized output
* [MNG-6043] - Colorization is disabled too late in batch mode
* [MNG-6053] - Unsafe System Properties copy in  
MavenRepositorySystemUtils, causing NPEs
* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order  
is changed
* [MNG-6079] - 3.4 regression: cannot override version of a  
dependencyManagement in a submodule any more

* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
* [MNG-6112] - Central repository in the 4.0.0 super POM should  
declare update policy 'never'.
* [MNG-6114] - Elements from the global settings should be ordered  
before elements from the user settings.

* [MNG-6117] - ${session.parallel} not correctly set
* [MNG-6127] - Fix plugin execution configuration interference

** Dependency upgrade
* [MNG-5967] - Dependency updates.
* [MNG-6110] - Upgrade Aether to Maven Resolver 1.2

** Improvement
* [MNG-4508] - No way to avoid adding artifactId to site urls
* [MNG-5457] - Show repository id when downloading or uploading  
from/to a remote repository
* [MNG-5579] - Unify error output/check logic from shell and batch  
scripts

* [MNG-5600] - Dependency management import should support exclusions.
* [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
* [MNG-5883] - Silence unnecessary legacy local repository warning
* [MNG-5889] - .mvn directory should be picked when using --file
* [MNG-5896] - Download dependency POMs in parallel
* [MNG-5904] - Remove the whole Ant Build
* [MNG-5931] - Fixing documentation
* [MNG-5934] - String handling issues identified by PMD
* [MNG-5940] - Change the maven-source-plugin jar goal into  
jar-no-fork in Maven Super POM
* [MNG-5946] - Fix links etc. in README.txt which is part of the  
delivery

* [MNG-5951] - add an option to avoid path addition to inherited URLs
* [MNG-5968] - Default plugin version updates.
* [MNG-5975] - Use Java 7's SimpleDateFormat in  
CLIReportingUtils#formatTimestamp
* [MNG-5977] - Improve output readability of our MavenTransferListener  
implementations
* [MNG-5992] - Git passwords are exposed as the Super POM still uses  
Maven Release Plugin 2.3.2
* [MNG-5993] - Confusing 

Re: Taking Security Seriously

[Alexander Kjäll]

Hi

The attack scenario that I'm trying to guard against is the following:

Stopping an attacker that manages to exploit the our nexus server from 
being able to run arbitrary code on all the build servers and developer 
machines in our organization.


best regards
Alexander Kjäll

On 06. des. 2016 13:25, Tibor Digana wrote:

What real problem is behind your question?
Are you running any tool which has a problem with signatures in Nexus or
the development process in your company has a problem?

The MD5 is not security nothing but verification of deployed artifact is
identical binary you have downloaded from Nexus, and however GnuPG *.asc is
the real signature of deployer and the KEYS can be found in Apache projects
if really necessary.

You should be always able to verify gpg signatures via (gpg --verify
your-artifact-file.sig your-artifact-file)  without adding (XXX) in POM.


On Mon, Dec 5, 2016 at 1:56 AM, John Patrick  wrote:


Hiya,

So currently checksum's are not generated by default... I've submitted
a ticket which switched the install plugin to generate them by
default.

Next step stop using md5 which most have considered dead for several
years, and checking apache
(https://www.apache.org/dev/release-signing.html) sha512 should be
being used.

So either;
1) add support so md5, sha1, sha256 and sha512 are all generated
2) plugin defines which is generated
3) plugin defines a list which are generated
4) settings.xml defines which is generated
5) settings.xml defines a list which are generated?

Thoughts???

Next;
Currently when downloading we have ignore, warn or error if checksum's
don't match. I propose adding a checksum min level options? i.e. allow
MD5 > SHA1, SHA256 > SHA512

So;
1) Default to MD5
2) Wait till all maven plugins deploy a sha512 to central
3) Switch default to SHA512

What are developers thoughts?
What staged steps should this be merged as?

I would like to start helping getting the core maven and all of it's
dependencies more secure so people can start trusting maven is secure
by default as I get the feeling isn't at the moment.

Cheers,
John

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Taking Security Seriously

[Tibor Digana]

What real problem is behind your question?
Are you running any tool which has a problem with signatures in Nexus or
the development process in your company has a problem?

The MD5 is not security nothing but verification of deployed artifact is
identical binary you have downloaded from Nexus, and however GnuPG *.asc is
the real signature of deployer and the KEYS can be found in Apache projects
if really necessary.

You should be always able to verify gpg signatures via (gpg --verify
your-artifact-file.sig your-artifact-file)  without adding (XXX) in POM.


On Mon, Dec 5, 2016 at 1:56 AM, John Patrick  wrote:

> Hiya,
>
> So currently checksum's are not generated by default... I've submitted
> a ticket which switched the install plugin to generate them by
> default.
>
> Next step stop using md5 which most have considered dead for several
> years, and checking apache
> (https://www.apache.org/dev/release-signing.html) sha512 should be
> being used.
>
> So either;
> 1) add support so md5, sha1, sha256 and sha512 are all generated
> 2) plugin defines which is generated
> 3) plugin defines a list which are generated
> 4) settings.xml defines which is generated
> 5) settings.xml defines a list which are generated?
>
> Thoughts???
>
> Next;
> Currently when downloading we have ignore, warn or error if checksum's
> don't match. I propose adding a checksum min level options? i.e. allow
> MD5 > SHA1, SHA256 > SHA512
>
> So;
> 1) Default to MD5
> 2) Wait till all maven plugins deploy a sha512 to central
> 3) Switch default to SHA512
>
> What are developers thoughts?
> What staged steps should this be merged as?
>
> I would like to start helping getting the core maven and all of it's
> dependencies more secure so people can start trusting maven is secure
> by default as I get the feeling isn't at the moment.
>
> Cheers,
> John
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Resources Plugin version 3.0.2

[Olivier Lamy]

+1

On 5 December 2016 at 23:20, Christian Schulte  wrote:

> Hi,
>
> We solved 3 issues:
>  projectId=12317827&version=12336059>
>
> There are still a couple of issues left in JIRA:
>  3D%20MRESOURCES%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%
> 20Reopened)%20ORDER%20BY%20key%20ASC>
>
> Staging repo:
> 
>  content/org/apache/maven/plugins/maven-resources-
> plugin/3.0.2/maven-resources-plugin-3.0.2-source-release.zip>
>
> Source release checksum(s):
> maven-resources-plugin-3.0.2-source-release.zip sha1:
> 4b77d70fce42dbdc6382f57dff5635abe9c55cb1
>
> Staging site:
> 
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Taking Security Seriously

[Alexander Kjäll]

This is a a good idea, and a hash it would serve roughly as good as 
specifying the key i think, it would maybe even be better since it's 
easier to generate a hash.


It might be wise to plan for the future, as what ever hash algorithm 
that is considered best practice today will be broken and useless at 
some point in the future.


maybe something like this:


junit
junit
4.12
XXX


And having the signed-by element be legal to specify 0-N times, so that 
it's possible to add multiple versions of it but not required.


I understand that .md5 files isn't used to verify that the downloaded 
artifact isn't controlled by an attacker, but at least I use the .asc 
files for that. Do you mean that they also have some other purpose?


best regards
Alexander Kjäll

On 05. des. 2016 23:10, Bernd Eckenfels wrote:

Having artifact checksums (hashes not signatures) in POM dependency 
declarations would be cool, but that is not what .md5 or .asc is used for.

Gruss
Bernd




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Resources Plugin version 3.0.2

[Anders Hammar]

+1

/Anders

On Mon, Dec 5, 2016 at 9:23 PM, Robert Scholte  wrote:

> +1
>
>
> On Mon, 05 Dec 2016 13:20:25 +0100, Christian Schulte 
> wrote:
>
> Hi,
>>
>> We solved 3 issues:
>> > ectId=12317827&version=12336059>
>>
>> There are still a couple of issues left in JIRA:
>> > 20MRESOURCES%20AND%20status%20in%20(Open%2C%20%22In%
>> 20Progress%22%2C%20Reopened)%20ORDER%20BY%20key%20ASC>
>>
>> Staging repo:
>> 
>> > maven-1311/content/org/apache/maven/plugins/maven-resources-
>> plugin/3.0.2/maven-resources-plugin-3.0.2-source-release.zip>
>>
>> Source release checksum(s):
>> maven-resources-plugin-3.0.2-source-release.zip sha1:
>> 4b77d70fce42dbdc6382f57dff5635abe9c55cb1
>>
>> Staging site:
>> > >
>>
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for at least 72 hours.
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>