Thus said Kelly Dean on Thu, 08 Jan 2015 08:52:28 +0000: > Yes, a badly-behaving one. That's why I said the network probably > dropped some packets. But I used HTTPS, so the problems the proxy > could have introduced would be no more than dropped packets, and bogus > TCP resets (which SSL inanely fails to authenticate).
Unless MITM has occurred (which is unlikely) I'm not sure how to explain this, but were you presented with a certificate to accept and did it have the right fingerprint? Otherwise, I'm at a loss as to why this proxy (is it transparent or does Fossil know it's using a proxy?) would cause Fossil to leave behind a repository in this state. I haven't been able to cause it to do this with my tampering of my network, however, I don't have a misbehaving proxy to work with either. I've gone over relevant parts of the code (except perhaps for the lower level SSL stuff) and as far as I can tell, the only way project-code could be empty is if the HTTP response was truncated before the client saw the push card. I'm not even sure how this could be possible unless the underlying SSL library accepted a short read off the network (or MITM truncated the response) and didn't return some kind of an error. I do notice that Fossil doesn't verify that it got the mount of data that is expected to be delivered in the Content-length header: http://www.fossil-scm.org/index.html/info/7fe8a2731d517e5b03449c006efb2b019b86fce1?ln=375 It could verify iLength against what the previous read of the Content-length header returned here: http://www.fossil-scm.org/index.html/info/7fe8a2731d517e5b03449c006efb2b019b86fce1?ln=312,314 But this won't really help unless we think there is some kind of tampering going on with the response (e.g. the proxy is truncating after X number of bytes/lines, but how could it since this is HTTPS). I'm still baffled by what would cause Fossil to go 2 round-trips and then consider the transfer complete enough to rebuild and write the database. Clearly, no network error was detected, no read/write error on the network was detected, no error was reported by the server and it must have thought that the clone_seqno was 0, else it would have continued to ask the server for clone_seqno 1 repeatedly in a loop until... I'm not sure when. So, until someone is able to reproduce this more readily, I'm not sure what can be done about it. Anyone have a badly behaving proxy I can use, or ideas on how it can be simulated better? I was able to cause Fossil to exit with code 141 by causing the TCP/IP connection to be RST while it was transfering, but not with gdb attached and no core was left behind. So it's possible that the SSL library isn't very robust at handling network failures very well. Most of the time, my attempt to interrupt the transfer simply caused Fossil to hang because the TCP/IP connection remained in an ESTABLISHED state and it was just blocked on a read. Thanks, Andy -- TAI64 timestamp: 4000000054af6425 _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
