Stack trace names (was Re: [TLF] merge 'tables' into 'develop')

[Alex Harui <ah...@adobe.com>]

On 11/27/14, 6:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>No worries. The 4.14 release will have my name - or rather, my
>computer account name - all over any stack traces that a user might
>see. Better make sure there are as few as possible ;-)

On this topic, I recently saw in this document [1], the following:

"Must releases be built on hardware owned and controlled by the committer?

Strictly speaking, releases must be verified on hardware owned and
controlled by the committer.  That means hardware the committer has
physical possession and control of and exclusively full
administrative/superuser access to. That's because only such hardware is
qualified to hold a PGP private key, and the release should be verified on
the machine the private key lives on or on a machine as trusted as that.
Practically speaking, when a release consists of anything beyond an
archive (e.g., tarball or zip file) of a source control tag, the only
practical way to validate that archive is to build it locally; manually
inspecting generated files (especially binary files) is not feasible. So,
basically, "Yes".
Note: This answer refers to the process used to produce a release artifact
from a source control tag. It does not refer to testing that artifact for
technical quality."

I don’t think the SDK release is a simple tar ball of a tag because we
exclude several files, especially the mustella tests, but it made me
wonder what generated files are in the package, and how close we are to
having the release artifact produced by Jenkins.  Then the stack trace
would be the same from release to release and not contain any of our names.

The RM would have to download the artifacts from the CI server, validate
via MD5, then do some verification before PGP signing and posting the
artifacts on dist.a.o.

Thoughts?
-Alex

[1] http://www.apache.org/dev/release.html#owned-controlled-hardware

Re: Stack trace names (was Re: [TLF] merge 'tables' into 'develop')

[Erik de Bruin <er...@ixsoftware.nl>]

I think the 'flex-sdk_release' job runs the same ant targets that an
RM would, at least that is the way I set it up originally. That means
that the nightlies basically could qualify as an RC (with the added
signature, of course).

But to me it somehow feels "more in control" to walk through the
release steps myself (I've been practicing ;-)), then it would to
download some archives from Jenkins and signing them.

EdB



On Thu, Nov 27, 2014 at 4:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/27/14, 6:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>No worries. The 4.14 release will have my name - or rather, my
>>computer account name - all over any stack traces that a user might
>>see. Better make sure there are as few as possible ;-)
>
> On this topic, I recently saw in this document [1], the following:
>
> "Must releases be built on hardware owned and controlled by the committer?
>
> Strictly speaking, releases must be verified on hardware owned and
> controlled by the committer.  That means hardware the committer has
> physical possession and control of and exclusively full
> administrative/superuser access to. That's because only such hardware is
> qualified to hold a PGP private key, and the release should be verified on
> the machine the private key lives on or on a machine as trusted as that.
> Practically speaking, when a release consists of anything beyond an
> archive (e.g., tarball or zip file) of a source control tag, the only
> practical way to validate that archive is to build it locally; manually
> inspecting generated files (especially binary files) is not feasible. So,
> basically, "Yes".
> Note: This answer refers to the process used to produce a release artifact
> from a source control tag. It does not refer to testing that artifact for
> technical quality."
>
> I don’t think the SDK release is a simple tar ball of a tag because we
> exclude several files, especially the mustella tests, but it made me
> wonder what generated files are in the package, and how close we are to
> having the release artifact produced by Jenkins.  Then the stack trace
> would be the same from release to release and not contain any of our names.
>
> The RM would have to download the artifacts from the CI server, validate
> via MD5, then do some verification before PGP signing and posting the
> artifacts on dist.a.o.
>
> Thoughts?
> -Alex
>
> [1] http://www.apache.org/dev/release.html#owned-controlled-hardware
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl