www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: Clarification on the release requirements
Date Wed, 29 Apr 2009 23:34:04 GMT
On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl <jvanzyl@sonatype.com> wrote:
>
> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>
>>>> Anything that (essentially) matches the contents of svn and can be
>>>> built to produce the other release artifacts is IMHO fine as a source
>>>> release.
>>>>
>>>
>>> I agree and this is generally standard practice by SCM teams. It's
>>> predicated on immutable tagging and the SCM being reliable. I can see why
>>> Roy wants it done from the source archive here because we've never setup
>>> CVS
>>> or SVN to follow SCM best practices and it's not uncommon for SVN to be
>>> out
>>> for unacceptable periods of time. So I can see where Roy's methodology
>>> came
>>> from. I've seen lots of diddled tags (though this is pretty much
>>> impossible
>>> with mvn -B release:prepare release:perform) and SVN has been unavailable
>>> more often then I would like to admit to the outside world.
>>
>> It's not only a problem of SVN not being available : there is no way
>> you can guarantee that SVN hasn't been compromized if you base your
>> build on a tag.
>
> I don't think this argument carries any weight because where did you get
> your source archive from? A tag most likely. So if you wake up in the
> morning and pull a tag to create a source archive and then release,  or
> alternatively do "mvn -B release:prepare release:perform" there's no
> difference. The freak chance a second after you prepare the SCM goes down is
> slim. If we wait a length of time between each step then yes it could
> happen.
>
>> OTOS, a source package can be signed, thus can't be
>> compromized without being detected.
>>
>
> That's not related to making the source archive and it's integrity if you do
> both operations in rapid succession.

I believe this is flawed though - 'rapid succession' is not a
guarantee of atomicity. When you can't rely on atomicity, then you
need verification in between, which is where the signed artifact comes
in.

-Nathan

>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
>  -- Jakob Burckhardt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message