[wpkg-users] [Bug 42] add a time parameter
bugzilla-daemon at bugzilla.wpkg.org
bugzilla-daemon at bugzilla.wpkg.org
Tue Jan 15 11:43:32 CET 2008
--- 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
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,
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
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
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
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.
More information about the wpkg-users