Re: Why gnome-shell disables the extensions when the screen is idle?

[Juan Simón <decedion gmail com>]

Gnome-shell has limitations (like all desktop environments) and these limitations can be covered with extensions which, among other things, causes this desktop environment is a good choice. But after 4 years it seems incredible that there isn't yet complete and updated documentation about the Gnome libraries available for _javascript_: Is really this page (https://wiki.gnome.org/Projects/GnomeShell/Extensions) the best documentation available?
This search shows nothing about extensions development: https://developer.gnome.org/search?q=extensions
The native tools to obtain such documentation doesn't even work:

$ g-ir-generate /usr/lib/gnome-shell/St-1.0.typelib > st.gir
$ g-ir-doc-tool --language gjs st.gir -o st                
st.gir: Incompatible version 1.0 (supported: 1.2)

I edit the generated .gir file and change to version 1.2 in this line: <repository version="1.0"> but:
$ g-ir-doc-tool --language gjs st.gir -o st                
Caught exception: <type 'exceptions.TypeError'> TypeError("'NoneType' object has no attribute '__getitem__'",)
> /usr/lib/gobject-introspection/giscanner/docwriter.py(826)field_is_writable()
-> if isinstance(resolved, ast.Compound) and node.type.ctype[-1] != '*':
.....

There isn't documentation and I can't generate it... :-(

--------------------

Regarding the disabling of the extensions when the session is idle. I don't find any logical reason for this. This complicates the programming of extensions and limits their functionality.

Regards.

2016-03-17 21:16 GMT+01:00 Jasper St. Pierre <jstpierre mecheye net>:

The main reason wasn't actually security -- an extension can simply
have a dummy disable() function if it wants. The main reason was that
a lot of the extensions simply weren't designed for the lock screen in
mind. The initial set of extensions that were uploaded were things
like a new Apps Menu, or a Bottom Panel, or a custom status icon and
top bar button.

These extensions didn't handle the case when the screen was locked,
and exposing the top bar button during that time would have been a
major information leak. It also seems like an easy thing to miss as an
extension author, so I didn't want to risk it.

It might be possible to extend the extension metadata format to
support a new "handlesLockScreen" key and not turn it off when that
happens.

On Thu, Mar 17, 2016 at 12:56 PM, Jay Strict <jay strict posteo de> wrote:
> On 17.03.2016 16:04, Emmanuele Bassi wrote:
>>> But the worst is that it was a futile effort because when the screen is
>>> idle, gnome-shell disables the extensions. Why?
>>
>> It's a security measure.
>
> Hmm, is that so?
>
>
>> Since an extension can do whatever it wants with the UI, it can also
>> read the user's credentials from the session unlock screen;
>> alternatively, it could take over the whole thing, and impersonate the
>> user.
>
> Since an extension can do whatever it wants with the UI, it can also
> simulate a fake session unlock screen and read the user's credentials
> from there;
> alternatively, it does not need to take over the user's session, because
> it already runs as the user's UID and can spawn new processes as the
> user with GLib.spawn_async().
>
>
> There may be sound arguments for disabling extensions on session lock,
> but I doubt that those reasons are security. But maybe I am missing a
> point here?
>
>
> Kind regards,
> Jay

> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-shell-list



--
  Jasper