maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Coast <nathan.co...@db.com>
Subject Re: how to make the SVN release process more robust
Date Mon, 05 Aug 2013 17:08:30 GMT
Classification: Public

Absolutely agree that people should not commit to tags, however we need to 
take a more defensive position to guarantee that there is no route for 
malicious code to "sneak" into the release process.  As release prepare 
and release perform are not atomic, we need a process which guarantees 
what is being built, is exactly the same as tagged code.



From:
Curtis Rueden <ctrueden@wisc.edu>
To:
Maven Users List <users@maven.apache.org>, 
Date:
05/08/2013 15:59
Subject:
Re: how to make the SVN release process more robust



Hi Nathan,

No one should ever be committing to an SVN tag that already exists. Unless
the team has malicious committers? Or very clueless ones? In which case 
you
have much bigger problems...

In other words: isn't this more of a social issue?

-Curtis
 On Aug 5, 2013 9:51 AM, "Nathan Coast" <nathan.coast@db.com> wrote:

> Classification: Public
>
> Hi all,
>
> As SVN tags are simply a convention overlayed on top of SVN directories,
> SVN tags are therefore mutable.  This opens the possibility that someone
> could inject code to a tag between the release:prepare and the
> release:perform phases.
>
> This would mean that the code checked out during release perform phase
> could be different from the code which was originally tagged.
>
> To close this potential loophole, I'm considering this solution:
> 1)  Modify the behaviour within
> org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand  to
> return the tag revision number via TagScmResult
> 2)  Write the result to release.properties
> 3)  Utilise the revision number within the checkout command (tag plus
> revision#)
>
> Does anyone have any alternate suggestion for how to solve this?
>
> Regards,
> Nathan
>
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If 
you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>






---

This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate
and regulatory disclosures.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message