grahamedgecombe

You can still request permission to use it for apps distributed via Google Play for a limited set of use cases:

https://support.google.com/googleplay/android-developer/answ...

which is then subject to Google reviewing and approving it.

I assume HSBC are using the "antivirus" use case.

We've been experimenting with Azure's IPv6 support at work recently. The fact it uses NAT is insane - though we could tolerate that. Even worse is that the NAT is broken - it doesn't update the ICMPv6 checksum when it rewrites the source/destination address, so the machines on both ends drop all ICMPv6 traffic that passes through Azure.

This is rather bad considering the importance of ICMPv6 in IPv6 (for Path MTU Discovery, for example).

Their support is being rather useless, despite us having to pay for the privilege of reporting a bug in their own infrastructure to them!

In the UK it's probably already illegal under the Computer Misuse Act, as it'd fall under "unauthorised modification of computer material".

I assume other countries have similar laws.

That said, enforcing it is a different matter.

> "runes" like Go would be even better but codepoints are halfway there

Go runes are codepoints.

I think Swift is interesting, a "character" in Swift is actually a grapheme cluster.

I don't think `mkcert -install` requires root in all cases. The NSS trust store is stored in ~/.pki/nssdb/ and can be written to without root.

It's probably easier to manually merge the manifest (as they're much more human-readable) than a lock file though.

> But you won't be able to synthesize a RISC-V CPU. The iCE40 series consists of relatively small parts.

You can fit picorv32 on an iCE40-HX8K, although admittedly you'll only get an RV32IMC core with just the user ISA.

The citext type automatically does case-insensitive comparisons: https://www.postgresql.org/docs/current/static/citext.html

> each device gets 2^64 addresses

Each subnet gets 2^64 addresses. You can have multiple devices in the same subnet.

Chrome requires Certificate Transparency for the EV indicator to be displayed - see https://news.netcraft.com/archives/2015/08/24/thousands-shor...

Wildcards are in the version of the ACME spec at https://letsencrypt.github.io/acme-spec/:

> A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the “*” label).

Although this seems to be gone from https://ietf-wg-acme.github.io/acme/, which I think is the later version.

CAs are forbidden from issuing a cert for * .co.uk. The Baseline Requirements say:

> The CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "* .com", "* .co.uk", see RFC 6454 Section 8.2 for further explanation).

This basically means that the CA should check the Public Suffix List before they issue a wildcard.

As a 'just in case' measure, most modern browsers also reject certs where the wildcard is directly below something on the PSL.

(sorry for the spaces after the asterisks, HN seemed to like converting big chunks of the post to italics)

> You need to zero fill .bss section in the boot code before jumping to C code.

GRUB does this for you. See this thread from a few years ago: https://news.ycombinator.com/item?id=7590790

Amazon bought one of the Starfield roots from GoDaddy last year: https://mobile.twitter.com/Cryptoki/status/61114541131566694...

use -std=gnu99 instead

People have been able to get SSL certs for webmail domains before, as the webmail providers hadn't blacklisted some of the emails CAs can use for domain validation by email. e.g. see http://www.entrust.com/what-happened-with-live-fi/

X509 extensions can be marked as critical. Certificates must be rejected if the stack encounters a critical extension it doesn't understand. (In theory at least, I haven't looked at real implementation behaviour.)

I get the impression that 296 is meant to be 2^96, which is exactly the same as your figure.

And LibreSSL also has support for ChaCha20.

I've just checked the GRUB source code and I think it will clear the .bss section even if it's loading an ELF file.

grub-core/loader/multiboot_elfxx.c has a function named grub_multiboot_load_elf32/64 which actually loads the segments of the ELF file. A segment has two fields defining its size: filesz (which is the amount of bytes to copy from the file) and memsz (which is its actual size once loaded). If memsz is greater than filesz, it zeroes the trailing bytes:

  if (phdr(i)->p_filesz < phdr(i)->p_memsz)
    grub_memset ((grub_uint8_t *) source + phdr(i)->p_filesz, 0,
      phdr(i)->p_memsz - phdr(i)->p_filesz);

The .bss section is placed by the linker at the end of a segment and increases memsz by the size of it (but not filesz, to avoid having to place lots of pointless zeroes in the ELF file) - for example this is one of the segments from my kernel's ELF file, which contains the .bss section at the end:

  LOAD off    0x0000000000020000 vaddr 0xffffffff8011f000 paddr 0x000000000011f000 align 2**12
       filesz 0x0000000000004be0 memsz 0x0000000000017678 flags rw-

