Emacs in a Corporate Environment

Emacs in a Corporate Environment

[Yuan Cao]

Hello,

I was wondering if anyone here has experience getting Emacs accepted into
the approved software list in a corporate environment and is willing to
answer a few questions or point me in the right direction.

Thanks very much in advance!

Best Regards,

Yuan

Re: Emacs in a Corporate Environment

[Corwin Brust]

Hi Yuan,

On Wed, Apr 12, 2023 at 2:48 PM Yuan Cao <yuancao85@gmail.com> wrote:
>
> Hello,
>
> I was wondering if anyone here has experience getting Emacs accepted into
> the approved software list in a corporate environment and is willing to
> answer a few questions or point me in the right direction.

I've done this, multiple times even :)

I'd be more than happy to share my experiences (and interested to hear
about others'). You are contact me off-list, if you wish, but I
suggest we should keep the conversation on-list given it is all the
same to you.

Re: Emacs in a Corporate Environment

[John Yates]

Sometimes no effort is required...

Eight years ago, when I joined Mathworks, Emacs was already
the best supported editor for the simple reason that the head
of the tools group was a long time Emacs user and evangelist.

Eight years later, little has changed.

Re: Emacs in a Corporate Environment

[Yuan Cao]

> Hi Yuan,

> On Wed, Apr 12, 2023 at 2:48 PM Yuan Cao <yuancao85@gmail.com> wrote:
> >
> > Hello,
> >
> > I was wondering if anyone here has experience getting Emacs accepted into
> > the approved software list in a corporate environment and is willing to
> > answer a few questions or point me in the right direction.

> I've done this, multiple times even :)

> I'd be more than happy to share my experiences (and interested to hear
> about others'). You are contact me off-list, if you wish, but I
> suggest we should keep the conversation on-list given it is all the
> same to you.


On Wed, Apr 12, 2023 at 4:48 PM John Yates <john@yates-sheets.org> wrote:
>
> Sometimes no effort is required...
>
> Eight years ago, when I joined Mathworks, Emacs was already
> the best supported editor for the simple reason that the head
> of the tools group was a long time Emacs user and evangelist.
>
> Eight years later, little has changed.


Too true! Unfortunately, I messed up!

I requested Org Mode for Emacs since our version of Emacs appeared to
be a stripped-down version of an older Emacs version -- ELPA and MELPA
are blocked, and only a very few built-in packages showed up when I
queried `M-x package-list-packages`. Org Mode was not one of the
built-in packages that showed up -- although other similarly installed
packages, as we shall see later, did show up.

After completing the request, I started investigating the emacs
installation and found the `org` directory in the
`...\share\emacs\25.1\lisp` directory. When I tried to withdraw my
request, I got hit with a list of questions I needed to ask the
"vendor" to clarify for OrgMode and Emacs. I am not sure who I can
ask, and the questions feel odd for Emacs.

The inquiry is:
"[...] confirm whether any advanced algorithms, predictive analytics,
dynamic components, machine learning, or artificial intelligence are
used within this product, and whether any part of the input or output
process involves any of these techniques. Examples of non-traditional
modeling capabilities include but are not limited to: auto-complete or
suggested text functionalities; optical character recognition (OCR) or
other image recognition and processing; transcription, translation,
speech-to-text or text-to-speech; search engines; virtual assistants;
and other assistive technologies."

I guess I am a little new to this process, so I might be overreacting.
I just want to make sure that Emacs isn't taken away.

This is a little embarrassing, but I hope this can help someone else
avoid being in the same situation.

Best Regards,

Yuan

Re: Emacs in a Corporate Environment

[Corwin Brust]

On Wed, Apr 12, 2023 at 4:33 PM Yuan Cao <yuancao85@gmail.com> wrote:
>
> After completing the request, I started investigating the emacs
> installation and found the `org` directory in the
> `...\share\emacs\25.1\lisp` directory. When I tried to withdraw my
> request, I got hit with a list of questions I needed to ask the
> "vendor" to clarify for OrgMode and Emacs. I am not sure who I can
> ask, and the questions feel odd for Emacs.
>
> The inquiry is:
> "[...] confirm whether any advanced algorithms, predictive analytics,
> dynamic components, machine learning, or artificial intelligence are
> used within this product, and whether any part of the input or output
> process involves any of these techniques. Examples of non-traditional
> modeling capabilities include but are not limited to: auto-complete or
> suggested text functionalities; optical character recognition (OCR) or
> other image recognition and processing; transcription, translation,
> speech-to-text or text-to-speech; search engines; virtual assistants;
> and other assistive technologies."

