[wpkg-users] [Bug 42] add a time parameter

Tue Jan 15 11:43:32 CET 2008

http://bugzilla.wpkg.org/show_bug.cgi?id=42

--- Comment #13 from Tomasz Chmielewski <mangoo at wpkg.org>  2008-01-15 11:43:26 ---
> I hope you're not really thinking about WPKG client to store the exit code
> within the registry and WPKG.js is checking frequently if it is available
> (polling). I even don't want to think about it since I am too far away from the
> toilet...

Yes, yes, let's use the registry for storing all temporary variables we use!
(did you barf already?) :)

> Alternative proposal:
> There might be a possibility to listen on a TCP port so WPKG could use a simple
> transfer protocol (probably HTTP-based).

You really never saw these cool firewalls warning the user "Program XYZ is
attempting to connect to/from 127.0.0.1. This may be an attack attempt!
[Block/Allow]"? It's a responsibility of an admin to set up a firewall, but I
can imagine these posts to the mailing list.

Of course, WPKG Client could listen, but JScript/wpkg.js perhaps not. Again,
we're polling.

Also, TCP/IP based communication can mean a potential security risk - just
about any unprivileged user could connect to a local port (unless we don't
listen on a port after logon delay is over, or make some per-user, per-program
firewalling).

Unless I'm mistaken of course.

> Currently the main need seems to be to display more information on the
> pre-login banner so the user is informed that the machine is doing something
> (and what). This could be done by simple STDOUT/STDIN communication and
> currently we just need one-way communication. If in the future we will
> implement TCP/IP based communication it might be very easy to upgrade (while
> even keeping backwards compatibility).

True, right now, only one-way communication is needed.
Anyway, I'd call displaying information on the banner an eye-candy rather than
a really useful feature (although, it could have some use for really long
installations: preventing users from pressing "reboot" button).

> PS: I probably did not fully understand your example. If WPKG client is running
> as a service of course it's not allowed to interact with the desktop (unless
> the service allows so, which is not recommended). Of course in such case also
> wpkg.js and its childs (insatllers) cannot display anything. In that case even
> sending the command to WPKG client will not help since WPKG client also does
> not have the rights to show the GUI.

Right now, it indeed works like that: WPKG Client either displays on a real
display or not. However, as we're more flexible with WPKG Client, we could
choose to start some commands on this "hidden" desktop (like cscript wpkg.js)
and some commands on a real desktop (wpkg.js told us to start a given command
on a real desktop).

> If WPKG client is allowed to interact with
> the desktop then wpkg.js will be allowed as well - so no need to transfer the
> command.

No. You just described the mode when we enable "WPKG user interface" ("Show"
checked). Then, all started commands are being shown. JScript has no way of
starting chosen GUI programs in a non-interactive desktop.

When wpkg.js is started in a non-interactive desktop it also can't start chosen
commands in an interactive desktop.

Perhaps with some (start_on_real_GUI.exe) wrapper, though? We run with
administrative privileges, so at least technically it should be possible).

> Transferring the command is again a one-way communication from wpkg.js
> to WPKG client (which can be done using STDOUT). What remains is returning the
> status code which is not really needed 

Hmm? Exit code is needed, as this is the way we know if the installation was
successful, or if reboot is needed.

> as of the fact that executing the
> command by WPKG client does not change anything on the process/child rights of
> desktop interaction.

I didn't understand this one.

> Probably there is a reason but I can't think about an example yet. A "cancel"
> or "stop" button on the GUI also does not justify bidirectional communication
> since stopping a child can e done using signals, you just kill the sub-process.

I'm not sure if we're talking about the same context, but a "cancel" or "stop"
button in the GUI can be used by an unprivileged user, signals can not (to stop
our installers). And it's the primary reason why WPKG Client starts commands in
a non-interactive desktop.

> WPKG currently just uses static information from XML files as an input. So
> there is no run-time value read from the system after initialization. So
> currently I don't see any need to push data to WPKG at any time when it is
> running.

Again, what was the exit code?

But anyway, what we're talking about is more theory than a real need. So far
there were only few reports of installers failing when not started in a real
GUI, and I think most of them (if not all) were solved somehow.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.