Nathaniel Smith wrote:
> On Sun, Nov 8, 2009 at 4:10 AM, Antoine Martin <[email protected]> wrote:
>> Nathaniel Smith wrote:
>>> avoid-apport-whenkilled.patch: Fails to apply. What is it trying to do?
>> Ubuntu Karmic (and probably others) will catch a python unclean exit
>> (ctrl^C, SIGINT) and launch apport to report an application crash upstream.
>>
>> In this case, it is not a crash, so it is best to catch the exception
>> and exit cleanly (with an error code if needed)
>
> Okay... but that patch just adds a try/catch around the initial client
> socket creation, and only catches socket errors. It only affects the
> initial connection, and even then it doesn't affect SIGINT handling...
Yes, this patch (rebased):
http://xpra.devloop.org.uk/patches/v0.0.8pre/avoid-apport-whenkilled-againstmainline.patch
Prevents apport from firing if you get the target wrong.
> Also, I'm running karmic and hitting control-C on the client doesn't
> trigger apport for me...
>
>>> catch-socket-error.patch: ...this is the same as
>>> avoid-apport-whenkilled.patch?
>> Nope, this one is a real bug: the log statement uses a variable ("e")
>> which does not exist.
>
> Look again:
> http://xpra.devloop.org.uk/patches/catch-socket-error.patch
> You're thinking of something else...?
Yes, I was thinking of bug-xerror-undef-var.patch
>>> cleanup-parti-main-unusedimport.patch: Fixed in a better way.
>> Can you elaborate?
>> What's better than removing one line of unused code? Removing two?
>
> Well, it's pretty trivial anyway, but:
>
> http://code.google.com/p/partiwm/source/diff?spec=svn9c713271d55dcb6fa5ad580b2e36af9b09d6389e&r=9c713271d55dcb6fa5ad580b2e36af9b09d6389e&format=side&path=/parti/parti_main.py
hah, commented out, just a bit further down.
>>> cleanup-parti-scripts-unusedvars.patch: (options, args) =
>>> parser.parse_args(...) is idiomatic; this patch makes the code harder
>>> to read, not easier...
>> The aim was not to make it easier or harder to read, just to remove
>> unused variables (hence the name of the patch).
>> This allows IDEs (pydev/lint) to find real bugs automatically, they have
>> already found a few.
>
> Making code readable for these IDEs requires making it less readable
> for humans? That seems like quite a limitation :-).
>
> Certainly they're handy, and I did apply various of the changes they
> suggested, that I wouldn't have noticed otherwise. But they have false
> positives, too; that's the nature of lint tools.
Yes, and unlike with Java (and others) there are no ways of turning off
those warnings on a per case basis, which is a real shame.
I generally prefer adding one line of documentation explaining what the
structure is/does add gaining the ability to spot bugs automatically.
But in this case I have no strong feelings either way.
>>> cleanup-wimpiggy-prop-unusedimportsandvars.patch: Applied the part of
>>> this that I like.
>>> cleanup-wimpiggy-unusedimportsandvars.patch: Applied the parts of this
>>> that I like.
>>> cleanup-xpra-scripts-unusedimportsandvars.patch: Ditto.
>>> cleanup-xpra-unusedimportsandvars.patch: Ditto.
>>> cleanup-yatest-whitespace-import.txt: Ditto.
>> I hope this includes the changes to the import statements for
>> wimpiggy.error, as this otherwise imports the logger twice which is
>> unnecessary at best, potentially worse.
>
> Yes, I noticed that. I originally designed 'wimpiggy.trap' to be used
> with 'import *', and then broke that slightly when I added the logging
> code, so I fixed 'wimpiggy.trap' by defining __all__. Maybe it would
> be better to stop using 'import *', I dunno, probably doesn't make
> much difference, but for now I just standardized on 'import *' because
> it was the majority.
I dislike import '*' because it is not really clear what it does from
reading the code. You know, "harder for humans"? ;)
And it makes lint unhappy too.
>>> xpra-name-windows.patch: Can you remind me what the point of this is?
>> So you can set the title of the xpra client window. You suggested
>> passing it from the server since it is a window attribute. I would be
>> happy with that, but until that's implemented/working this patch is
>> quite useful.
>
> Ah, right, thanks for the reminder.
>
> Okay, I just committed the version where it shows the actual machine
> where the app is running by default :-). Do you still care about the
> command line option, given that?
Actually yes, it can be a lot more relevant to name a session (purpose)
than its machine (location).
[snip]
>>> -- Continuing to defer these until there's a chance to get it right.
>> You could at least merge the parts which are uncontroversial and make
>> the code better.
>
> Yes, I did that a while ago, these remaining ones are the ones that
> involve adding spaghetti if/then's for different platforms to the main
> code... (AFAICT)
This one would make my life soooo much easier, and should be totally
uncontroversial:
http://xpra.devloop.org.uk/patches/v0.0.8pre/mswindows-move-eventcode.patch
>> Also "getting it right" will probably have to rely on these patches in
>> some shape or form: generic win32 does not and will not support X11 (I'm
>> not talking about Cygwin etc), so the clipboard simply cannot be
>> implemented via the current ClipboardProtocolHelper for example.
>
> Yes, of course. My point is just that these patches are not about
> changing any core functionality (that part, e.g. your patch for the
> glib mainloop's tricky behavior on win32, was already merged), they're
> about stubbing out stuff that doesn't work on win32. I would like to
> do that in a cleaner way (i.e., by separating out platform-specific
> code into its own module, rather than having if/then's scattered
> around the whole program), and these patches are very useful in
> identifying which bits need to be separated out, but *applying* them
> won't help much with that.
OK.
>>> xpra-allow-bind-to-all-interfaces.patch
>>> password-file.patch
>>> password-secure.patch
>>> password.patch
>>> -- Okay, seriously: Why do you care about TCP? Is it just because
>>> implementing ssh support on windows is hard? Because I keep asking
>>> this, and I keep not getting an answer, just more and more patches to
>>> enhance an option that is fundamentally insecure and misleads users
>>> into doing insecure things. Please?
>> Seriously, please refrain from claiming things like "fundamentally
>> insecure and misleads users", as it's just not backed up by facts.
>
> All I mean is that TCP is never going to be as secure as ssh, and in
> most situations will be substantially less secure,
Hmmm, we'll have to agree to disagree on this one.
Having to hand out SSH logins simply to bind to a port has its own
security cost/impact.
And HMAC is very robust (yet simple to implement), despite the
weaknesses in MD5/SHA-1:
http://www.ietf.org/mail-archive/web/cfrg/current/msg00527.html
"In particular, known collisions (for KNOWN IVs) in the underlying hash
functions are IRRLEVANT to the security of HMAC."
The main difference between the two is that the shared secret is
asymetric in the case of SSH (public/private key) whereas HMAC just
relies on the salt to prevent replay attacks. The password used can me
made long enough to make all brute force attacks impractical.
> and that very few
> users have the technical knowledge to make an informed judgment
> between them -- yet the option is supported and documented, so they
> have to make such a judgment anyway,
I don't think they do. The default is SSH, if they choose to use TCP
then it is fair to assume that they at least understand the difference
between the two. The *nix philosophy is to give you enough rope.
If they choose a stupid/short password, the same reasoning applies.
> and some will get it wrong. (I've
> talked to at least one person on IRC who AFAICT was using TCP because
> it must be faster.
On LANs (1GBit or higher), this would make sense. I will try to find the
time to run some benchmarks on 100MBit.
Another point I forgot to mention is startup speed, the SSH
handshake/login sequence can be quite slow. TCP is almost instantenuous.
Also, bear in mind that a lot of thin clients don't have a lot of CPU
resources (hence the use of remote displays), so taxing the CPU is
generally a last resort, and with SSH (even with the lowest compression)
you will add that extra cost.
> This is almost certainly wrong, I'm not at all sure
> it was secure in their situation, and they'd have been better served
> if the option just didn't exist.)
>
> Which parts of this are not backed up by facts?
[snip]
>> Some of the benefits of plain TCP are (you can google the details and
>> the ones I have mentioned before):
>> * SSH is not necessary on a secured network. Why require things that
>> just aren't necessary!?
>
> Why require support for raw TCP sockets when it's just not necessary? ;-)
>
> Let's stop talking hypotheticals. When you, personally, want to log
> into a remote machine over a secured network, do you use ssh or
> telnet?
Do you prefer apples or oranges? ;)
> Do you, personally, insist that sysadmins install and support telnet
> servers, because you refuse to use ssh over secure networks?
Have you ever tried explaining what a public/private key is to an
average MS Windows user?
Even some who would consider themselves "power-users" still use
ftp/telnet (I had one *today*). Welcome to the 1990s... sigh.
> If the network is *really* secured, then why do you need password support?
Fair point.
It may be secured in the sense that you don't have to worry about
intruders snooping, but that you still want to control who can attach to
the session.
> If it isn't really secured, enough so that you do need password
> support, then how do we know it is secure enough that you don't need
> the many other security features ssh provides?
The one thing I have reservations on is the ability for someone snooping
on the network to replay the screen redraws on their own machine. This
is one thing SSH prevents that plain TCP simply cannot do.
>> * SSH is simply not desirable in some use cases: if I want to give
>> access to a session, having to hand out SSH accounts (keys, passwords
>> whatever) for just binding to a port is crazy.
>
> Right now, to me, this seems like the only real argument. But this is
> so far outside xpra's core use case, and describes a situation that is
> so likely to require special infrastructure *anyway*, that I don't
> find it very convincing on its own.
The only special infrastructure is an application to serve, think thin
clients/kiosks types.
>> * Win32 and SSH don't get on. Putty/Plink is no go and openssh would
>> require cygwin. Keep it simple.
>
> AFAIK, I've made them "go" -- though I'm still waiting for someone to
> confirm that, see the other thread. Is there something I'm missing?
I'll try to find the time to test that soon...
Cheers
Antoine
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
