I moved from VMWare Workstation to using Linux's libvirt and its native virtualization facilitiesearlier this year, and I've been happy with that move although I still would like to be able to takegood snapshots of UEFI based virtual machines. Over time I've woundup with a setup that I'm happy with for the work that I do, one that'ssimilar but not quite the same as my VMWare setup.

I have two groups of VMs. One group is Fedora VMs (and one

Our network design carries with it theimplicit assumption that all of our machines (and all machines runby other people ) are within our networkperimeter, so we can safely expose dangerous services to them, likean unauthenticated SMTP 'smarthost' and a central syslog server . In the beginning this was completely true, butover time we've acquired a few machines that are outside our networkperimeter (and if there is cloud in our future, we'll get more).We'd rather like for these

Every so often I want to know what Ubuntu release a particularmachine is running, and when I do I've become accustomed to using' lsb_release -r '' to get this information. Sometimes I alsowant to remember which version of Fedora I'm currently running onmy desktops (it changes much more often); depending on my memoryat the moment I look at /etc/fedora-release, or /etc/redhat-release,or remember that I actually installed lsb_release

One of the potential concerns in the Certificate Transparency ecosystem is that a CT Logcould be compromised. But what can an attacker who's in control ofa CT log actually do? That's a question both of how CT logs workin general and of the current uses that people make of them, bothclients (ie browsers) and Certificate Authorities. So here's whatI can see about that, based partly on the TLS client's view ofCT logs . To start with, let'

I generally haven't had particularly positive experiences with xdg-desktop-portal on my custom desktop . At best itappears to do nothing; at worst, it's been a core element inmysterious problems . Havingxdg-desktop-portal installed effectively isn't optional these dayson Fedora (if you try to deinstall it, it takes out a bunch of otherthings, although in Fedora 36 there's fewer things than I expected).However, letting the program and its whole portal environment

Certificate Transparency involves all Certificate Authorities logging newly issued TLScertificates in various public 'CT Logs', and then generally addingsome Signed Certificate Timestamps (SCTs) to the issued TLScertificate to demonstrate that they've done this. Interested partiescan then watch the CT logs to look for bad or mis-issued TLScertificates, and TLS clients can take steps to check that TLScertificates are in the logs .Famously, Firefox currently does not 'support' CertificateTransparency .But what does this actually mean?

The "

TLS Certificate Transparency is a system where browser vendors require TLS Certificate Authoritiesto publish information about all of their TLS certificates incryptographically validated logs, which are generally run by thirdparties (see also Wikipedia ). Thisraises the question of how clients (generally browsers) interactwith Certificate Transparency. As far as I can tell, it dependson how thorough a client wants to be about verifying that a TLScertificate really is in a given CT log.

The current version of Certificate Transparency is described in RFC 916

A while back, I tweeted something that has astory attached:

A person with a single machine room temperature sensor knows the roomtemperature (where the sensor is). A person with three temperaturesensors lined up next to each knows only uncertainty (and has a wishfor a carefully calibrated and trustworthy thermometer).

If you set out to get some inexpensive USB temperature sensors tosupplement a more well developed and expensive temperature sensorsystem , it's quite likelythat you'll wind up with the PCsensor TEMPer2

I recently read ZFS sync/async + ZIL/SLOG, explained ( via ), which remindedme that there's a clever but unsafe seeming thing that ZFS doeshere, that's actually safe because of how ZFS works. Today, I'mgoing to talk about why ZFS's "in-place" direct writes to mainstorage for large synchronous writes are safe, despite that perhapssounding dangerous.

ZFS periodically flushes writes to disk as part of a ZFS transactiongroup ; these days a transaction