Features: support certificates, low-integrity commands about hass.agent HOT 4 CLOSED

Hi @mitchcapper. Thanks, and thank you for taking the time to review! I'll first try to answer each point.

• Agreed, will change in the next version. About listening to all ips; I try to make using the app as straightforward as possible for the less tech-savvy as well. But I agree that it should be configurable, so I'll think about making something like a flyout during onboarding to specify which ips should listen, and optionally configure certificates. The configuration window has been redesigned in the next version, allowing more space per category for specific settings like these.
• I've built the notification code quite some time ago, but currently the websocket route does seem nice. I did think about switching, but I'm also looking into making the application a native app so there'd be even less to configure for the users. Perhaps I could implement a mdns server in the meantime, so users won't have to provide their ip.
• The initial reason for admin privileges is because it's required to bind the listening port. That could be done by running netsh http add urlacl in a seperate, elevated prompt. But the second reason is to provide full functionality when running custom commands. It is something that has been bugging me as well, and I'm thinking about creating a seperate service which runs the commands/sensor under user specified privileges. The benefit of using one single desktop application is that it has way less overhead, so it's easier for me to develop/maintain.
• Nice! Will do.

Then a bit more general:

I'm developing this besides a fulltime job, so I have to think about what parts I want developed and to what extent. But that's not an excuse to cut corners security wise, and like I said the admin privileges have been bugging me. Generally speaking, I think the application will be run on the same local network as Home Assistant, so no direct external vector. But as more people begin using this, the more relevant it becomes. I'll think about the best way to give users the option to select privileges, without making it too complex (for the user, but for me to maintain as well).

Thanks again for your time, if you have any other tips/notes/issues/etc now or in the future, please let me know! :)

from hass.agent.

I'm developing this besides a fulltime job, so I have to think about what parts I want developed and to what extent.

Completely get that, and much the same situation:) Feel like a jerk to just suggest things without a PR but while an awesome app was not the best solution for me.

In terms of keeping things simple while flexible I think you could keep your on boarding exactly as it is, and just add an advanced options section for some of these options. It can always be questionable to spend time rewriting what already works too, hopefully it just might further increase adoption.

The admin option for commands is certainly useful, I think if most users expect that even running as admin by default is fine as long as a user can choose to just run with normal rights otherwise. If a user ran the app on a laptop and then roamed with that laptop it may cross to other networks. If you wanted to be super advanced you could even offer to run in the windows sandbox instead if they have it installed:

var proc = new Process();
proc.StartInfo.FileName = "%SystemRoot%\Sysnative\WindowsSandbox.exe";
proc.StartInfo.Arguments = cmd;
proc.StartInfo.UseShellExecute = true;
proc.Start();

or if being really fancy you can also offer to launch commands as low integrity:
https://github.com/zeko868/cookie-management-tool/blob/99cc63519aca3465f45184e706bd1c2b6baf9042/IntegrityLevelManagement/DerivedMethod.cs
https://github.com/edetoc/samples/blob/18cdf198694a4398b9ac9c605fc14a6b39706f12/CSCreateLowIntegrityProcess/CSCreateLowIntegrityProcess/MainForm.cs

Anyway, unless there are users looking for such features it may not matter but I figured it might be worth mentioning.

from hass.agent.

Feel like a jerk to just suggest things without a PR

You shouldn't! I'm honestly glad you took the time to share your thoughts.

I've done some testing and I agree that admin privileges aren't required. Even getting the window title from an elevated application works fine. So I'll be removing it from the next version, and just use an elevated console to allow/remove port bindings. With that, I can also remove the scheduled task, so less overhead after all :)

The low integrity method looks nice, I'll add that as an option, thanks.

from hass.agent.

Just published a new release, and with that I think most of your points are covered.

Last released already dropped the elevation requirement, and stopped loading the rest server if notifications are disabled. And this one adds certificates for HA based on your code (also submitted a PR to HADotNet), and the option to launch commands as low integrity.

Only selecting which IP to listen to remains, I've added that to my 'nice to have' list. Think that when someone's concerned with that, they can easily modify the firewall rule to specify a subnet/source IP.

Thanks for your input, if you're ever bored in the future - feel free to do so again :)

from hass.agent.