<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libgit2.git, branch ethomson/sslread</title>
<subtitle>github.com: libgit2/libgit2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/'/>
<entry>
<title>httpclient: use a 16kb read buffer for macOS</title>
<updated>2020-03-05T00:24:41+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-01T20:44:39+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=502e5d5126ff50775f9c9143e5b424f0aaef9c16'/>
<id>502e5d5126ff50775f9c9143e5b424f0aaef9c16</id>
<content type='text'>
Use a 16kb read buffer for compatibility with macOS SecureTransport.

SecureTransport `SSLRead` has the following behavior:

1. It will return _at most_ one TLS packet's worth of data, and
2. It will try to give you as much data as you asked for

This means that if you call `SSLRead` with a buffer size that is smaller
than what _it_ reads (in other words, the maximum size of a TLS packet),
then it will buffer that data for subsequent calls.  However, it will
also attempt to give you as much data as you requested in your SSLRead
call.  This means that it will guarantee a network read in the event
that it has buffered data.

Consider our 8kb buffer and a server sending us 12kb of data on an HTTP
Keep-Alive session.  Our first `SSLRead` will read the TLS packet off
the network.  It will return us the 8kb that we requested and buffer the
remaining 4kb.  Our second `SSLRead` call will see the 4kb that's
buffered and decide that it could give us an additional 4kb.  So it will
do a network read.

But there's nothing left to read; that was the end of the data.  The
HTTP server is waiting for us to provide a new request.  The server will
eventually time out, our `read` system call will return, `SSLRead` can
return back to us and we can make progress.

While technically correct, this is wildly ineffecient.  (Thanks, Tim
Apple!)

Moving us to use an internal buffer that is the maximum size of a TLS
packet (16kb) ensures that `SSLRead` will never buffer and it will
always return everything that it read (albeit decrypted).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use a 16kb read buffer for compatibility with macOS SecureTransport.

SecureTransport `SSLRead` has the following behavior:

1. It will return _at most_ one TLS packet's worth of data, and
2. It will try to give you as much data as you asked for

This means that if you call `SSLRead` with a buffer size that is smaller
than what _it_ reads (in other words, the maximum size of a TLS packet),
then it will buffer that data for subsequent calls.  However, it will
also attempt to give you as much data as you requested in your SSLRead
call.  This means that it will guarantee a network read in the event
that it has buffered data.

Consider our 8kb buffer and a server sending us 12kb of data on an HTTP
Keep-Alive session.  Our first `SSLRead` will read the TLS packet off
the network.  It will return us the 8kb that we requested and buffer the
remaining 4kb.  Our second `SSLRead` call will see the 4kb that's
buffered and decide that it could give us an additional 4kb.  So it will
do a network read.

But there's nothing left to read; that was the end of the data.  The
HTTP server is waiting for us to provide a new request.  The server will
eventually time out, our `read` system call will return, `SSLRead` can
return back to us and we can make progress.

While technically correct, this is wildly ineffecient.  (Thanks, Tim
Apple!)

