this implements SHA2 (224, 256, 384, 512) signature algorithms and
uses sha256WithRSAEncryption for X509req() and X509gen() instead
of oid_md5WithRSAEncryption.
the compiler used to skip zero initialization when initializer
list was given not covering unspecified elements. now we zero
all non explicitely initialized elements. for example:
typedef struct F F;
struct F
{
int a;
int b;
int c;
};
void
main(void)
{
char a[16] = { 1, 2, 3 }; /* a[3..15] initialized to zero */
F f = { .b = 1 }; /* f.a, f.c initialized to zero */
}
the emited code that initializes local variables did not handle
unaligned data causing stack corruption, affecting code like:
void main(void)
{
char a[9] = {0};
}
this change will emit code that does byte stores for the unaligned
bytes and also handles small objects (<= 16 bytes) without branches.
tlsClient() now can optionally send the server_name in the ClientHello
message by setting the TLSconn.serverName. This is required for some
https sites.
using /proc/$pid/mem to access vga bios is not portable and crashes
sgi machines when aux/vga is run. instead, try /dev/realmodemem
first (provided by realemu), then #v/vgabios.
this allows extracting tar archives that use longnames extension,
where the real filename is stored in a special entry with
linkflag == 'L' before the file entry. also skip longlink entries
with linkflag == 'K'.
David du Colombier wrote:
> The slowness issue only appears on the loopback, because
> it provides a 16384 MTU.
>
> There is an old bug in the Plan 9 TCP stack, were the TCP
> MSS doesn't take account the MTU for incoming connections.
>
> I originally fixed this issue in January 2015 for the Plan 9
> port on Google Compute Engine. On GCE, there is an unusual
> 1460 MTU.
>
> The Plan 9 TCP stack defines a default 1460 MSS corresponding
> to a 1500 MTU. Then, the MSS is fixed according to the MTU
> for outgoing connections, but not incoming connections.
>
> On GCE, this issue leads to IP fragmentation, but GCE didn't
> handle IP fragmentation properly, so the connections
> were dropped.
>
> On the loopback medium, I suppose this is the opposite issue.
> Since the TCP stack didn't fix the MSS in the incoming
> connection, the programs sent multiple small 1500 bytes
> IP packets instead of large 16384 IP packets, but I don't
> know why it leads to such a slowdown.