bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

This mode would just be the normal fundamental mode (or conf mode or
something), but it would add `display' properties on all password tokens
so that these wouldn't be immediately visible to passers-by while you're
editing the file.

And a command to toggle the visibility, I guess.

Hm...  perhaps a general minor mode that hides certain bits based on a
syntax of some sort?


In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-10-08 built on stories
Repository revision: 9b3ce6252115980802adaa562af575bcd73a2c55
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.9 (jessie)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Ted Zlatanov]

On Wed, 11 Oct 2017 13:45:53 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> This mode would just be the normal fundamental mode (or conf mode or
LI> something), but it would add `display' properties on all password tokens
LI> so that these wouldn't be immediately visible to passers-by while you're
LI> editing the file.

LI> And a command to toggle the visibility, I guess.

LI> Hm...  perhaps a general minor mode that hides certain bits based on a
LI> syntax of some sort?

One of my big annoyances with netrc format is that it's badly defined
(previously discussed on bug list). So I implemented JSON support in
auth-source. Thus we can now use something like
https://github.com/DamienCassou/json-navigator as the UI, if the default
JSON editing is not good enough (for me it is).

The token display is a great idea and IMO it should be a minor mode,
operating like prettify-symbols mode. Then it could be used in any major
mode that tags its secret data appropriately, not just netrc.

WDYT?
Ted

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The token display is a great idea and IMO it should be a minor mode,
> operating like prettify-symbols mode. Then it could be used in any major
> mode that tags its secret data appropriately, not just netrc.
>
> WDYT?

Yup; that would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> The token display is a great idea and IMO it should be a minor mode,
>> operating like prettify-symbols mode. Then it could be used in any major
>> mode that tags its secret data appropriately, not just netrc.
>>
>> WDYT?
>
> Yup; that would be nice.

I was going to start typing up this mode now, but I just can't seem to
find a good name for it.  `hide-passwords-mode' seems rather too on the
nose...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

I thought I'd take a what at this, but if I remember correctly, the
consensus on emacs-devel was that this mode should just call
prettify-symbols-mode.

But looking at that mode, it seems like it doesn't really work on
regexps, and doesn't allow translating to strings?  It just takes
literal strings and displays is as a char?

That doesn't work for .authinfo, since the stuff we want to hide is,
like, "\bbpassword [^ ]+" or something...

Does anybody remember whether this really was the conclusion, or whether
there's another framework for hiding stuff that should be used?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Does anybody remember whether this really was the conclusion, or whether
> there's another framework for hiding stuff that should be used?

Found it.  Ted asked and Stefan M answered.

So the solution is to extend reveal-mode with a `display' thing and then
use that.

> > Right. I tried to find a standard way to do the hiding part, especially
> > one that would work with `reveal-mode`, and failed. Would doing it with
> > `jit-lock-register` work with `reveal-mode` automatically?

> reveal-mode doesn't care which mechanism you use to add the `invisible`
> property, so doing it with jit-lock-register will neither help nor
> hinder the use of reveal-mode.

> The current constraint of reveal-mode is that it only works for text
> hidden using the `invisible' property, and only if that property is
> applied via an overlay.

> It might very well be too restrictive for your use case (e.g. you might
> prefer to hide the passwords by replacing them with ******* or something
> like that, which requires the use of a `display` rather than
> `invisible` property, and you might also prefer to use a text-property
> rather than an overlay), but my suggestion was to extend reveal-mode to
> be able to handle such cases.

> You can see in reveal-open-new-overlays what tests are applied before
> "opening" an overlay:

>                   (and inv
>                        ;; There's an `invisible' property.  Make sure it's
>                        ;; actually invisible, and ellipsized.
>                        (and (consp buffer-invisibility-spec)
>                             (cdr (assq inv buffer-invisibility-spec)))
>                        (or (setq open
>                                  (or (overlay-get ol 'reveal-toggle-invisible)
>                                      (and (symbolp inv)
>                                           (get inv 'reveal-toggle-invisible))
>                                      (overlay-get ol 'isearch-open-invisible-temporary)))
>                            (overlay-get ol 'isearch-open-invisible)
>                            (and (consp buffer-invisibility-spec)
>                                 (cdr (assq inv buffer-invisibility-spec))))
>                        (overlay-put ol 'reveal-invisible inv))

> It could test for the presence of the `display` property (and maybe
> check for the presence of a reveal-specific property like
> reveal-toggle-invisible above, so that it doesn't reveal any and all
> `display` properties but only those that were designed to be revealed).

>         Stefan


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So the solution is to extend reveal-mode with a `display' thing and then
> use that.

I have now done this, and hopefully I didn't break anything in older
modes that use `reveal-mode'.

I've made the new `authinfo-mode' just hide passwords when the file is
loaded -- if you type in a new "password foobar" in the file, then it's
not automatically hidden.  I guess one could use `jit-lock-register' or
something and hide new passwords, too, but ... it doesn't really seem
that vital.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28785: 27.0.50; Wishlist: There should be a mode for .netrc and .authinfo

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 21 Sep 2019 10:58:19 +0200
> 
> I thought I'd take a what at this, but if I remember correctly, the
> consensus on emacs-devel was that this mode should just call
> prettify-symbols-mode.

FWIW, I'd prefer we didn't proliferate prettify-symbols-mode more than
it is already, because I hope it will go away some time soon, to be
replaced by true ligature support.

> But looking at that mode, it seems like it doesn't really work on
> regexps, and doesn't allow translating to strings?  It just takes
> literal strings and displays is as a char?

Yes, it's pretty limited.  What's more, it uses infrastructure (static
character composition) that was a temporary hack way back, when
automatic composition was not yet available, and we should at some
point deprecate and remove it.

> Does anybody remember whether this really was the conclusion, or whether
> there's another framework for hiding stuff that should be used?

I suggest to only consider the second part of that ;-)

In general, you can hide stuff with display properties, and I'm unsure
what additional framework you'd need for that.

Thanks.