It sounds like the main concerns here are in the general area of
"information leakage". It may be helpful to understand that this is
also a major concern for GNU (and an important area of focus for the
Free Software Society in terms of our guiding philosophies).

No part of Emacs (including org) comes set up to send information to
other systems beyond the host on which Emacs is running. Especially,
Emacs is NOT equipped to connect to/with "Software as a Service"
providers, to which GNU/FSF are categorically opposed.

Responding point-by-point to the mentioned capabilities:
- auto-complete provided with Emacs does not use resources external to
Emacs; it is limited to scanning the files/projects being editing,
their "CTAGS", etc.
- suggested text is possible to configure, using the same (local to
the machine running Emacs) functionality as for auto-complete
- NO optical character recognition or other image recognition included
- Image processing is limited to
   - displaying
   - scaling
   - rotating
   - cropping, and
   - playing multi-frame (animated) images
   - Emacs also provides image creation primitives; It is possible
(although a bit painful, perhaps) to use Emacs as a drawing tool
- NO text-to-speech is provided with Emacs
- NO search engines are integrated with Emacs
- Emacs does not have any virtual assistant (nothing AI/ML driven
whatsoever is integrated with Emacs)

>
> I guess I am a little new to this process, so I might be overreacting.
> I just want to make sure that Emacs isn't taken away.
>
> This is a little embarrassing, but I hope this can help someone else
> avoid being in the same situation.
>
> Best Regards,
>
> Yuan

Hopefully, others will answer and/or help corroborate (or refine) my
answers.  Don't be embarrassed.  It's embarrassing that

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-13, at 02:08, Corwin Brust <corwin@bru.st> wrote:

> It sounds like the main concerns here are in the general area of
> "information leakage". It may be helpful to understand that this is

Which is a /very/ valid concern.

> also a major concern for GNU (and an important area of focus for the
> Free Software Society in terms of our guiding philosophies).
>
> No part of Emacs (including org) comes set up to send information to
> other systems beyond the host on which Emacs is running. Especially,

Except, obviously, packages whose goal is specifically that (TRAMP).  Of
course, it is still safe in the sense that TRAMP does not "call home",
only to the server you explicitly ask it to call to.

> Emacs is NOT equipped to connect to/with "Software as a Service"
> providers, to which GNU/FSF are categorically opposed.
>
> Responding point-by-point to the mentioned capabilities:
> - auto-complete provided with Emacs does not use resources external to
> Emacs; it is limited to scanning the files/projects being editing,
> their "CTAGS", etc.
> - suggested text is possible to configure, using the same (local to
> the machine running Emacs) functionality as for auto-complete
> - NO optical character recognition or other image recognition included
> - Image processing is limited to
>    - displaying
>    - scaling
>    - rotating
>    - cropping, and
>    - playing multi-frame (animated) images
>    - Emacs also provides image creation primitives; It is possible
> (although a bit painful, perhaps) to use Emacs as a drawing tool

Ha, I'm doing it right now in some code I'm working on.  And I can agree
-- it is possible, and a bit painful indeed. ;-)

> - NO text-to-speech is provided with Emacs
> - NO search engines are integrated with Emacs

Let's slow down here -- doesn't eww try duckduckgo by default?

> - Emacs does not have any virtual assistant (nothing AI/ML driven
> whatsoever is integrated with Emacs)

Well, I would argue that Emacs /is/ one of the best "virtual assistants"
in existence.  Of course, this is 99.99% not what is meant by that
document.

>> I guess I am a little new to this process, so I might be overreacting.
>> I just want to make sure that Emacs isn't taken away.

Totally understood!  Not having Emacs at work would be /terrible/.

>> This is a little embarrassing, but I hope this can help someone else
>> avoid being in the same situation.
>>
>> Best Regards,
>>
>> Yuan
>
> Hopefully, others will answer and/or help corroborate (or refine) my
> answers.  Don't be embarrassed.  It's embarrassing that