Here you can see memsz is 0x17678 bytes and filesz is smaller at 0x4be0 bytes. The difference between them is the size of the .bss section.

grub_multiboot_load_elf32/64 is called in the case when the address tag is not present, so the .bss section will be cleared by GRUB in this case as well.

It's still important to test on physical hardware though, perhaps on an old spare machine you don't care about if you want to be cautious, as the virtual machines do not perfectly emulate real hardware. For example, QEMU initializes memory to all zeroes, whereas on a real system it's typically all ones, which led to some interesting bugs in my OS on real hardware where I had forgotten to zero out some memory.

It's worth pointing out there are a few bugs in James Molloy's tutorial [1], and some of the things he does in them aren't exactly best practices - for example, a few I remember are:

- Disabling interrupts and paging (which also has the side effect of flushing the TLB) to copy memory around by physical address. This could be done without disabling them by mapping all of physical memory into virtual memory instead (possible in 64-bit mode, but in 32-bit there isn't enough room when your PC has a similar amount of RAM to virtual memory space, in which case you could map smaller parts of it as needed).

- Moving the stack around to get around the fact that GRUB doesn't set ESP to some well-defined value (instead of defining the stack yourself, which would be much more robust) and then attempting to rewrite the base pointers to fix it. For example, his code can't tell the difference between integers that just happen to have a value in the range of the pointers and a pointer, and will happily rewrite both. Also as ESP isn't defined by the Multiboot standard you could be using any location at all as the stack (such as some memory address that doesn't exist, or your kernel's code itself, or some memory-mapped area for a piece of hardware, etc.) All of which will mean things go wrong. It's better to just set ESP yourself before you enter C - see another of my comments on this submission here [3].

There's actually a newer and much better version of JamesM's tutorials on GitHub, but I believe they aren't quite finished [2].

[1]: http://wiki.osdev.org/James_Molloy%27s_Known_Bugs [2]: https://github.com/jmolloy/JMTK [3]: https://news.ycombinator.com/item?id=7590753

> Another thing that is missing is clearing the .BSS section before passing control to the C code. It's not used at the moment, though.

The Multiboot standard says that the boot loader will clear the .bss section for you - in section 3.1.3: "bss_end_addr Contains the physical address of the end of the bss segment. The boot loader initializes this area to zero"

I don't know what GRUB does if you rely on that fact it can parse ELF files and don't specify the fields like bss_end_addr though. I'm fairly sure it clears it in this case too, but I'm using Multiboot 2 for my OS so the behaviour could be different.

There's a slight problem in this tutorial in that it assumes ESP (the stack pointer) will be defined by the boot loader to point to an appropriate location for the stack. However, the Multiboot standard states that ESP is undefined [1], and that the OS should set up its own stack as soon as it needs one (here the CALL instruction uses the stack, and the compiled C code may well too).

An easy way to solve this is to reserve some bytes in the .bss section of the executable for the stack by adding a new section in the assembly file:

  [section .bss align=16]
    resb 8192
    stack_end:

Then before you make use of the stack (between `cli` and `call kmain` would be appropriate in this case), you need to set the stack pointer:

  mov esp, stack_end

[1]: https://www.gnu.org/software/grub/manual/multiboot/multiboot...

> losetup on a disk image doesn't (to my knowledge) detect partitions… for reasons unknown to me.

You can use the kpartx command for this. This site has a good overview: http://nfolamp.wordpress.com/2010/08/16/mounting-raw-image-f...

OCSP and CRLs allow a CA to revoke an SSL certificate (albeit with a varying degree of browser support).

It can work like this - see: http://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel

I suspect DigitalOcean have more virtual servers per physical machine than Linode do, which is probably why they can offer cheaper prices. This means you probably won't be able to use as much CPU power and I/O (more people contending for the same resources.)

The old L5520 processors they are using have 4 cores with hyperthreading, so it appears as 8 to the OS - so they don't have to have changed the host machines to present 8 cores to the VMs.

> The interesting thing is that linode started out as a cheaper alternative to slicehost

Linode have been around since 2003. I think Slicehost was founded later than this (in 2006 according to a quick search for their name.)