Moving us to use an internal buffer that is the maximum size of a TLS
packet (16kb) ensures that `SSLRead` will never buffer and it will
always return everything that it read (albeit decrypted).
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #5437 from libgit2/ethomson/azp</title>
<updated>2020-03-02T19:26:22+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-02T19:26:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=cd6ed4e48c25ab75ba3acbc8f24b21ad66f2d8d6'/>
<id>cd6ed4e48c25ab75ba3acbc8f24b21ad66f2d8d6</id>
<content type='text'>
ci: provide globalsign certs for bionic</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ci: provide globalsign certs for bionic</pre>
</div>
</content>
</entry>
<entry>
<title>ci: provide globalsign certs for bionic</title>
<updated>2020-03-02T18:22:54+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-02T18:22:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=dc55d0e8fe71a80a52591e8f9ab55de636bc11d3'/>
<id>dc55d0e8fe71a80a52591e8f9ab55de636bc11d3</id>
<content type='text'>
tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #5426 from pks-t/pks/freebsd-htobe64</title>
<updated>2020-03-01T23:57:24+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-01T23:57:24+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=6d25dbdc5c3924336f61bc6091df64821acb95f2'/>
<id>6d25dbdc5c3924336f61bc6091df64821acb95f2</id>
<content type='text'>
deps: ntlmclient: fix htonll on big endian FreeBSD</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
deps: ntlmclient: fix htonll on big endian FreeBSD</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #5433 from libgit2/ethomson/azp</title>
<updated>2020-03-01T23:56:22+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-01T23:56:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=8c1aef10b82adf34a80e60909c27bd14d5b35163'/>
<id>8c1aef10b82adf34a80e60909c27bd14d5b35163</id>
<content type='text'>
azure-pipelines: download GlobalSign's certificate manually</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
azure-pipelines: download GlobalSign's certificate manually</pre>
</div>
</content>
</entry>
<entry>
<title>ci: provide globalsign certs</title>
<updated>2020-03-01T23:34:44+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-03-01T22:42:03+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=0f316d5957b2148c297c455a2e03ca555693d61e'/>
<id>0f316d5957b2148c297c455a2e03ca555693d61e</id>
<content type='text'>
tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄
</pre>
</div>
</content>
</entry>
<entry>
<title>deps: ntlmclient: fix htonll on big endian FreeBSD</title>
<updated>2020-02-26T18:34:49+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2020-02-26T18:34:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=c690136c78075cc95ea4f1b9578f8133136299ee'/>
<id>c690136c78075cc95ea4f1b9578f8133136299ee</id>
<content type='text'>
In commit 3828ea67b (deps: ntlmclient: fix missing htonll symbols on
FreeBSD and SunOS, 2020-02-21), we've fixed compilation on BSDs due to
missing `htonll` wrappers. While we are now using `htobe64` for both
Linux and OpenBSD, we decided to use `bswap64` on FreeBSD. While correct
on little endian systems, where we will swap from little- to big-endian,
we will also do the swap on big endian systems. As a result, we do not
use network byte order on such systems.

Fix the issue by using htobe64, as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit 3828ea67b (deps: ntlmclient: fix missing htonll symbols on
FreeBSD and SunOS, 2020-02-21), we've fixed compilation on BSDs due to
missing `htonll` wrappers. While we are now using `htobe64` for both
Linux and OpenBSD, we decided to use `bswap64` on FreeBSD. While correct
on little endian systems, where we will swap from little- to big-endian,
we will also do the swap on big endian systems. As a result, we do not
use network byte order on such systems.

Fix the issue by using htobe64, as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge pull request #5417 from pks-t/pks/ntlmclient-htonll</title>
<updated>2020-02-25T21:49:16+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2020-02-25T21:49:16+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=a48da8fab662aaa77340a3e969ac0deec9d51731'/>
<id>a48da8fab662aaa77340a3e969ac0deec9d51731</id>
<content type='text'>
deps: ntlmclient: fix missing htonll symbols on FreeBSD and SunOS</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
deps: ntlmclient: fix missing htonll symbols on FreeBSD and SunOS</pre>
</div>
</content>
</entry>
<entry>
<title>transports: auth_ntlm: fix use of strdup/strndup</title>
<updated>2020-02-24T20:49:43+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2020-02-24T20:49:43+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=ebade23333d1f5c460aeb7f02473c96c95568a91'/>
<id>ebade23333d1f5c460aeb7f02473c96c95568a91</id>
<content type='text'>
In the NTLM authentication code, we accidentally use strdup(3P) and
strndup(3P) instead of our own wrappers git__strdup and git__strndup,
respectively.

Fix the issue by using our own functions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the NTLM authentication code, we accidentally use strdup(3P) and
strndup(3P) instead of our own wrappers git__strdup and git__strndup,
respectively.

Fix the issue by using our own functions.
</pre>
</div>
</content>
</entry>
<entry>
<title>deps: ntlmclient: fix missing htonll symbols on FreeBSD and SunOS</title>
<updated>2020-02-24T20:46:41+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2020-02-21T10:26:19+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=3828ea67b97fc56dead976f319792ead3aa7e623'/>
<id>3828ea67b97fc56dead976f319792ead3aa7e623</id>
<content type='text'>
The ntlmclient dependency defines htonll on Linux-based systems, only.
As a result, non-Linux systems will run into compiler and/or linker
errors due to undefined symbols.

Fix this issue for FreeBSD, OpenBSD and SunOS/OpenSolaris by including
the proper headers and defining the symbol accordingly.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ntlmclient dependency defines htonll on Linux-based systems, only.
As a result, non-Linux systems will run into compiler and/or linker
errors due to undefined symbols.

Fix this issue for FreeBSD, OpenBSD and SunOS/OpenSolaris by including
the proper headers and defining the symbol accordingly.
</pre>
</div>
</content>
</entry>
</feed>