I guess some internet beast swallowed the rest of your letter, but
I second the message that OP should /not/ be embarrassed.  Silly jokes
aside, the question is a valid one.  In fact, there is one area I am
a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
bit), let me ask this: if I edit remote files via TRAMP, can I be sure
not even partial copy of data from the server ends up on my local drive,
e.g. in /tmp?

Also, one area one should be probably /very/ careful are packages which
save "Emacs session" to disk.  If the "session" includes the kill ring,
it may happen (/especially/ if one uses TRAMP to edit remote .env files
and similar stuff) that some password ends up there, which could be
a /very/ serious leakage.

Also, this is obvious, but no guarantees can be made about /any/ package
on MELPA, EmacsWiki or elsewhere.  (Still I think Emacs -- and Vim, for
that matter -- are "safer", at least for some sane values of "safer",
than VSCode etc.)

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Michael Albinus]

Marcin Borkowski <mbork@mbork.pl> writes:

Hi Marcin,

>> Hopefully, others will answer and/or help corroborate (or refine) my
>> answers.  Don't be embarrassed.  It's embarrassing that
>
> I guess some internet beast swallowed the rest of your letter, but
> I second the message that OP should /not/ be embarrassed.  Silly jokes
> aside, the question is a valid one.  In fact, there is one area I am
> a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
> bit), let me ask this: if I edit remote files via TRAMP, can I be sure
> not even partial copy of data from the server ends up on my local drive,
> e.g. in /tmp?

You can be sure that a copy of your remote data end up in your local
drive in /tmp. Tramp is busy to clenaup after the operations, but there
is no guarantee that it will cover everything. And if somebody calls
`file-local-copy' of a remote file, this ends up in your /tmp by
intention of the caller.

> Also, one area one should be probably /very/ careful are packages which
> save "Emacs session" to disk.  If the "session" includes the kill ring,
> it may happen (/especially/ if one uses TRAMP to edit remote .env files
> and similar stuff) that some password ends up there, which could be
> a /very/ serious leakage.

I cannot speak about environment files, but Tramp is very careful about
passwords. It has delegated password handling completely to
auth-source.el, which manages all kind of passwords, locally or
remote. So passwords is not an exclusive Tramp problem.

> Best,

Best regards, Michael.

Re: Emacs in a Corporate Environment

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Corwin Brust <corwin@bru.st>,  Yuan Cao <yuancao85@gmail.com>,
>  help-gnu-emacs@gnu.org,  John Yates <john@yates-sheets.org>
> Date: Fri, 14 Apr 2023 16:36:37 +0200
> 
> > I guess some internet beast swallowed the rest of your letter, but
> > I second the message that OP should /not/ be embarrassed.  Silly jokes
> > aside, the question is a valid one.  In fact, there is one area I am
> > a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
> > bit), let me ask this: if I edit remote files via TRAMP, can I be sure
> > not even partial copy of data from the server ends up on my local drive,
> > e.g. in /tmp?
> 
> You can be sure that a copy of your remote data end up in your local
> drive in /tmp. Tramp is busy to clenaup after the operations, but there
> is no guarantee that it will cover everything. And if somebody calls
> `file-local-copy' of a remote file, this ends up in your /tmp by
> intention of the caller.

Actually, you don't even need file-local-copy in the picture.  Every
modern OS has a swap file, which is used as the "backing store" for
the VM allocations.  So once you have any text in memory, chances are
its copy will end up on disk, and these chances go up as time goes by
and the probability of the memory holding the text to be swapped out
increases.

The rule is: anything you have in memory can very well end up being
somewhere on your local disk.

Re: Emacs in a Corporate Environment

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> The rule is: anything you have in memory can very well end up being
> somewhere on your local disk.

Modern OSes have mechanisms for preventing pagination of a specified
chunk of memory.

The OS can also be configured to encrypt the pagefile. (Or, even better,
the whole disk.)

Re: Emacs in a Corporate Environment

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 14 Apr 2023 17:08:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The rule is: anything you have in memory can very well end up being
> > somewhere on your local disk.
> 
> Modern OSes have mechanisms for preventing pagination of a specified
> chunk of memory.
> 
> The OS can also be configured to encrypt the pagefile. (Or, even better,
> the whole disk.)

You should talk to your CISO and hear from him/her what they think
about these measures in terms of information security and leaks.

Re: Emacs in a Corporate Environment

