You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Nathan Coast <na...@db.com> on 2013/08/05 16:51:14 UTC
how to make the SVN release process more robust
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
Re: how to make the SVN release process more robust
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Nathan,
> I'm not sure that will help our problem as tags remain mutable. The
> tag checked out for release perform could still be corrupted.
As I asked before: who is doing this "corruption"? If you have committers
capable of doing that, they could absolutely hose your repository in all
sorts of ways. It's a much bigger problem than just the
maven-release-plugin.
That's not to say your proposed changes wouldn't make maven-release-plugin
more robust -- it just seems like an unwinnable battle. Better to go
Baptiste's very sensible route of locking down the server on the
server-side.
-Curtis
P.S. SVN is certainly not unique in having mutable tags. Git's tags are
mutable too: just force push over top the old one. And any VCS having
immutable tags would be a real PITA, IMO.
On Mon, Aug 5, 2013 at 12:14 PM, Nathan Coast <na...@db.com> wrote:
> Classification: Public
>
> I'm not sure that will help our problem as tags remain mutable. The tag
> checked out for release perform could still be corrupted.
>
>
>
>
> From:
> Stephen Connolly <st...@gmail.com>
> To:
> Maven Users List <us...@maven.apache.org>,
> Date:
> 05/08/2013 18:00
> Subject:
> Re: how to make the SVN release process more robust
>
>
>
> The original behaviour was to tag the local working copy not the remote
> tree, so that you could release at any time without having to for e a
> "quiet" period on trunk.
>
> Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot
> recall
> which) made tagging from working copies for https based repositories
> difficult for users.
>
> Now that serf is the default transport, perhaps we can switch back to the
> old behaviour?
>
> On Monday, 5 August 2013, Baptiste MATHUS wrote:
>
> > Hi,
> >
> > Well, as this is actually something that the SCM itself allows, I would
> > consider just forbidding on my svn server.
> >
> > This might be an interesting evolution though to be able to enforce this
> at
> > the maven-release-plugin (though unlikely to happen often since the
> three
> > usual commits actually happen very close to each others).
> >
> > Cheers
> >
> >
> > 2013/8/5 Nathan Coast <nathan.coast@db.com <javascript:;>>
> >
> > > 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<javascript:
> ;>
> > > For additional commands, e-mail: users-help@maven.apache.org<
> javascript:;>
> > >
> > > --
> > > Baptiste <Batmat> MATHUS - http://batmat.net
> > > Sauvez un arbre,
> > > Mangez un castor ! nbsp;! <users-help@maven.apache.org <javascript:;>>
> >
>
>
> --
> Sent from my phone
>
>
>
>
>
>
> ---
>
> 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
>
>
Re: how to make the SVN release process more robust
Posted by Stephen Connolly <st...@gmail.com>.
typically you go
$ mvn release:prepare release:perform -B
So there is maybe a 1 second window when somebody can mutate the tag
between the create and the checkout...
Now if you are doing release:perform a while after the release:prepare (the
tag is created only as the second last operation at end of the prepare step
- the final being checking in the development of next version poms) then it
could be a concern...
But that will always be an issue.... because you could have the case where
the machine with the release.properties has a hard disk failure before you
can run release:perform and as a result you loose the revision detail.
TL;DR for every safeguard you put in place (that is not a rule enforced on
the Subversion server) we can find a scenario that can work around your
safeguard... the solution is a rule enforced by the Subversion server that
only permits creation and deletion of tags and no modification to the tags
themselves (you need delete if you ever want to respin a release... if you
don't want to respin [your name could be sebb or fred :-P ] then don't put
a rule that permits deleting borked tags.
On 5 August 2013 18:14, Nathan Coast <na...@db.com> wrote:
> Classification: Public
>
> I'm not sure that will help our problem as tags remain mutable. The tag
> checked out for release perform could still be corrupted.
>
>
>
>
> From:
> Stephen Connolly <st...@gmail.com>
> To:
> Maven Users List <us...@maven.apache.org>,
> Date:
> 05/08/2013 18:00
> Subject:
> Re: how to make the SVN release process more robust
>
>
>
> The original behaviour was to tag the local working copy not the remote
> tree, so that you could release at any time without having to for e a
> "quiet" period on trunk.
>
> Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot
> recall
> which) made tagging from working copies for https based repositories
> difficult for users.
>
> Now that serf is the default transport, perhaps we can switch back to the
> old behaviour?
>
> On Monday, 5 August 2013, Baptiste MATHUS wrote:
>
> > Hi,
> >
> > Well, as this is actually something that the SCM itself allows, I would
> > consider just forbidding on my svn server.
> >
> > This might be an interesting evolution though to be able to enforce this
> at
> > the maven-release-plugin (though unlikely to happen often since the
> three
> > usual commits actually happen very close to each others).
> >
> > Cheers
> >
> >
> > 2013/8/5 Nathan Coast <nathan.coast@db.com <javascript:;>>
> >
> > > 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<javascript:
> ;>
> > > For additional commands, e-mail: users-help@maven.apache.org<
> javascript:;>
> > >
> > > --
> > > Baptiste <Batmat> MATHUS - http://batmat.net
> > > Sauvez un arbre,
> > > Mangez un castor ! nbsp;! <users-help@maven.apache.org <javascript:;>>
> >
>
>
> --
> Sent from my phone
>
>
>
>
>
>
> ---
>
> 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
>
>
Re: how to make the SVN release process more robust
Posted by Nathan Coast <na...@db.com>.
Classification: Public
I'm not sure that will help our problem as tags remain mutable. The tag
checked out for release perform could still be corrupted.
From:
Stephen Connolly <st...@gmail.com>
To:
Maven Users List <us...@maven.apache.org>,
Date:
05/08/2013 18:00
Subject:
Re: how to make the SVN release process more robust
The original behaviour was to tag the local working copy not the remote
tree, so that you could release at any time without having to for e a
"quiet" period on trunk.
Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot
recall
which) made tagging from working copies for https based repositories
difficult for users.
Now that serf is the default transport, perhaps we can switch back to the
old behaviour?
On Monday, 5 August 2013, Baptiste MATHUS wrote:
> Hi,
>
> Well, as this is actually something that the SCM itself allows, I would
> consider just forbidding on my svn server.
>
> This might be an interesting evolution though to be able to enforce this
at
> the maven-release-plugin (though unlikely to happen often since the
three
> usual commits actually happen very close to each others).
>
> Cheers
>
>
> 2013/8/5 Nathan Coast <nathan.coast@db.com <javascript:;>>
>
> > 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<javascript:
;>
> > For additional commands, e-mail: users-help@maven.apache.org<
javascript:;>
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor ! nbsp;! <users-help@maven.apache.org <javascript:;>>
>
--
Sent from my phone
---
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
Re: how to make the SVN release process more robust
Posted by Stephen Connolly <st...@gmail.com>.
The original behaviour was to tag the local working copy not the remote
tree, so that you could release at any time without having to for e a
"quiet" period on trunk.
Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot recall
which) made tagging from working copies for https based repositories
difficult for users.
Now that serf is the default transport, perhaps we can switch back to the
old behaviour?
On Monday, 5 August 2013, Baptiste MATHUS wrote:
> Hi,
>
> Well, as this is actually something that the SCM itself allows, I would
> consider just forbidding on my svn server.
>
> This might be an interesting evolution though to be able to enforce this at
> the maven-release-plugin (though unlikely to happen often since the three
> usual commits actually happen very close to each others).
>
> Cheers
>
>
> 2013/8/5 Nathan Coast <nathan.coast@db.com <javascript:;>>
>
> > 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<javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor ! nbsp;! <users-help@maven.apache.org <javascript:;>>
>
--
Sent from my phone
Re: how to make the SVN release process more robust
Posted by Nathan Coast <na...@db.com>.
Classification: Public
We have considered that route, and unfortunately that option is not
possible for us.
From:
Baptiste MATHUS <ml...@batmat.net>
To:
Maven Users List <us...@maven.apache.org>,
Date:
05/08/2013 16:01
Subject:
Re: how to make the SVN release process more robust
Hi,
Well, as this is actually something that the SCM itself allows, I would
consider just forbidding on my svn server.
This might be an interesting evolution though to be able to enforce this
at
the maven-release-plugin (though unlikely to happen often since the three
usual commits actually happen very close to each others).
Cheers
2013/8/5 Nathan Coast <na...@db.com>
> 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
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <us...@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
Re: how to make the SVN release process more robust
Posted by Baptiste MATHUS <ml...@batmat.net>.
Hi,
Well, as this is actually something that the SCM itself allows, I would
consider just forbidding on my svn server.
This might be an interesting evolution though to be able to enforce this at
the maven-release-plugin (though unlikely to happen often since the three
usual commits actually happen very close to each others).
Cheers
2013/8/5 Nathan Coast <na...@db.com>
> 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
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <us...@maven.apache.org>
Re: how to make the SVN release process more robust
Posted by Nathan Coast <na...@db.com>.
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 <ct...@wisc.edu>
To:
Maven Users List <us...@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" <na...@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
Re: how to make the SVN release process more robust
Posted by Curtis Rueden <ct...@wisc.edu>.
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" <na...@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
>
>
Re: how to make the SVN release process more robust
Posted by Jochen Wiedmann <jo...@gmail.com>.
Isn't it possible to handle this in a technical manner` For example, a
rigger script that's invoked upon commit and checks whether the path
contains a "tags" directory?
On Mon, Aug 5, 2013 at 4:51 PM, Nathan Coast <na...@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
>
>
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero