core3 event names

[Jean-Philippe Ouellet]

Hello,

There are some events with specific names after a colon, e.g.:
- device-pre-attach:block
- device-list-attached:pci
- property-set:netvm
etc.

and sometimes the same names show up both with and without colons, e.g.:
in core-admin/qubes/vm/__init__.py:
self.vm.fire_event('domain-feature-delete', feature=key)
self.vm.fire_event('domain-feature-set', feature=key, value=value,
self.vm.fire_event('domain-feature-set', feature=key, value=value)

in desktop-linux-common/qubesappmenusext/__init__.py:
@qubes.ext.handler('domain-feature-set:internal')

I think this specific with/without colons mismatch is a bug, but
perhaps the original intention was that two events would be fired, one
foo-bar:specific and one foo-bar, as a means of pre-filtering which
events you care about? I could see this being useful for e.g.
listening on generic property-setting for all properties, but idk.

Also, I wonder if perhaps event identifiers might be better as classes
instead of strings so that we can statically catch event name
mismatches at compile time instead of silently firing or listening for
a typo (or other oversight) which goes nowhere / never comes.

Regards,
Jean-Philippe

P.S.: more documentation for qubes-core-* would be awesome

[Wojtek Porczyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 13, 2017 at 09:19:59PM -0500, Jean-Philippe Ouellet wrote:
> Hello,
>
> There are some events with specific names after a colon, e.g.:
> - device-pre-attach:block
> - device-list-attached:pci
> - property-set:netvm
> etc.
>
> and sometimes the same names show up both with and without colons, e.g.:
> in core-admin/qubes/vm/__init__.py:
> self.vm.fire_event('domain-feature-delete', feature=key)
> self.vm.fire_event('domain-feature-set', feature=key, value=value,
> self.vm.fire_event('domain-feature-set', feature=key, value=value)
>
> in desktop-linux-common/qubesappmenusext/__init__.py:
> @qubes.ext.handler('domain-feature-set:internal')
>
> I think this specific with/without colons mismatch is a bug, but
> perhaps the original intention was that two events would be fired, one
> foo-bar:specific and one foo-bar, as a means of pre-filtering which
> events you care about? I could see this being useful for e.g.
> listening on generic property-setting for all properties, but idk.

If there is no explicit fire_*() with this name with colon (maybe calculated
as 'domain-feature-set:' + variable), this is a bug, and IIUC it will cause
the handler in qubesappmenuext (desktop-linux-common) not to fire.

It is a general convention that events with colon are intented as generic
classes with exact instance being named after color. This should happen at
least for devices (qubes/devices.py and qubes/ext/*), which are implemented
using extensions and communicating with events.

> Also, I wonder if perhaps event identifiers might be better as classes
> instead of strings so that we can statically catch event name
> mismatches at compile time instead of silently firing or listening for
> a typo (or other oversight) which goes nowhere / never comes.

Having this exact concern, I wrote this tool for static analysis:
https://github.com/QubesOS/qubes-core-admin/blob/master/contrib/check-events.
However it cannot be used with automatic tests, because there are some events
that no-one currently listens for and, more importantly, when I wrote this,
there were events that were fired in extensions and handled in core. I don't
know if that's still the case.

Also, the event identifiers sooner or later will have to be coerced to str,
because they are also forwarded over Admin API (see admin.Events,
https://www.qubes-os.org/doc/admin-api/). Also, I'd like to retain the
possibility to fire any event without constrain. But I see no reason not to
generate those with some predefined functions/classes/macros/whatever.

> P.S.: more documentation for qubes-core-* would be awesome

https://dev.qubes-os.org/projects/core-admin
https://dev.qubes-os.org/projects/core-admin-client

Sorry, but that's all we've got. It seems core-admin-client is currently
broken, but I don't know why.

In core-admin there are some events documented on some classes, but
1) they are not indexed AFAIK, because I don't know sphinx good enough, and
2) because they are just strings, anyone can fire any event they wish.

HTH.

- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaMoE+AAoJEL9r2TIQOiNREYcP/R/42hDpF6Are0gfn1FWjiVV
RMhoqumksg8DT4wJwU/B8jxY90c6OL7z/pe2V+6I3HY5yls3igAc8h0Vlihg7whk
jxs56EG6kpdM/eTorZwq1HGp7t3kjlqgBktVeIWiGaGxwwDqni5G+qfS+Cv9SvW9
LegOA0o/vXR8c7nX5uUydXXi/v4EDDyIpYEipGGA0ue9Ha6jBdOTpvoxkaAoqOor
8IesXkEccInv0GQFsz4DXMt+kNXauX87shpx+Lcdh5V4SsIw+E1jYYlUOKJyPPJr
naJLziyd4YsI22J6G7vAhSpuq2ZqGBV57F5pbLtNeH4zgpYGmSBTvHpyw4sJZ0DG
LtO89OwIwI7xH3ehMz/D0TNRJ1FTHXwUsZEsQyzXZ9caZ6iCPfkZy8M1R6gIRZ0Z
CVFU9kgXP4wwZv3rqdTAbua65oVnZR4MRvSiKPx67pEAMjRC7iXErSX1a/aTPmIl
3ULSnKQINp9ip4dK/EC3a8cxKhfSf42bugFaxCzZc3t2UA2vvCOEsIwGITasJRNg
XLf075OyRfDKxmGrClprr6pCD2cKe1u7tHIv0ev2C95Rn3rg+yzBH1QyhwsCQRMF
q4IhE6NaMINBZVZUodxxW153L56gwtvmm9xOIJ7ybt44B+zAjI5/n0HpEHyRSdYZ
V5CpdxdNAyAoIXgQVrvZ
=YKkJ
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Thu, Dec 14, 2017 at 8:48 AM, Wojtek Porczyk
<wo...@invisiblethingslab.com> wrote:
> On Wed, Dec 13, 2017 at 09:19:59PM -0500, Jean-Philippe Ouellet wrote:
>> Hello,
>>
>> There are some events with specific names after a colon, e.g.:
>> - device-pre-attach:block
>> - device-list-attached:pci
>> - property-set:netvm
>> etc.
>>
>> and sometimes the same names show up both with and without colons, e.g.:
>> in core-admin/qubes/vm/__init__.py:
>> self.vm.fire_event('domain-feature-delete', feature=key)
>> self.vm.fire_event('domain-feature-set', feature=key, value=value,
>> self.vm.fire_event('domain-feature-set', feature=key, value=value)
>>
>> in desktop-linux-common/qubesappmenusext/__init__.py:
>> @qubes.ext.handler('domain-feature-set:internal')
>>
>> I think this specific with/without colons mismatch is a bug, but
>> perhaps the original intention was that two events would be fired, one
>> foo-bar:specific and one foo-bar, as a means of pre-filtering which
>> events you care about? I could see this being useful for e.g.
>> listening on generic property-setting for all properties, but idk.
>
> If there is no explicit fire_*() with this name with colon (maybe calculated
> as 'domain-feature-set:' + variable), this is a bug, and IIUC it will cause
> the handler in qubesappmenuext (desktop-linux-common) not to fire.

Indeed. Patch here: https://github.com/QubesOS/qubes-desktop-linux-common/pull/7

I'm still not sure whether that's the right way to fix it though.
Perhaps the event firing (and tests) should be changed to match the
existing handler instead? Idk.

> It is a general convention that events with colon are intented as generic
> classes with exact instance being named after color. This should happen at
> least for devices (qubes/devices.py and qubes/ext/*), which are implemented
> using extensions and communicating with events.
>
>> Also, I wonder if perhaps event identifiers might be better as classes
>> instead of strings so that we can statically catch event name
>> mismatches at compile time instead of silently firing or listening for
>> a typo (or other oversight) which goes nowhere / never comes.
>
> Having this exact concern, I wrote this tool for static analysis:
> https://github.com/QubesOS/qubes-core-admin/blob/master/contrib/check-events.
> However it cannot be used with automatic tests, because there are some events
> that no-one currently listens for and, more importantly, when I wrote this,
> there were events that were fired in extensions and handled in core. I don't
> know if that's still the case.

Nice :)

> Also, the event identifiers sooner or later will have to be coerced to str,
> because they are also forwarded over Admin API (see admin.Events,
> https://www.qubes-os.org/doc/admin-api/). Also, I'd like to retain the
> possibility to fire any event without constrain. But I see no reason not to
> generate those with some predefined functions/classes/macros/whatever.

Makes sense.

>> P.S.: more documentation for qubes-core-* would be awesome
>
> https://dev.qubes-os.org/projects/core-admin
> https://dev.qubes-os.org/projects/core-admin-client
>
> Sorry, but that's all we've got. It seems core-admin-client is currently
> broken, but I don't know why.
>
> In core-admin there are some events documented on some classes, but
> 1) they are not indexed AFAIK, because I don't know sphinx good enough, and
> 2) because they are just strings, anyone can fire any event they wish.
>
> HTH.

Thanks,
Jean-Philippe

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think better fix it the other way around. Otherwise (almost?) every
event handler for domain-feature-set even would be cluttered with 'if
feature == ...'. In practice handlers are for some particular feature.
If someone want to listen for multiple events at once, it's possible to
register handler for '*' (but not 'domain-feature-set:*'). It is rare
case anyway.
BTW the same bug applies to tags (domain-tag-add/domain-tag-delete).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlo8U2QACgkQ24/THMrX
1yz9iggAloy1vHStEJUpkxvlTCxyLLDnJfWQ4kRTaqGLZszzN8CABTUm8gOQQPR8
8JAOb0ks7/YJgJ0lbCB9tqoE34cgUds8BTlcj9g0gZBwu2lykafUpSUJgEWiZcSH
rs957gkw7BjpquqeQs+rGX2GrDvIFv4rqYfr2RxRPoIvTKCOOsCBPH0tb2jrfXvB
VKr1IOvvfvmKOo7w4J5WdYF8nPOTBDeovUlkalCMWCTEnY7G0y89pCzgu6j8JcJ+
v42HJKcTHcK+DK3lMBmajkITqYGEzMTO6HGwIfW3phxJphAgrxTk4H2QxnYlkgMa
/TQm9yd7MFLo4l4DOtySrCN/kVwMCw==
=m9gC
-----END PGP SIGNATURE-----