[tomas]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Fri, Apr 14, 2023 at 05:52:36PM +0300, Eli Zaretskii wrote:

> Actually, you don't even need file-local-copy in the picture.  Every
> modern OS has a swap file [...]

Mine hasn't. I gave it enough RAM :-)

Anyway: my employers so far have decided that they can trust
my judgement wrt data security, thanks $DEITY.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-14, at 18:11, tomas@tuxteam.de wrote:

> On Fri, Apr 14, 2023 at 05:52:36PM +0300, Eli Zaretskii wrote:
>
>> Actually, you don't even need file-local-copy in the picture.  Every
>> modern OS has a swap file [...]
>
> Mine hasn't. I gave it enough RAM :-)
>
> Anyway: my employers so far have decided that they can trust
> my judgement wrt data security, thanks $DEITY.

That's of course a pleasant experience, but I still think this
discussion is worthwhile.

Also, I've seen e.g. reckless developers enamored by ChatGPT and
similar, LLM-based tools, happily providing company information to
them...

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Sat, Apr 15, 2023 at 08:12:55AM +0200, Marcin Borkowski wrote:
> 
> On 2023-04-14, at 18:11, tomas@tuxteam.de wrote:

[...]

> > Anyway: my employers so far have decided that they can trust
> > my judgement wrt data security, thanks $DEITY.
> 
> That's of course a pleasant experience, but I still think this
> discussion is worthwhile.

For sure, and I am glad for that. Still, it's a bit jarring to me
what people are willing to accept without complaints because it
comes from $EMPLOYER. Did it come from the state, they'd all be
yelling dictatorship (with a reason). Why does an employer get a
free pass on that?

I mean: sometimes you have no choice if you want to go buy bread,
but rationalising that behaviour goes too far for my taste.

> Also, I've seen e.g. reckless developers enamored by ChatGPT and
> similar, LLM-based tools, happily providing company information to
> them...

Yes: trust in your employees is an investment: as an employer you
have to put resources into education and into building a trust
relationship. But it pays off handsomely.

If, as an employer,  you insist into treating your employees as a
disposable resource, you'll get every data leak you deserve.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-15, at 09:31, tomas@tuxteam.de wrote:

> On Sat, Apr 15, 2023 at 08:12:55AM +0200, Marcin Borkowski wrote:
>>
>> On 2023-04-14, at 18:11, tomas@tuxteam.de wrote:
>
> [...]
>
>> > Anyway: my employers so far have decided that they can trust
>> > my judgement wrt data security, thanks $DEITY.
>>
>> That's of course a pleasant experience, but I still think this
>> discussion is worthwhile.
>
> For sure, and I am glad for that. Still, it's a bit jarring to me
> what people are willing to accept without complaints because it
> comes from $EMPLOYER. Did it come from the state, they'd all be
> yelling dictatorship (with a reason). Why does an employer get a
> free pass on that?

Good point.  I often think that slaves in antiquity, peasants in the
Middle Ages (which were much more civilized times than most people think
- in fact, it may be the case that the so-called "Middle Ages" were the
golden age of our civilization, and we have only declined since then, at
least in moral and political terms) and employees today are in a very
much similar position.  And quite possibly it was even better to be
a peasant 600 years ago than a corporate employee today.

> I mean: sometimes you have no choice if you want to go buy bread,
> but rationalising that behaviour goes too far for my taste.

You might be right, but I would be very cautious with judgements in
individual cases.  (But you know that already, of course.)

>> Also, I've seen e.g. reckless developers enamored by ChatGPT and
>> similar, LLM-based tools, happily providing company information to
>> them...
>
> Yes: trust in your employees is an investment: as an employer you
> have to put resources into education and into building a trust
> relationship. But it pays off handsomely.

Agreed.

> If, as an employer,  you insist into treating your employees as a
> disposable resource, you'll get every data leak you deserve.

