unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* No digital signatures on windows installer or executables
@ 2023-09-29 21:18 Lee B
  2023-09-29 23:51 ` Corwin Brust
  0 siblings, 1 reply; 2+ messages in thread
From: Lee B @ 2023-09-29 21:18 UTC (permalink / raw)
  To: help-gnu-emacs

I'm a long time emacs user but it I may have to stop using it because the
installer and executables are not digitally signed (the way microsoft wants
them singed).  If I right click on  emacs-29.1_2-installer.exe and pull up
properties there are no digital signatures.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: No digital signatures on windows installer or executables
  2023-09-29 21:18 No digital signatures on windows installer or executables Lee B
@ 2023-09-29 23:51 ` Corwin Brust
  0 siblings, 0 replies; 2+ messages in thread
From: Corwin Brust @ 2023-09-29 23:51 UTC (permalink / raw)
  To: Lee B; +Cc: help-gnu-emacs

On Fri, Sep 29, 2023 at 4:18 PM Lee B <ballle98@gmail.com> wrote:
>
> I'm a long time emacs user but it I may have to stop using it because the
> installer and executables are not digitally signed (the way microsoft wants
> them singed).  If I right click on  emacs-29.1_2-installer.exe and pull up
> properties there are no digital signatures.
>

Hi Lee.

Have you considered building Emacs for yourself?  I believe
self-compiling is a route to avoid some nags Microsoft Windows
provides regarding binaries distributed without paying into their
sphere of influence.

In any case, considering that any number of other people may feel as
you do:  I've thought about purchasing a code signing certificate to
use for signing these binaries. If I did so, I'd likely feel obligated
to make some type of report about what this specifically ends up
costing me and publish that, and that's so that I can feel good about
dropping a "donate" link on it: without sharing the cost it's a
meaningful hunk of what I can afford for charitable giving.  Ignoring
how "extra" this all begins to feel, it immediately leads me to
realize I'd as soon have people donate to FSF as anything I might be
up to, which more or less has stopped me doing anything at all.

I suspect it goes fine without my saying why I assume the concept of
paying Microsoft regularly in order to distribute Emacs would be
touchy within a community powered by the labor of Free Software
believers.  I haven't assumed I'd be flatly refused: I think we'll get
a conversation.  My point here is that conversation would be necessary
before I'd be willing to publish any Microsoft Code Signed binaries to
GNUs FTP on behalf of Emacs.  On the other hand, I do assume the
prognosis for any proposal that has FSF (however indirectly) buying
Microsoft code signing certs would fall somewhere between "unlikely"
and "dead on arrival".  Sorry if more initiative on my part would have
saved you some time and effort.  Frankly, I haven't wanted to chair a
conversation on the wisdom of kissing Microsoft's ring vis-a-vis "is
this program trusted".  Given we can agree there's something
"important" and do-able, that conversation does need to be had, I've
been thinking in these terms:

Is it an ethical compromise to purchase Microsoft code signing certs
specifically for use signing Emacs binaries? If so, is it acceptable?
Does it make a difference if volunteers (me) are doing this at their
own expense?
What if I don't want to cover it any more?  Am I implicated "fired" if
there's someone else who will cover it?

It is worth noting that these certs are not at all faceless.  There's
a complex identity verification process which, in the case of EV certs
(more below) also requires an IRL organizational entity.

So, TL;DR for the above: I haven't brought this up (e.g. on
emacs-devel) but that needs to happen, given there's something here to
discuss.  (Maybe self-building solves this?)

But: having looked into this a little, let's pretend it's not
completely out of the question: "I can just buy a cert myself and
upload signed binaries on behalf of Emacs, wee!", thinks Corwin. (I
hate the nags too, especially when I see it on friends' computers).
While I hope you won't feel _obligated_ (only invited) to those
questions above, faced, finally with an non-theoretical person who
cares about this, I do have couple more, for you:

1. Can you give some background on why this is important?

Is it about avoiding nags, as I suggest above, that and more, or
something else entirely?


2. Would "normal" code signing vs "EV" signing make a difference for you?

In case you *aren't* familiar, the salient difference will be whether
binaries continue to appear signed even after the (version of) the key
used to sign them has expired (or been renewed; renewing won't
"unbreak" signatures for older binaries, while binaries signed with an
EV cert are "perpetually" signed, so long as the cert is maintained in
good standing), is my understanding from "Benefits of EV Code Signing
Certificates" section at
https://www.digicert.com/signing/code-signing-certificates

. Adding an optional timestamp means your signature
. lives on even after the original EV code signing
. certificate used to sign it has expired. Without a gpg
. timestamp, your signature expires when the
. certificate expires, requiring you to re-sign your code.


Thanks for raising this issue.
Corwin

(Did anyone else note the "GPG timestamp" in that quote?  This is us
buying back --access to someone's instance of-- our own tools --used
to make a file someone mails me on an USB drive, probably-- if we go
ahead and do it, right?)



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-09-29 23:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-29 21:18 No digital signatures on windows installer or executables Lee B
2023-09-29 23:51 ` Corwin Brust

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).