Me and Claude have been working on zfetch (https://github.com/roobie/zfetch), which is a single static binary that fetches URLs over HTTPS with strict security defaults. For many applications, it should be able to replace curl in restricted environments where you need a small, auditable tool with no runtime dependencies.
It should also be usable as a Zig library for embedding HTTP(S) fetches in your own programs.
I've been thinking about knowledge in agentic systems lately. Your comment made me put up my draft of the `knowledge-repo` concept: https://github.com/roobie/rfc/blob/main/knowledge-repo/READM... - nothing special really, but I think the concept could be really powerful.
Mutation testing is a new concept for me, and even though one has to manage the performance aspects of it, it seems like a good idea to at least apply to selected functions in one's codebase, in order to find bugs.
All the open source developers/publishers here should get together and pitch in to get one long lasting certificate to sign all of their respective binaries (of course, really important that they vet each other's code, so has to be open source)
Edit: typo.
AppGet or Chocolatey are already on the system and (I think) could unblock binaries from SmartScreen. AFAIK user level programs could run with zero prompts.
The FreeBSD Security Team was notified of the issue in late December
and received a briefing under NDA with the original embargo date of
January 9th. Since we received relatively late notice of the issue, our
ability to provide fixes is delayed.
Meltdown (CVE-2017-5754)
~~~~~~~~~~~~~~~~~~~~~~~~
In terms of priority, the first step is to mitigate against the Meltdown
attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for
this is ongoing, but due to the relatively large changes needed, this is
going to take a little while. We are currently targeting patches for
amd64 being dev complete this week with testing probably running into
next week. From there, we hope to give it a short bake time before
pushing it into the 11.1-RELEASE branch. Additional work will be
required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE.
The code will be selectable via a tunable which will automatically turn
on for modern Intel processors and off for AMD processors (since they
are reportedly not vulnerable). Since the fix for Meltdown does incur a
performance hit for any transition between user space and kernel space,
this could be rather impactful depending on the workload. As such, the
tunable can also be overridden by the end-user if they are willing to
accept the risk.
Initial work can be tracked at https://reviews.freebsd.org/D13797.
Please note this is a work in progress and some stuff is likely to be
broken.
Spectre (CVE-2017-5753 and CVE-2017-5715)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When it comes to the Spectre vulnerabilities, it is much harder to sort
these out. Variant 1 (CVE-2017-5753) is going to require some static
analysis to determine vulnerable use cases that will require barriers to
stop speculation from disclosing information it shouldn't. While we
haven't done the analysis to determine where we are vulnerable, the
number of cases here are supposed to be pretty small. Apparently there
have been some Coverity rules developed to help look for these, but we
are still evaluating what can be done here.
The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier
as it affects both normal processes and bhyve. There is a proposed patch
for LLVM (https://reviews.llvm.org/D41723) that introduces a concept
called 'retpoline' which mitigates this issue. We are likely to pull
this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately,
the currently supported FreeBSD releases are using older versions of
LLVM for which we are not sure the LLVM project will produce patches. We
will be looking at the feasibility to backport these patches to these
earlier versions.
There are CPU microcode fixes coming out when in concert with OS changes
would also help, but that's a bit down the road at the moment.
If anything significantly changes I will make additional posts to
clarify as the information becomes available.
Best regards,
Gordon Tetlow
with security-officer hat on
> FreeBSD Security Team was notified of the issue in late December
Anyone else thinks this was kind of a slap in the face to the smaller communities and companies or is it just me?
They were notified in late December, right before the holidays, so that's basically only 2-3 weeks of work. Obviously nobody _had_ to notify anyone, could have just released it right away, so it was a professional courtesy, but why not extend it to a few more projects?
Before anyone says "but OpenBSD broke an embargo before", this is a different project and besides having BSD in the name don't see why they were excluded.
FreeBSD secteam was only notified — at all — because Netflix (a big FreeBSD user) requested it of Intel. It was a big slap in the face to smaller communities by Intel.
FreeBSD isn't two people in a garage, it's a foundational part of the internet developed by professionals who can be counted upon to do the right thing.
Intel and Google don't have a leg to stand on: I'm super glad they found the bugs, but their disclosure has been nothing but a shitshow.
I’m not arguing for or against anyone in particular getting notice. I’m just pointing out why they’d limit it in principle. You have the draw the line somewhere.
>>> Before anyone says "but OpenBSD broke an embargo before", this is a different project and besides having BSD in the name don't see why they were excluded.
AFAIK they all share the same brand name BSD and they are all closely affiliated.
> AFAIK they all share the same brand name BSD and they are all closely affiliated.
This is a gross falsehood.
They all variously diverged from a parent project, called BSD, in the 90s. Since then they are wholly independent. Because of the common license and heritage, code sharing is often easy and legally unrestricted. But their leaders, policies, and philosophies are very distinct.
It should also be usable as a Zig library for embedding HTTP(S) fetches in your own programs.
Vendors and links BoringSSL