Agreed, too.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-14, at 16:52, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: Corwin Brust <corwin@bru.st>,  Yuan Cao <yuancao85@gmail.com>,
>>  help-gnu-emacs@gnu.org,  John Yates <john@yates-sheets.org>
>> Date: Fri, 14 Apr 2023 16:36:37 +0200
>> 
>> > I guess some internet beast swallowed the rest of your letter, but
>> > I second the message that OP should /not/ be embarrassed.  Silly jokes
>> > aside, the question is a valid one.  In fact, there is one area I am
>> > a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
>> > bit), let me ask this: if I edit remote files via TRAMP, can I be sure
>> > not even partial copy of data from the server ends up on my local drive,
>> > e.g. in /tmp?
>> 
>> You can be sure that a copy of your remote data end up in your local
>> drive in /tmp. Tramp is busy to clenaup after the operations, but there
>> is no guarantee that it will cover everything. And if somebody calls
>> `file-local-copy' of a remote file, this ends up in your /tmp by
>> intention of the caller.
>
> Actually, you don't even need file-local-copy in the picture.  Every
> modern OS has a swap file, which is used as the "backing store" for
> the VM allocations.  So once you have any text in memory, chances are
> its copy will end up on disk, and these chances go up as time goes by
> and the probability of the memory holding the text to be swapped out
> increases.
>
> The rule is: anything you have in memory can very well end up being
> somewhere on your local disk.

Good point, though my new laptop (which I am in the process of
configuring now) has enough RAM not to use swap (which is good).

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: Michael Albinus <michael.albinus@gmx.de>, corwin@bru.st,
>  yuancao85@gmail.com, help-gnu-emacs@gnu.org, john@yates-sheets.org
> Date: Sat, 15 Apr 2023 08:11:37 +0200
> 
> > The rule is: anything you have in memory can very well end up being
> > somewhere on your local disk.
> 
> Good point, though my new laptop (which I am in the process of
> configuring now) has enough RAM not to use swap (which is good).

Don't rely on that.  The OS can create a paging file whenever it sees
fit, your configuration notwithstanding.  E.g., what do you think
happens when your laptop hibernates?

Re: Emacs in a Corporate Environment

[tomas]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sat, Apr 15, 2023 at 10:17:43AM +0300, Eli Zaretskii wrote:
> > From: Marcin Borkowski <mbork@mbork.pl>
> > Cc: Michael Albinus <michael.albinus@gmx.de>, corwin@bru.st,
> >  yuancao85@gmail.com, help-gnu-emacs@gnu.org, john@yates-sheets.org
> > Date: Sat, 15 Apr 2023 08:11:37 +0200
> > 
> > > The rule is: anything you have in memory can very well end up being
> > > somewhere on your local disk.
> > 
> > Good point, though my new laptop (which I am in the process of
> > configuring now) has enough RAM not to use swap (which is good).
> 
> Don't rely on that.  The OS can create a paging file whenever it sees
> fit, your configuration notwithstanding.  E.g., what do you think
> happens when your laptop hibernates?

My OS doesn't create "paging files". I told it not to. "Hibernation"
only happens to RAM (so it's actually a deep sleep).

Perhaps under Windows you, the user, have no say over all of this.
With a civilised OS you do :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs in a Corporate Environment

[Eli Zaretskii]

> Date: Sat, 15 Apr 2023 09:34:02 +0200
> From: <tomas@tuxteam.de>
> 
> > Don't rely on that.  The OS can create a paging file whenever it sees
> > fit, your configuration notwithstanding.  E.g., what do you think
> > happens when your laptop hibernates?
> 
> My OS doesn't create "paging files". I told it not to. "Hibernation"
> only happens to RAM (so it's actually a deep sleep).
> 
> Perhaps under Windows you, the user, have no say over all of this.
> With a civilised OS you do :-)

Famous last words.

Seriously: you should talk to your CISO, if you have one.  You _think_
you control everything on your "civilised" OS, but that's an illusion.
Unless you build your machines yourself, from the ground up, and also
code all the software that runs on it.

Re: Emacs in a Corporate Environment

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On Sat, Apr 15, 2023 at 10:59:02AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 15 Apr 2023 09:34:02 +0200
> > From: <tomas@tuxteam.de>
> > 
> > > Don't rely on that.  The OS can create a paging file whenever it sees
> > > fit, your configuration notwithstanding.  E.g., what do you think
> > > happens when your laptop hibernates?
> > 
> > My OS doesn't create "paging files". I told it not to. "Hibernation"
> > only happens to RAM (so it's actually a deep sleep).
> > 
> > Perhaps under Windows you, the user, have no say over all of this.
> > With a civilised OS you do :-)
> 
> Famous last words.
> 
> Seriously: you should talk to your CISO, if you have one.  You _think_
> you control everything on your "civilised" OS, but that's an illusion.
> Unless you build your machines yourself, from the ground up, and also
> code all the software that runs on it.

You just moved the goalposts. We had it about paging files (which in
my case would be a partition, but I disgress). I control that. I don't
control the IME, alas.

At my current employer we haven't a CISO, we are too small (or well,
I'm half of that, of sorts).

Cheers


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs in a Corporate Environment

[Eli Zaretskii]

> Date: Sat, 15 Apr 2023 10:21:08 +0200
> Cc: help-gnu-emacs@gnu.org
> From:  <tomas@tuxteam.de>
> 
> > Seriously: you should talk to your CISO, if you have one.  You _think_
> > you control everything on your "civilised" OS, but that's an illusion.
> > Unless you build your machines yourself, from the ground up, and also
> > code all the software that runs on it.
> 
> You just moved the goalposts. We had it about paging files (which in
> my case would be a partition, but I disgress). I control that. I don't
> control the IME, alas.

No, the original issue was about whether some stuff Emacs has in
memory could end up on your local disk somewhere.  Pagefiles are just
one such mechanism, but it isn't the only one.

Re: Emacs in a Corporate Environment

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 15 Apr 2023 10:21:08 +0200
>> Cc: help-gnu-emacs@gnu.org
>> From:  <tomas@tuxteam.de>
>> 
>> > Seriously: you should talk to your CISO, if you have one.  You _think_
>> > you control everything on your "civilised" OS, but that's an illusion.
>> > Unless you build your machines yourself, from the ground up, and also
>> > code all the software that runs on it.
>> 
>> You just moved the goalposts. We had it about paging files (which in
>> my case would be a partition, but I disgress). I control that. I don't
>> control the IME, alas.
>
> No, the original issue was about whether some stuff Emacs has in
> memory could end up on your local disk somewhere.  Pagefiles are just
> one such mechanism, but it isn't the only one.

I think you're all missing the most obvious snafu (which has actually
gotten me in trouble with our security folks): auto-save files.

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-15, at 13:16, Po Lu <luangruo@yahoo.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Sat, 15 Apr 2023 10:21:08 +0200
>>> Cc: help-gnu-emacs@gnu.org
>>> From:  <tomas@tuxteam.de>
>>> 
>>> > Seriously: you should talk to your CISO, if you have one.  You _think_
>>> > you control everything on your "civilised" OS, but that's an illusion.
>>> > Unless you build your machines yourself, from the ground up, and also
>>> > code all the software that runs on it.
>>> 
>>> You just moved the goalposts. We had it about paging files (which in
>>> my case would be a partition, but I disgress). I control that. I don't
>>> control the IME, alas.
>>
>> No, the original issue was about whether some stuff Emacs has in
>> memory could end up on your local disk somewhere.  Pagefiles are just
>> one such mechanism, but it isn't the only one.
>
> I think you're all missing the most obvious snafu (which has actually
> gotten me in trouble with our security folks): auto-save files.

Good point!  Is there a way to disable them wholesale on remote machines
(when using TRAMP)?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Ruijie Yu via Users list for the GNU Emacs text editor]

On Apr 15, 2023, at 20:06, Marcin Borkowski <mbork@mbork.pl> wrote:
> 
> 
>> On 2023-04-15, at 13:16, Po Lu <luangruo@yahoo.com> wrote:
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> Date: Sat, 15 Apr 2023 10:21:08 +0200
>>>> Cc: help-gnu-emacs@gnu.org
>>>> From:  <tomas@tuxteam.de>
>>>> 
>>>>> Seriously: you should talk to your CISO, if you have one.  You _think_
>>>>> you control everything on your "civilised" OS, but that's an illusion.
>>>>> Unless you build your machines yourself, from the ground up, and also
>>>>> code all the software that runs on it.
>>>> 
>>>> You just moved the goalposts. We had it about paging files (which in
>>>> my case would be a partition, but I disgress). I control that. I don't
>>>> control the IME, alas.
>>> 
>>> No, the original issue was about whether some stuff Emacs has in
>>> memory could end up on your local disk somewhere.  Pagefiles are just
>>> one such mechanism, but it isn't the only one.
>> 
>> I think you're all missing the most obvious snafu (which has actually
>> gotten me in trouble with our security folks): auto-save files.
> 
> Good point!  Is there a way to disable them wholesale on remote machines
> (when using TRAMP)?

I believe we have connection-local variables for that. 

> TIA,
> 
> -- 
> Marcin Borkowski
> http://mbork.pl
> 

Re: Emacs in a Corporate Environment

[tomas]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Sat, Apr 15, 2023 at 02:04:25PM +0200, Marcin Borkowski wrote:

[...]

> Good point!  Is there a way to disable them wholesale on remote machines
> (when using TRAMP)?

I'd put tramp-auto-save-directory on a tempfs. This way you get
autosave during your OS session (nice if the remote session goes
down) and the files are gone when you shut down your workstation.

Assuming that you  do that regularly, of course.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs in a Corporate Environment

[Michael Albinus]

Marcin Borkowski <mbork@mbork.pl> writes:

Hi Marcin,

>> I think you're all missing the most obvious snafu (which has actually
>> gotten me in trouble with our security folks): auto-save files.
>
> Good point!  Is there a way to disable them wholesale on remote machines
> (when using TRAMP)?

From the Tramp manual (master branch):

--8<---------------cut here---------------start------------->8---
   Set ‘auto-save-file-name-transforms’ to ‘nil’ to save auto-saved
files to the same directory as the original file.

   Alternatively, set the user option ‘tramp-auto-save-directory’ to
direct all auto saves to that location.

   If you want to suppress auto-saving of remote files at all, set user
option ‘remote-file-name-inhibit-auto-save’ to non-‘nil’.
--8<---------------cut here---------------end--------------->8---

See (info "(tramp) Auto-save File Lock and Backup")

> TIA,

Best regards, Michael.

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-14, at 16:36, Michael Albinus <michael.albinus@gmx.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> Hi Marcin,
>
>>> Hopefully, others will answer and/or help corroborate (or refine) my
>>> answers.  Don't be embarrassed.  It's embarrassing that
>>
>> I guess some internet beast swallowed the rest of your letter, but
>> I second the message that OP should /not/ be embarrassed.  Silly jokes
>> aside, the question is a valid one.  In fact, there is one area I am
>> a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
>> bit), let me ask this: if I edit remote files via TRAMP, can I be sure
>> not even partial copy of data from the server ends up on my local drive,
>> e.g. in /tmp?
>
> You can be sure that a copy of your remote data end up in your local
> drive in /tmp. Tramp is busy to clenaup after the operations, but there
> is no guarantee that it will cover everything. And if somebody calls
> `file-local-copy' of a remote file, this ends up in your /tmp by
> intention of the caller.

