openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Digital signing release for windows.
Date Thu, 25 Dec 2014 21:25:28 GMT
On 25 December 2014 at 20:17, Dennis E. Hamilton <>

>  -- in reply below --
> From: jan i []
> Sent: Thursday, December 25, 2014 10:13
> To:;
> Subject: Re: Digital signing release for windows.
> On Thursday, December 25, 2014, Dennis E. Hamilton <
> wrote:
> [ ... ]
> > <orcmid>
> >    The official key is not needed in order to confirm a successful
> signing.
> >    Demonstrating a successful signing with any verifiable key is good
> >    enough to establish that the end-to-end procedure works.  Then take
> the
> >    same originals back through the ASF signing process.
> which is infra offers test keys, but I was talking about making a release
> and that requires the official key.
> I have experimented enough (I started about 6month ago, and was part of the
> discussions in infra)
> <orcmid>
>    I don't understand what experimentation in Infra has to do with
>    AOO learning, as a project, how to do these things.

OK let me be very precise about the use of my "hats". As AOO Committer I
tested how AOO could implement digital signing, As INFRA committer I helped
ASF find a solution that would work for all projects.

I cannot tell you what it has to do with AOO learning, because I am not
sure what you mean. I documented my findings on this list.

>    I apologize for my ignorance in not being around whenever this was
>    discussed before.
>    How can we translate what you have confirmed by experimentation into
>    something the project can do here and that release managers can be
>    equipped to do as we move ahead?
Simply read the cook receipt I wrote on this thread (and other threads).
There are no magic to it, no change to the build system is needed unless we
want to automate it.

>    If that is available in previous materials that I have missed in
>    my absence, please point to where the information is.
See earlier mails on this list, with subject digital signing (ps. some of
the mails might also be on private).

If you want to know how ASF have implemented digital signing, you need to
search in Infra ML. Basically we can sign artifacts using a tomcat
script/program which we could call from inside our build system or use the
Web UI to manually sign the artifacts.

The build system is not easy to expand (I think everybody who have tried
will agree to that), I tried to change it based on the capstone output, but
failed. Then I realised that manually uploading the artifacts to the webUI,
signing them and then downloading them again was a lot faster.

> </orcmid>
> >
> >    A shortcut, which I am puzzling about is to not even do a new build
> but
> >    use the artifacts that are already in the Apache 4.1.1 distribution.
> >    (It does mean the cab may have to be opened, and I am not certain how
> >    that works for signing).  This has the advantage of preserving the
> >    provenance of the distribution, because apart from signing the
> artifacts
> >    are identical.
> with my knowledge this would be far more difficult,
> >
> >    It might be too difficult to interrupt the process to just use the
> > end-stage
> >    that puts together the (now-signed) cab contents and the installer
> > package.
> you dont interrupt the process, you simply start the build process in the
> right directory, this is a standard facility of our build system.
> <orcmid>
>    Then it is relatively easy to put together a signed distribution using
>    existing artifacts?
Yes very. The time/CPU killer is getting the artifacts build, not the
signing afterwards.

> </orcmid>
> >
> >    In that case, it might be good enough to experiment with on a single
> > language
> >    but not for a new binary release.  But if we are certain there is a
> > working
> >    process but new builds are needed, waiting for 4.1.1 seems like a good
> > idea.
> >    One can then verify the process using a developer build before going
> to
> > rc01.
> The release candidate should only be in a single language, but since we
> vote on binaries as well The vote should be on all languages we want to
> release.
> <orcmid>
>     I don't understand.  I thought the idea was to *not* do a new Apache
>     release, but reissue signed convenience binaries.
A patch is also a apache release, and since the checksums change it is
formally not the same.

"real" apache releases only have source code, so they would never use
digital signing. We do however provide binaries as the primary target for
end-users with checksums.

>     For that, the best provenance is binaries that have already been
>     through the release-process-like approval of the previous binaries.
>     Or are those not done in combination?

We cannot use the binaries for 4.1 unless someone can show how we easily
can "split" the installer and then "combine" it again. We need a build tree
so that our builder can run and generate a new installer.

The checksum for the new installer is different from the old installer, so
we cannot just "overwrite" version 4.1 we need a patch number.

jan i.

> </orcmid>
> >
> >    Also, I think it is still necessary to see what the problem was with
> > having
> >    a signed installer (actually, a setup self-extractor the way AOO does
> > it)
> >    that creates a setup directory of unsigned artifacts.  The Windows
> 8[.1]
> >    Problem seems odd.  If it doesn't complain when the 4.1.1 extraction
> is
> >    done with an unsigned installer, I can't quite get the problem.  It
> may
> > be
> >    that the way I do installs avoids that problem and that might be
> useful
> > to
> >    understand.  (I don't let the installer crap on my desktop, and I have
> > it
> >    use a share on a file server instead, and setup runs from there just
> > fine
> >    on 8.1 and Windows 10 Technical Preview.)
> it has been tried both by myself and mark from tomcat, for 8.1 we need the
> runtime objects signed, for older versions your idea works well.
> <orcmid>
>    Help me understand what is happening.  I understand that the full
> signing
>    is required for certification, and Rob also commented about some sort of
>    complaint.  Yet I have AOO 4.1.1 installed and operating without any
>    complaints on Windows 8.1 and on Window 10 Technology Preview.
Did it not complain when you installed it and first time you started
it....that at least happened for me.

Once you have installed it (and accepted an untrusted source) and run it
the first time, Windows registers that you have allowed it and does not
complain anymore.

>    I am having difficulty comprehending how having the extractor signed
>    and not having the setup files signed screws this up. Is there something
>    else in the install scenario also being changed?
That is because windows started in version 8.1 to check when it loaded
files and not only when setup runs. See above why it does not complain
anymore on your system.

>    PS: I am going to try this myself, but I am not ready to alter my
>    development configuration just yet.  I am almost there.
OK, I will be glad to help.

jan I.

> </orcmid>
> rgds
> jan i
> > </orcmid>
> >
> >
> >
> > Steps are simple:
> > 1) make a full build, pick all DLL, JAR and EXE from the object tree
> > 2) Sign them, or let me help with that
> > 3) Overwrite the object tree with the signed artifacts
> > 4) run build but on postprocess (generate new setup package)
> > 5) Sign the installer or let me help with that
> > 6) Upload and start vote
> > 7) Upload to dist and be happy.
> >
> > [ ... ]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > <javascript:;>
> > For additional commands, e-mail:
> > <javascript:;>
> >
> >
> --
> Sent from My iPad, sorry for any misspellings.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message