Re: windows installer

[phillip.lord@russet.org.uk (Phillip Lord)]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> This is no doubt a major-improvement.

Thank you!


> If I were to provide some feedback or comments, I would like to point
> out a few things.
>
> 1. Not commonly downloaded (yet)
>
> For the time being, the installer is reported as "not commonly
> downloaded", and gives a big red warning in MS EDGE. I'm guessing
> you'll get the same in Chrome, and also possibly Firefox:
>
> I've seen this before when developing and delivering other
> Windows-software, and this should only appear in a transitional phase.
>
> This will make the initial roll-out a little more painful, but it
>should basically resolve itself over time.
>
> I'm just mentioning this, so that if you get other comments on the
> same subject, I don't think you need to be overly worried about it.

Okay. For the snapshots, I will probably start adding a date to the file
name which will exacerbate this, but as you say it should go away when
Emacs-27 comes out.





> 2. Installer is not signed
>
> These days trying to distribute a unsigned installer on Windows is
> getting increasingly cumbersome. Especially for the end-users trying
> to run it.


Yeah, couldn't agree more. This has to be fixed.



> The solution is signing the installer. Signing an installer (and any
> EXE-file really) is fairly trivial and there are tools for this in the
> Windows SDK. (And make sure to use the time-stamp options too!)
>
> To do this of course, you will have to be in possession of a X509
> code-signing certificate. If GNU already has one of these, it should
> be easy to convert into whatever format Windows expects it to be in,
> and put into use.

A single GNU one would be the thing, I think.

> If this is deemed important enough to resolve, I think the first
> course of action will have to be finding an affordable option for
> buying and renewing code-signing certificates.
>
> Managing the security of this certificate is also important concern,
> but one we can dig deeper into at a later point.

One solution here would be to sign the exe's when I upload them; this
means that the signature would happen inside gnu.org. AFAICT, it's
possible to do the signature with mono based tools -- so gnu.org would
not need a windows box to achieve this. I guess they'd need to re-GPG
sign it also, as signtool signature would break the GPG one.

> Also setting up code-signing in a CI-environment (and especially for a
> FOSS-project) can be a bit of a pain. Is the Windows-installer built
> in a CI-environment? Should it be? If so, this may also something we
> will need to solve too, but again, that's definitely something for
> later.

Signing on upload would solve this also. But, no, the windows-installer,
like the rest of the windows binaries on a cheap media box in my living
room.



> 3. Installer defaults
>
> Once launched the installer seems to work as intended. I do however question some of the defaults provided.
>
> Install default directory has IMO at least 2 issues:
>
> * The default is to install to a folder on the desktop. This is highly unconventional.

Yeah, known issue "Currently, it installs to Desktop which is not right,
but was easy.".

It's quick and easy to see what is going on there.

>  I suggest we instead use the user's profile folder. From an initial
>  probe, this can be found in at least the following
>  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>  by concatenating HOMEDRIVE and HOMEPATH ).

I'll fix this.


>
> * The default install-directory includes the Emacs-version.
>
>  This means that if I create any mappings to this installed
>  Emacs-version, add it to the path, and I later want to upgrade Emacs
>  to a newer version... Will that be installed in a different place?
>  Will I have to re-register Emacs all over the registry and in all
>  open-with dialogs?

No idea.

I'm presuming most people will not add it to the path, but launch it
from the shortcut that the installation adds.



>  Not including the version-number will give us much less issues down
>  the line, especially for upgrades.

I think it will make it hard for the installer to notice downgrades,
though.

>
> * It should be noted that the Start-menu folder created for Emacs also
> contains the version number.
>
>  For the same reasons given above, I advice that we also remove the
>  version-number from this folder too. Again, it will make upgrades and
>  similar scenarios much more hygienic, with less "old stuff" we have
>  to clean up, in order to avoid stale links, or double
>  program-registrations for the same piece of software.

Would you be able to test the program-registrations for me? You should
be able to do this just by changing the directory name.

For the start menu, what about adding both "Emacs" and "Emacs-27"?


> Apart from that, I'm all positive about this initiative and the
> improvements it provides. This is just so much better.

Me too. I'm tired of seeing blank looks on the faces of people shown the
zip.

Phil