Thanks for the info.  This doesn't look very bad to me, as my `/tmp`
resides in RAM, but still -- good to know.  I might want to add cleaning
up `/tmp` to things I do when I leave work.

>> Also, one area one should be probably /very/ careful are packages which
>> save "Emacs session" to disk.  If the "session" includes the kill ring,
>> it may happen (/especially/ if one uses TRAMP to edit remote .env files
>> and similar stuff) that some password ends up there, which could be
>> a /very/ serious leakage.
>
> I cannot speak about environment files, but Tramp is very careful about
> passwords. It has delegated password handling completely to
> auth-source.el, which manages all kind of passwords, locally or
> remote. So passwords is not an exclusive Tramp problem.

Sounds good -- but again, I'm talking about e.g. killing and yanking
passwords.  I imagine this is less of a problem in "traditional" editors
using the concept of "clipboard" which can hold one item -- but Emacs
has the kill ring which has a long memory...

I sometimes use `browse-kill-ring` to clear it, and I don't use any
"session saving", but this is something that I think needs to be taken
into account.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Björn Bidar]

Michael Albinus <michael.albinus@gmx.de> writes:

> Hi Marcin,
>
>>> Hopefully, others will answer and/or help corroborate (or refine) my
>>> answers.  Don't be embarrassed.  It's embarrassing that
>>
>> I guess some internet beast swallowed the rest of your letter, but
>> I second the message that OP should /not/ be embarrassed.  Silly jokes
>> aside, the question is a valid one.  In fact, there is one area I am
>> a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
>> bit), let me ask this: if I edit remote files via TRAMP, can I be sure
>> not even partial copy of data from the server ends up on my local drive,
>> e.g. in /tmp?
>
> You can be sure that a copy of your remote data end up in your local
> drive in /tmp. Tramp is busy to clenaup after the operations, but there
> is no guarantee that it will cover everything. And if somebody calls
> `file-local-copy' of a remote file, this ends up in your /tmp by
> intention of the caller.

Not to hijack this list even more but Emacs should probably use various
directories other then /tmp under Unixes. Under those that use XDG
(Linux, BSD, Solaris) ${XDG_CACHE_HOME} or ${XDG_STATE_HOME} comes to
mind.
Another option is to use ${XDG_RUNTIME_DIR}.
All those are separate per user and the latter is likely deleted each
time (tmpfs).

Br,

Björn

Re: Emacs in a Corporate Environment

[Michael Albinus]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

Hi Björn,

>> You can be sure that a copy of your remote data end up in your local
>> drive in /tmp. Tramp is busy to clenaup after the operations, but there
>> is no guarantee that it will cover everything. And if somebody calls
>> `file-local-copy' of a remote file, this ends up in your /tmp by
>> intention of the caller.
>
> Not to hijack this list even more but Emacs should probably use various
> directories other then /tmp under Unixes. Under those that use XDG
> (Linux, BSD, Solaris) ${XDG_CACHE_HOME} or ${XDG_STATE_HOME} comes to
> mind.
> Another option is to use ${XDG_RUNTIME_DIR}.
> All those are separate per user and the latter is likely deleted each
> time (tmpfs).

