{"push_id":804714603,"size":5,"distinct_size":5,"ref":"refs/heads/master","head":"5c5ca116dbe1c62b447eaeb22d4e59db44b9a1f5","before":"43be90e287996e1be6f92f5a426475df25c16e10","commits":[{"sha":"5f6e443b55d9d2c53b0aadc857181ec377c95e18","author":{"email":"7951276d108732f685ad39766351430a193de32d@pobox.com","name":"Simon Tatham"},"message":"Don't try to agree a MAC we'll never use.\n\nIf we've chosen the ChaCha20-Poly1305 option for a cipher, then that\nforces the use of its associated MAC. In that situation, we should\navoid even _trying_ to figure out a MAC by examining the MAC string\nfrom the server's KEXINIT, because we won't use the MAC selected by\nthat method anyway, so there's no point imposing the requirement on\nservers to present a MAC we believe in just so we know it's there.\n\nThis was breaking interoperation with tinysshd, and is in violation of\nOpenSSH's spec for the \"chacha20-poly1305@openssh.com\" cipher.","distinct":true,"url":"https://api.github.com/repos/NaldoDj/putty/commits/5f6e443b55d9d2c53b0aadc857181ec377c95e18"},{"sha":"bea758a7ae0507e0d4a24b370f8401661cc1a2c8","author":{"email":"7951276d108732f685ad39766351430a193de32d@pobox.com","name":"Simon Tatham"},"message":"Fix spurious EAGAIN in Plink host key (and other) prompts.\n\nPlink sets standard input into nonblocking mode, meaning that read()\nfrom fd 0 in an interactive context will typically return -1 EAGAIN.\nBut the prompt functions in uxcons.c, used for verifying SSH host keys\nand suchlike, were doing an unguarded read() from fd 0, and then\npanicking and aborting the session when they got EAGAIN.\n\nFixed by inventing a wrapper around read(2) which handles EAGAIN but\npasses all other errors back to the caller. (Seemed slightly less\ndangerous than the stateful alternative of temporarily re-blockifying\nthe file descriptor.)","distinct":true,"url":"https://api.github.com/repos/NaldoDj/putty/commits/bea758a7ae0507e0d4a24b370f8401661cc1a2c8"},{"sha":"342f287660cb180a393db779df58ad4a6c9f4893","author":{"email":"7951276d108732f685ad39766351430a193de32d@pobox.com","name":"Simon Tatham"},"message":"Use a Cairo image surface as a client-side cache.\n\nIn any DRAWTYPE_CAIRO mode, we now do all our Cairo drawing to a Cairo\nimage surface which lives on the client; then we either blit directly\nfrom that to the window (if we're in GTK3 mode, or GTK2 without\ndeprecated pieces of API), or else we blit from the Cairo surface to\nthe server-side pixmap and then from there to the actual window.\n\nIn DRAWTYPE_GDK mode, nothing much has changed: we still draw directly\nto the server-side pixmap using the GDK drawing API, then blit from\nthere to the window. But there is one change, namely that the blit is\nno longer done proactively - instead, we queue a redraw of the\naffected rectangle, and wait until we're called back by the expose\nhandler.\n\nThe main aim of all this is to arrange that the only time we ever draw\nto the real window is in response to expose/draw events. The\nexperimental GTK3 OS X port stopped working a week or two ago (I\npresume in response to an OS update) with the symptoms that attempts\nto draw on the window outside the context of a \"draw\" event handler\njust didn't seem to work any more; this change fixes it.\n\nIn addition to that benefit, this change also has obvious performance\nadvantages in principle. No more expensive text rendering in response\nto an expose event - just re-copy to the window from the bitmap we\nalready have, from wherever it's stored that's nearest.\n\nMoreover, this seems to have fixed the significant performance problem\nwith X server-side fonts under GTK. I didn't expect _that_! I'd\nguessed that the approach of downloading character bitmaps and\nrendering them manually via Cairo was just inherently slow for some\nreason. I've no real idea _why_ this change improves matters so much;\nmy best guess is that perhaps there's an overhead in each drawing\noperation to a GDK Cairo surface, so we win by doing lots of\noperations to a much faster image surface and then batching them up\ninto one GDK Cairo operation. But whyever it is, I'm certainly not\ncomplaining!\n\n(In fact, it now seems to be noticeably _faster_, at least on my usual\nlocal X displays, to draw server-side fonts using that technique than\nusing the old GDK approach. I may yet decide to switch over...)","distinct":true,"url":"https://api.github.com/repos/NaldoDj/putty/commits/342f287660cb180a393db779df58ad4a6c9f4893"},{"sha":"13edf90e0a4397088085cfcd53a4311319b708b4","author":{"email":"7951276d108732f685ad39766351430a193de32d@pobox.com","name":"Simon Tatham"},"message":"Command-line options to log sessions.\n\nLog files, especially SSH packet logs, are often things you want to\ngenerate in unusual circumstances, so it's good to have lots of ways\nto ask for them. Particularly, it's especially painful to have to set\nup a custom saved session to get diagnostics out of the command-line\ntools.\n\nI've added options '-sessionlog', '-sshlog' and '-sshrawlog', each of\nwhich takes a filename argument. I think the fourth option (session\noutput but filtered down to the printable subset) is not really a\n_debugging_ log in the same sense, so it's not as critical to have an\noption for it.","distinct":true,"url":"https://api.github.com/repos/NaldoDj/putty/commits/13edf90e0a4397088085cfcd53a4311319b708b4"},{"sha":"5c5ca116dbe1c62b447eaeb22d4e59db44b9a1f5","author":{"email":"7951276d108732f685ad39766351430a193de32d@pobox.com","name":"Simon Tatham"},"message":"Centralise stripslashes() and make it OS-sensitive.\n\nI noticed that Unix PSCP was unwantedly renaming downloaded files\nwhich had a backslash in their names, because pscp.c's stripslashes()\ntreated \\ as a path component separator, since it hadn't been modified\nsince PSCP ran on Windows only.\n\nIt also turns out that pscp.c, psftp.c and winsftp.c all had a\nstripslashes(), and they didn't all have quite the same prototype. So\nnow there's one in winsftp.c and one in uxsftp.c, with appropriate\nOS-dependent behaviour, and the ones in pscp.c and psftp.c are gone.","distinct":true,"url":"https://api.github.com/repos/NaldoDj/putty/commits/5c5ca116dbe1c62b447eaeb22d4e59db44b9a1f5"}]}