Off topic, but I tried to go on IRC.
* Connected. Now logging in...
* *** Looking up your hostname...
* *** Checking Ident
* *** Your forward and reverse DNS do not match, ignoring hostname.
* *** No Ident response
* Closing Link: 195.154.243.53 (No more connections permitted from your host)
* Disconnected (Remote host closed socket).Same if I change identity. Should I open a topic in support?
[quote=“troubadour, post:81, topic:246”]Off topic, but I tried to go on IRC.
* Connected. Now logging in...
* *** Looking up your hostname...
* *** Checking Ident
* *** Your forward and reverse DNS do not match, ignoring hostname.
* *** No Ident response
* Closing Link: 195.154.243.53 (No more connections permitted from your host)
* Disconnected (Remote host closed socket).Same if I change identity. Should I open a topic in support?[/quote]
It’s a non-Whonix related issue with oftc. Seems they are banning the whole Tor network at times. All we can do in meanwhile is switching to another irc network.
Your open-link-confirmation branch still contains extraneous text changes. Please “git diff origin/master” and remove the extraneous parts.
Merged your msgcollector changes.
/usr/lib/msgcollector/error_handler by the way provides a function that gets sourced by whonixcheck and timesync.
Your open-link-confirmation branch still contains extraneous text changes. Please "git diff origin/master" and remove the extraneous parts.
Pushed a modified open-link-confirmation without the modifications made tot he text.
There were still some extra changes in open-link-confirmation, but nevermind, I simply fixed them after merging.
Pushed some minor packaging fixes to generic-gui-message.
As long as open-link-confirmation was using zenity, we were using zenity with --no-markup for security reasons, because cmd args are untrusted input.
At the moment we’re forwarding that untrusted input (could contain html tags) to generic_gui_message. I think we must run the cmd args though striphtml before we can safely forward them to generic_gui_message. But since striphtml is part of msgcollector, open-link-confirmation would have to depend on msgcollector. Not ideal. Should we go that route?
Perhaps striphtml would be better off in an extra package, but which one? Too many packages also isn’t good for inclusion into distributions. Code duplication they also do not like.
I am having in mind inclusion of open-link-confirmation into other distributions. But I guess that is rather unlikely anyway. So we could go with the less ideal solution of letting open-link-confirmation depend on msgcollector. What do you think?
A (perhaps) lesser-known but useful feature in bash.
We can call generic_gui_message that way:
if [ ! "$open_in_tool_exit_code" = "0" ]; then
python -c 'import sys
from PyQt4 import QtGui, QtCore
class Notice(QtGui.QMessageBox):
def __init__(self):
super(Notice, self).__init__()
self.initUI()
def initUI(self):
itype = "error"
title = "ERROR"
message = "ERROR: $open_in_tool_bin does not exist! Please report this bug"
question = ""
button = "ok"
if itype == "information":
self.setIcon(QtGui.QMessageBox.Question)
elif itype == "warning":
self.setIcon(QtGui.QMessageBox.Warning)
elif itype == "error":
self.setIcon(QtGui.QMessageBox.Critical)
self.setWindowTitle(title)
self.setText(message)
self.setInformativeText(question)
if button == "yesno":
self.setStandardButtons(QtGui.QMessageBox.Yes | QtGui.QMessageBox.No)
elif button == "ok":
self.setStandardButtons(QtGui.QMessageBox.Ok)
self.setTextFormat(QtCore.Qt.RichText)
self.exec_()
result = self.result()
if button == "yesno":
print result
sys.exit()
def main():
app = QtGui.QApplication(sys.argv)
ex = Notice()
sys.exit(app.exec_())
if __name__ == "__main__":
main()'
exit 1
fiTo redirect python stdout in ‘answer’:
if [ "$ask_for_confirmation" = "1" ]; then
answer="$(cat << EOF | python -
import sys
from PyQt4 import QtGui, QtCore
class Notice(QtGui.QMessageBox):
def __init__(self):
super(Notice, self).__init__()
self.initUI()
def initUI(self):
itype = "warning"
title = "Link Open Confirmation"
message = """<p>The following $type will be opened in $open_in_tool_bin_name.</p>
<p>Be careful. If $open_in_tool_bin_name is already running as your activities might get linked.</p>"""
question = "Continue?"
button = "yesno"
if itype == "information":
self.setIcon(QtGui.QMessageBox.Question)
elif itype == "warning":
self.setIcon(QtGui.QMessageBox.Warning)
elif itype == "error":
self.setIcon(QtGui.QMessageBox.Critical)
self.setWindowTitle(title)
self.setText(message)
self.setInformativeText(question)
if button == "yesno":
self.setStandardButtons(QtGui.QMessageBox.Yes | QtGui.QMessageBox.No)
elif button == "ok":
self.setStandardButtons(QtGui.QMessageBox.Ok)
self.setTextFormat(QtCore.Qt.RichText)
self.exec_()
result = self.result()
if button == "yesno":
print result
sys.exit()
def main():
app = QtGui.QApplication(sys.argv)
ex = Notice()
sys.exit(app.exec_())
if __name__ == "__main__":
main()
EOF
)"
fiOf course, it does not make sense to call the script that way in open-link-confirmation, but it is nice to know that one can write in line python in a bash script. That might save a a few lines of scripting in some cases, and it gives some extra power to bash.
Off-topic note. Feel free to rename generic_gui_message, or anything I push/publish, at your liking. It’s not written in stone.
I’ll keep that in mind. 
dispatch_x currently has only a minimize and close button. Could you add the maximize button as well please? (whonixcheck had an error at the very end. The window became scrollable. But if I was a user, I would wish to maximize the window to make a screenshot with all the text.)
A whonixcheck message is not correctly shown. Test script:
(Need to adjust path to dispatch_x.)
#!/bin/bash
set -x
msg="<p>Tor Bootstrap Result:
<br></br>Tor's Control Port could not be reached. (Code: "$tor_bootstrap_percent")
<br></br>(tor_bootstrap_timeout_type: $tor_bootstrap_timeout_type)
<br></br>(tor_bootstrap_status: $tor_bootstrap_status)
<br></br>(check_socks_port_open_test: $check_socks_port_open_test)
<br></br>Please report this Whonix bug!</p>"
./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x "error" "test title" "$msg" "1" ""Any idea?
A whonixcheck message is not correctly shown. Test script:
“not corretly shown”, that is wrong format, missing part?
In ./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x “error” “test title” “$msg” “1” “”, you give six arguments when five are expected, but it should not affect the result.
By the way, in msgdispatcher error_handler, I have left six arguments. That’s a remain from some tests. I’ll correct it, or may be you can do in the Whonix repository, just removinf the last “”. When I modify msgcollector next time, I’ll have to fetch and merge anyhow.
No more text after.
(tor_bootstrap_timeout_type: $tor_bootstrap_timeout_type)Only quarter of next line is visible.
./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x "error" "test title" "$msg" "1" ""It’s just 5 arguments.
1 “error”
2 “test title”
3 “$msg”
4 “1”
5 “”
It was 4 arguments before and didn’t work. Fixed to 5 arguments. Please review:
Only quarter of next line is visible.
Pushed a modified dispatch_x. The vertical size calculation is flawed, as it will never manage all the possible situations. Looking into it, including the maximize button.
It was 4 arguments before and didn't work. Fixed to 5 arguments. Please review: https://github.com/Whonix/msgcollector/commit/a2faca06f814bcfaa47e9611938a20c13877026f
Let’s forget yesterday 
and start again on the right foot.
[quote=“Patrick, post:72, topic:246”]Can dispatch_x show colors? Such as we are using for whonixcheck in CLI, where [INFO] is colored? INFO is colored, while [ and ] are uncolored (default: white).
Maybe we color the text or we use background color for test? Maybe strings like “Tor Bootstrap Result” (without colon?) would have either green (info), yellow (warning) or red (error) background color?
Can you tell me please an example on how to use dispatch_x to show colored text?
If it’s possible and we think it’s a good idea, I would implement it into msgcollector as function pretty_type_x.
Maybe help.
<b><p style="color: white; background-color: green">info</p></b>
<b><p style="color: black; background-color: yellow">warning</p></b>
<b><p style="color: black; background-color: red">error</p></b>
[/quote]
pretty_type_x plus plus bold result in case of warning-error would look nice. In my opinion we should not touch the background (looks good in the console, but does not look professional in a GUI, too reminiscent of home made HTML only web pages).
A set of basic colors to choose from.
#!/bin/bash
set -x
msg="<p><br></br>orange<span style=color:#ff8000>WARNING</span>
<br></br>dark red<span style=color:#c00000>WARNING</span>
<br></br>dark green<span style=color:#008000>INFO</span>
<br></br>green<span style=color:#00c000>INFO</span>:
<br></br>red<span style=color:#ff0000>ERROR</span></p><p>
<br></br>orange bold<span style=font-weight:600;color:#ff8000>WARNING</span>
<br></br>dark red bold<span style=font-weight:600;color:#c00000>WARNING</span>
<br></br>dark green bold<span style=font-weight:600;color:#008000>INFO</span>
<br></br>green bold<span style=font-weight:600;color:#00c000>INFO</span>
<br></br>red bold<span style=font-weight:600;color:#ff0000>ERROR</span></p>"
./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x "error" "test title" "$msg" "1" ""I wanted to update messages for timesync.
#!/bin/bash
set -x
testfunct() {
local HELPTEXT="See logfile: <code>tail -f -n 20 /var/log/sdwdate.log</code>
<br></br>See status files: <code>cd /var/run/sdwdate && dir</code>
<br></br>Try again: Start menu -> Applications -> System -> Timesync
<br></br> or in Terminal: <code>timesync</code>
<br></br>Last resort: manually set the clock! (In UTC!):
<br></br><code>sudo su
<br></br>date -s \"17 FEB 2012 24:00:00\" && hwclock -w</code>"
local MSG="<p>Network Time Synchronization (timesync) failed!!!
<br></br>TIMESANITYCHECK_STATUS: "$TIMESANITYCHECK_STATUS_WORD"
<br></br>"$SDWDATE_STATUS" Please report this bug!
<br></br>
<br></br>$HELPTEXT<p>"
./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x "error" "test title" "$MSG" "1" ""
}
testfunctAnd noticed, that spaces are omitted.
Last resort: manually set the clock! (In UTC!): sudo su date -s \"17 FEB 2012 24:00:00\" && hwclock -w
Becomes.
Last resort: manually set the clock! (In UTC!): sudo su date -s \"17 FEB 2012 24:00:00\" && hwclock -w
Can this be fixed or must we use a special html code for spaces?
[quote=“Patrick, post:86, topic:246”]As long as open-link-confirmation was using zenity, we were using zenity with --no-markup for security reasons, because cmd args are untrusted input.
At the moment we’re forwarding that untrusted input (could contain html tags) to generic_gui_message. I think we must run the cmd args though striphtml before we can safely forward them to generic_gui_message. But since striphtml is part of msgcollector, open-link-confirmation would have to depend on msgcollector. Not ideal. Should we go that route?
Perhaps striphtml would be better off in an extra package, but which one? Too many packages also isn’t good for inclusion into distributions. Code duplication they also do not like.
I am having in mind inclusion of open-link-confirmation into other distributions. But I guess that is rather unlikely anyway. So we could go with the less ideal solution of letting open-link-confirmation depend on msgcollector. What do you think?[/quote]
Depend on msgcollector (for striphtml) and using striphtml before invoking generic_gui_message until there are better suggestions:
Using more secure defaults (does nothing if generic_gui_message does not work for some reason; default do nothing, only open link if yes button is clicked):
HTML tags in
Can this be fixed or must we use a special html code for spaces?
Yes,
creates an indented paragraph. Used every time there are spaces in the messages. Should be OK in the above, but I did not test locally. Please let me know.
I am proposing a stylistic change. How do you like it when using the tag as well? This is more a matter of taste.
In the following example, there is a problem.
#!/bin/bash
set -x
testfunct() {
local HELPTEXT="<p>See logfile: <blockquote><code>tail -f -n 20 /var/log/sdwdate.log</code></blockquote>
See status files: <blockquote><code>cd /var/run/sdwdate && dir</code></blockquote>
Try again: <blockquote>Start menu -> Applications -> System -> Timesync
<br></br>or in Terminal: <code>timesync</code></blockquote>
Last resort: manually set the clock! (In UTC!):
<blockquote><code>sudo su
<br></br>date -s \"17 FEB 2012 24:00:00\" && hwclock -w</code></blockquote></p>"
local MSG="<p><b>Network Time Synchronization (timesync) failed!!!</b>
<br></br>TIMESANITYCHECK_STATUS: "$TIMESANITYCHECK_STATUS_WORD"
<br></br>"$SDWDATE_STATUS" Please report this bug!</p>
$HELPTEXT"
./Whonix/packages/msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x "error" "test title" "$MSG" "1" ""
}
testfunct
Only half of
date -s "17 FEB 2012 24:00:00" && hwclock -w
is shown. If I understood you right last time, you are still working on this?
I am proposing a stylistic change. How do you like it when using the tag as well? This is more a matter of taste.
Nice stylistic change, to my taste too. :).
Only half of
is shown. If I understood you right last time, you are still working on this?
Yes, on this… and that… But when I run your script, the whole of ‘date -s “17 FEB 2012 24:00:00” && hwclock -w’ is shown. Just checked, you have the latest version of dispatch_x .
[quote=“Patrick, post:95, topic:246”][quote author=Patrick link=topic=261.msg2592#msg2592 date=1404215181]
As long as open-link-confirmation was using zenity, we were using zenity with --no-markup for security reasons, because cmd args are untrusted input.
At the moment we’re forwarding that untrusted input (could contain html tags) to generic_gui_message. I think we must run the cmd args though striphtml before we can safely forward them to generic_gui_message. But since striphtml is part of msgcollector, open-link-confirmation would have to depend on msgcollector. Not ideal. Should we go that route?
Perhaps striphtml would be better off in an extra package, but which one? Too many packages also isn’t good for inclusion into distributions. Code duplication they also do not like.
I am having in mind inclusion of open-link-confirmation into other distributions. But I guess that is rather unlikely anyway. So we could go with the less ideal solution of letting open-link-confirmation depend on msgcollector. What do you think?
[/quote]
Depend on msgcollector (for striphtml) and using striphtml before invoking generic_gui_message until there are better suggestions:
Using more secure defaults (does nothing if generic_gui_message does not work for some reason; default do nothing, only open link if yes button is clicked):
https://github.com/Whonix/open-link-confirmation/commit/845a8ff4c63cce7266f905f0ad7e6806c65baa62[/quote]
First of all, the problem expands, as generic_gui_message is now called from tb-starter and tb-updater. But…
open-link-confirmation and the other packages do not have to depend on msgcollector if we run the code inline in a simplified version.
#!/bin/bash
msg="<p>This is a link:</p>
<a href=https://www.whonix.org>https://www.whonix.org</a>"
export msg
stripped_msg="$(cat << EOF | python -
import os, re
message=re.sub('<[^<]+?>', '', os.getenv('msg'))
print message
EOF
)"
echo $stripped_msg
striphtml is not called from many places (at the moment…). It should not clutter the scripts too much.
That’s one option.
Another one could be merging generic-gui-message into msgcollector? What do you think?
generic-gui-message is unlikely to be accepted into Debian, I think, because it’s too tiny?
And msgcollector is unlikely to be accepted into Debian, I think, because Debian, because it’s too non-standard*? [* using acl; background process the gets started by /etc/profile.d and writes to tty0]
So it shouldn’t matter?