Emacs has the user option temporary-file-directory. It is initialized
using the environment variable $TMPDIR (or $TMP or $TEMP). If that
doesn't exist, "/tmp/" is used.

Prior starting Emacs, $TMPDIR could be set to "${XDG_CACHE_HOME}/emacs/"
(provided, subdirectory "emacs" is created). Alternatively, you could
set this user option in your init file.

Whether Emacs shall support this setting by default, including the
subdir creation, is a different question. Perhaps we shall do this as
opt-in, based on a user variable.

Similarly, you (we) could set small-temporary-file-directory to
"${XDG_RUNTIME_DIR}/emacs/".

> Br,
>
> Björn

Best regards, Michael.

Re: Emacs in a Corporate Environment

[Marcin Borkowski]

On 2023-04-12, at 23:33, Yuan Cao <yuancao85@gmail.com> wrote:

> The inquiry is:
> "[...] artificial intelligence [...]

Do nested `if's count?

I can see myself out now.

-- 
Marcin Borkowski
http://mbork.pl

Re: Emacs in a Corporate Environment

[Yuan Cao]

Freeze! What are you doing with that rule-based AI you have in your hand?

Best Regards,

Yuan

On Thu, Apr 13, 2023 at 10:23 AM Marcin Borkowski <mbork@mbork.pl> wrote:

>
> On 2023-04-12, at 23:33, Yuan Cao <yuancao85@gmail.com> wrote:
>
> > The inquiry is:
> > "[...] artificial intelligence [...]
>
> Do nested `if's count?
>
> I can see myself out now.
>
> --
> Marcin Borkowski
> http://mbork.pl
>

Re: Emacs in a Corporate Environment

[Jean Louis]

* Yuan Cao <yuancao85@gmail.com> [2023-04-12 22:50]:
> Hello,
> 
> I was wondering if anyone here has experience getting Emacs accepted into
> the approved software list in a corporate environment and is willing to
> answer a few questions or point me in the right direction.

"approved software list" is heaven thanks decided by myself in my
corporate environment.

We are using Emacs as ERP daily, projected budgets, accounting,
project planning. So I am building RCD Notes for GNU Emacs is Dynamic
Knowledge Repository designed as envisioned by Doug Engelbart.

RCD Notes for GNU Emacs is Dynamic Knowledge Repository designed as
envisioned by Doug Engelbart. Backed up by PostgreSQL relational
database, RCD Notes provides features such as people management also
known as CRM or Customer Relationship Management, ERP or Enterprise
Resource Planning, WRS or Website Revision System and Hyperscope
Dynamic Knowledge Repository. It uses any kind of Emacs major modes
and any kind of lightweight markup languages for editing and writing
of any of elementary objects.

Emacs has a programming language built-in, and by using Stallman's
principles that "any kind of text is editable", then it applies to
editing relational databases. Great.

We manage many people, resources, finances and multiple projects
through Emacs as interface.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/