cm3

I cannot express how much I like this. This is a great tool and the right one to write a replacement TLS stack with. Excited for things to come.

The original NaCl had assembly implementations, I believe generated with a Perl script (not unlike OpenSSL's asm generator), and looking around libsodium I cannot see assembly implementations of the loops. Does anyone know why that is? I believe the Linux kernel implementation of ChaCha20 carries asm versions.

Not criticizing the project, genuinely curious:

It's great that browsers can achieve more functionality previously exclusive to native applications, but anytime a code editor written in JavaScript to be run in a browser is announced, I wonder one thing: why don't we try to come up with a client/server protocol that would allow you to use your local editor, which is already fully customized to your needs? Is the idea that the files being edited are remote and therefore the only thing that would make sense is improving extensions like "It' All Text!" or wasavi?

It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd.

hg absorb sounds very useful. I'd like to know details, since I can imagine undesired results it might produce.

Of course Python as an abstraction layer made it more readily available on Windows and allowed allocation of developer resources to hgtk, including a Windows Explorer extension.

Still, despite its flaws, C is the common layer we have to expose an API that you want to be consumed everywhere. That, or a message passing interface with a client/server architecture. A client/server design may lead to zombie servers, while a tightly coupled C API might crash your application, though you can isolate the C API consumer in a supervised and automatically restarted server you talk to with messages, so that's the more flexible API to have.

The Rust rewrite of parts of Mercurial by Facebook is a no-brainer and given the possibility of GC-less C API in Rust, I wouldn't be surprised if a built-in-Rust C API for Mercurial were to follow. I don't like Rust when compared to high-level languages, but it's a viable C replacement with compile-time exclusion of certain bug classes, so I can get behind such a project. That said, the soundness bugs reported on github are worrisome, so I wouldn't trust Rust's checker to be correct or exhaustive, just yet. It's still a step up from C, that's undeniable.

The possibility of extending the Mercurial core with a well-defined API is one major reason. In fact, most interesting features are extensions, bundled with Mercurial, and after several releases and experience, the functionality usually gets integrated into Mercurial proper (most often than not still as an extension). This is, unfortunately not an C API but Python, but it's still an advantage Mercurial has for now. Git has various efforts to build reusable libraries to write tools with, but there isn't an officially sanctioned _and_ complete one that works across all platforms. Microsoft has removed their reliance on libgit2 and shells out to git in Visual Studio now. If the git project had an official libgit, which exposed all functionality, is reused by git itself, and worked across all platforms, the situation would be in favor of git because consuming a C API is more broadly supported than, say, using a Python API inside a .Net application.

tldr: Git is still faster overall, but those who want to extend a dvcs choose Mercurial for its API that exposes the data structures in a stable manner, albeit in Python, which limits use cases.

Despite conflicts and power games one might follow on the news, the world economy is totally global. This also includes supplies coming from armed conflict or politically volatile regions.

If you completely disassemble your Detroit-branded car, you will be surprised how many countries supplied parts for it, from all across the world, including Europe, Japan, China, etc.

This isn't advertised as much, but for some components, Japan is the world leader due to quality, despite the situation of their overall economy. Just like Germany supplies many components or instruments you won't read about on news sites. Fifty percent of the world's surgical equipment is manufactured in Tuttlingen (Germany). Over 400 medical supply companies are situated there. It's like the Shenzhen of medical tools in terms of concentration and market penetration. It's even more interesting in the context of what you wrote, if you look at where the rest of the surgical supplies come from.

Therefore, given that you trust a car which consists of many components built outside the US, and your surgeon probably operates on you with tools made in Germany, everyone is already trusting the global economy and "evil countries" with their lives.

Now, to answer your question about email providers, I'm with StavrosK here that using a Russian or Chinese service is safer if you're a European or US resident because of data access laws. The US govt is still fighting Microsoft to provide access under US laws to data stored in European data centers, now in revision after initial defeat. You should still encrypt or skip email for sensitive communication, but the ease with which the government that can imprison you can access your emails is proportionally more difficult the farther away from your region and its close allies you get.

EDIT: My impression is that the global economy began in earnest with the great European resource grab (or robbery if you like) via sea shipping across the globe, and it only got more global with time and stayed mostly on sea.

Right. Unfortunately, Rotate and Repave are not common practice, just like periodically restoring backups isn't.

> I still think the exfiltration threat is the worst. Any secret injected into the environment of any tested codebase is vulnerable -- especially if your logs are public.

Fair point, though instead of worrying about that, I think the real solution is to have test-only keys and also make sure logs can be shared without fear of leaking data.

That CircleCI post seems to talk about different issues than I see when I think safety of random CI jobs.

It's a non-trivial problem to solve, especially with caching of artifacts involved. You'd probably want to run a sandbox inside a vm and secure the vm itself first, while having only ephemeral storage attached. Barring a container escape via just read/write/execve allowed inside the sandbox, which could probably also used to escape the surrounding vm, there isn't much you can do if you support running random stuff in a CI job.

Actually, maybe CI needs to be limited to tools that can run on something like ZeroVM.

Limiting persistent state and spinning up machines (vm or bare metal) for each job, while having no permanently active job runners, sounds like another defense to consider.

That said, I very much doubt any of the CI services goes to such great lengths, given the limitations involved.

What would be the course of action for an opensource project to set up a CI worker there (ideally per-commit on X branches, not periodic) such that it could be integrated in a pre-merge check? I'm not bound to Gitlab CI runners, but it's the first thing that came to mind given the popularity of github and gitlab.

Since Zaius also seems to have fully open firmware for most (all, including USB controller?) pieces, it would be nice to get something like a <3k$ workstation. I would say Raptor Talos, but they seem to have their hands full with the POWER8 workstation and I wouldn't want them to divert resources to a P8 -> P9 move and further delay their project.

If Rackspace, given their major support for various opensource projects, were to provide POWER9 runners for, say, Gitlab CI, this could be a major help in porting software. Or, they could, like IBM provide SSH access to interested projects. But the CI part is important to ensure there's no regression, and given the scarce availability of POWER9 (or even POWER8) hardware to the general public, let alone opensource developers, Gitlab CI integration sounds like the more practical service.

Right, that's why I wrote "_a_ linux distro", not "some linux distros". I'm sorry for not making that clearer.

A not-yet-fully-upstreamed branch maintained by the linux foundation can, yes. But just like FreeBSD has to make an exception to build certain packages with gcc, the kernel can be exclusively built with gcc for the time being. If you're not using musl libc, I guess glibc might also require gcc but that's an unsurprising coupling, likely due to gcc C extensions in use.

The important points are that such a distro will quickly improve the situation of clang and libc++ compatibility across the board and exercise the alternative toolchain a lot more. In fact, there isn't much incompatible code out there, and it's been fixed mostly due to efforts of Debian, FreeBSD and of course Apple and Bitrig and Gentoo. FreeBSD is the leading force behind making lld a viable alternative to binutils ld and so far ThinLTO (which works with binutils, to be clear) is exclusive to llvm, so there's that.

https://aur.archlinux.org/packages/llvmlinux-git/

http://llvm.linuxfoundation.org/index.php/Main_Page

I'm glad that VoidLinux isn't anymore the only distro in town that's switched to LibreSSL. And with Docker defaulting to Alpine, more OpenSSL/LibreSSL compatibility fixes will trickle into upstream projects. This is good news.

EDIT: Next, I predict a linux distro will, after having switched to musl, also support llvm/compiler-rt/libunwind/libc++ as base toolchain instead of gcc/libgcc/libstdc++

Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?

Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison do not work properly?

Can you rewrite history in those?

> Why aren't we using it for everything yet?

There are some features which are so far exclusive to FreeBSD but go under the radar of the wider community of developers. In addition to CloudABI, Capsicum is another one, which, while not perfect, seems largely ignored/unused/reinvented outside FreeBSD. The LLVM-based base system is another one, which is partially matched by Bitrig. FreeBSD needs to market their features better, like pledge(2), libressl or systemd or docker are doing it.

Kees Cook and others have been porting or reimplementing features exclusive to grsec in upstream linux.

https://outflux.net/blog/archives/2016/09/26/security-things...

https://outflux.net/blog/archives/2016/09/27/security-things...

https://outflux.net/blog/archives/2016/09/28/security-things...

https://outflux.net/blog/archives/2016/09/30/security-things...

https://outflux.net/blog/archives/2016/10/03/security-things...

https://outflux.net/blog/archives/2016/10/04/security-things...

And naturally some stuff is exclusive to linux upstream, though grsec will benefit from those automatically if they deem it good enough.

I still have hope some or all HardendedBSD features might get ported or reimplemented in FreeBSD 12. Too much low hanging fruit, and now that linux has been steadily closing the gap to grsec, the competition in mainstream kernel branches is on.

> https://svnweb.freebsd.org/base?view=revision&revision=30090....

Is this a unique feature or how is this handled on illumos or Solaris?

Yeah, git doesn't restrict you in that regard and supports both workflows, which may differ from project to project. Mercurial has a nice improved version of this, where it's safe to rewrite locally but you're not allowed to rewrite public history. I think that's a smart compromise, although if the project you're working on has the concept of patch queues, like the linux kernel and others, then mutable history to maintain patch queues is a feature, which in fact had been supported by a few extensions before the new mercurial rebase implementation landed.

Bots can still learn with that reCAPTCHA behavior. We're basically providing free labor to Google and they're making is love Solvemedia and other captcha services for providing something that actually doesn't turn into a minute long puzzle exercise, when all I wanted to do was post a comment on a site.

If I load test/03.md with it, the process consumes around 19MB. Is that expected and normal for displaying ansi text?

It's not that kind of hang.

> systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux.

Agreed, but I hope that systemd starts focusing on stability and fixing the regressions they've introduced compared to sysvinit. systemd machines are the only instances of Linux since 1995 where I've had intermittent random hangups during startup and sometimes shutdown. I never thought about startup and shutdown before systemd. It just worked, and if there was a problem, it was reproduceable and a real error (usually configuration), not systemd random fault. I don't use CentOS, maybe their systemd integration is actually reliable.

> no one still has come with a golden response

SMF or Nosh

That's brilliant, and I wouldn't expect anything less from the BBC. They are technically competent and innovated in the broadcasting space, like a few other networks did/do. It surely helped that the BBC have (had?) an R&D department.