Kinda late on UNIX bashing bandwagon :)

Also, Windows owes more of it’s legacy to VMS.

What are the odds that VS Code doesn’t respect telemetry settings in nightly builds? I mean, the entire point of nightly builds is for testing, of which telemetry is potentially of particular value. If I wanted to minimise my exposure to telemetry, I wouldn’t be running nightly test builds in the first place, precisely because I’d expect it might not respect the normal telemetry settings (among several other reasons).

EDIT: I vaguely recall a similar post re: someone being outraged at Mozilla collecting telemetry from their Nightly builds which are published precisely for testing.

Just as important as Firefox being a distinct product is that it uses its own rendering engine. There are only three major browser rendering engines: Trident/WhateverTheyCallTheEdgeEngine (Microsoft), WebKit/Blink (Chrome, Chromium, Safari, Opera, most one-off browsers like Web in GNOME, WebPositive on Haiku, etc), and Gecko/Servo (Firefox).

It’s not enough to have a million different browsers if they’re all using the same rendering engine. We need variety in implementations on that front too…

I am surprised there are no major websites down today. This seems pretty trivial to abuse, and has a good chance of working with other certificate authorities.

I use a custom bash script. What is the advantage of Stow? The advantage of my solution is that it does require to install stow. I use this on machines, where I have no root/sudo access.

For the Windows admins (hello? Bueller?):

• Sysinternals Suite
  Utterly essential. Every Windows system I admin has these.
• Message Analyzer
  For packet capture & network diagnostics. Wireshark is also excellent. In general, I find MA has better protocol decoders for Microsoft specific stuff while Wireshark has much broader protocol support.
• Debugging Tools for Windows
  Installed on an as needed basis as for crash dump analysis just perform the analysis on the client. There are some scenarios though where having them on the affected system is either required or just makes life easier. Included with the Windows SDK versus a discrete download, but the download optionally includes MSI redistributables.
• Windows Performance Toolkit
  Installed as needed like the above and available via the Windows SDK with optional redistributables. If you’re diagnosing performance problems on a system, especially at the OS level, these are frequently invaluable. The actual analysis can be done on the client.

For all of the above except Message Analyzer you really want to configure symbols. The Debugging Tools effectively need them to be useful in most scenarios, while the WPT tools and many Sysinternals tools are much more useful with them (e.g. viewing a call stack for a thread in Process Explorer).

Nice article. In a similar vein and possibly helpful to others, I made this a while ago while dealing with bash quirks: bash-script-template. Idea was to have a sane starting point for creating more complex scripts that needed to be somewhat durable, with sane scripting defaults.

It provides several functions I’d often find myself effectively writing whenever I started a new script, hence the creation of a template I can simply source, or edit if I want it to be entirely self-contained. Might be useful to others, and constructive criticism is always welcome!

It’s such an incredible shame that the video is littered with poorly drawn ejaculated penises (yes, really) and using such clever usernames as “cuntballs” (again, yes, really). The presenter’s voice gives me the definite impression of an adult male and not a 12 year old.

It’s a shame as the actual content is both interesting as a trip down memory lane and a testament to the truly impressive effort Microsoft puts in to backwards compatibility. The fact it’s possible to run 16-bit Windows 2.0 apps (1987!) on 32-bit Windows 10 is truly remarkable. But it’s hard to have a mature discussion or casually show it to anyone with the pervasive immaturity throughout.

I do enjoy the “increased error rates” terminology. It’s the IT equivalent of political doublespeak. It’s not an outage, we’re just experiencing increased error rates of around 100%! The AWS status page might as well just be “ALL IS FINE MOVE ALONG” in 72 pt Comic Sans MS.

Remember folks, The Cloud is just somebody else’s computer. :)

Not to be too much of a tinfoil or anything, but if the relevant 3-letter agencies knew about this before disclosure, it must have been an absolute gold-mine. Tinfoil aside, I’d like to see a list of affected sites, even if limited to a Top 100, so that a judgement call can be made by users as to if they want to update their credentials.

How confident are you that you that you don’t use any services that are backed by CloudFlare, were afflicted, and sensitive data relevant to your usage wasn’t exposed? I’m not.

I recognise this could be considered a duplicate of this submission (sorry calvin!) but have posted it regardless as I think the blog post is both interesting and adds more context. It’s not seemingly linked to from the repository itself.

It’s so disappointing seeing these bugs as at least for me it has an enormous impact on my confidence in open-source encryption software to safeguard my data. Bruce Schneier remarked way back in 1999 that “In the cryptography world, we consider open source necessary for good security.” He’s right, but at the same time, this bug and many before it is amateur stuff. I mean, look at this code excerpt:

// paranoid default setup mode
//write (fd[1], "y\n", 2);
//write (fd[1], "y\n", 2);
write (fd[1], "p\n", 2);
write (fd[1], password, strlen (password));
write (fd[1], "\n", 1);

Coupled with the earlier execve call to an interactive command-line utility there is just so much wrong with this. I could be wrong, but I just don’t see these sort of fundamental, basic mistakes being made in major proprietary cryptography software? I’m not sure what the conclusion here is, but it seems there’s a real lack of serious code review, adherence to well defined coding standards, periodic code audits, etc… to avoid this stuff from ever making it into a stable release. OpenBSD is the only open-source security project I can think of that gets this stuff right. They’ll still make mistakes, but I at least have confidence they’re working hard to avoid them.

Likely controversially, I’d argue there’s a broader issue of applying the Unix philosophy of individual utilities that perform a few well-defined functions, and often shell scripts binding them together, to security software. It’s inherently brittle, with each additional independent binary or script making the overall system more fragile. A monolithic approach to ensure the system has a minimum of external dependencies, relies exclusively on stable, ideally low-level APIs that can be reasonably trusted to be correctly implemented, makes sense. It’s just too damn hard to manage a web of disparate utilities, scripts and dependencies with a guarantee they will work together exactly as intended for tasks which are security critical.

So it’s definitely a genuine issue, but it’s in my view nowhere near as big a deal as the author or the comments on many other sites covering it are making it out to be. Definitely a long-way off from an all-caps “SEVERE”; I reserve those for unauthenticated RCE and wormable exploits, or similar mass carnage variety flaws (e.g. Heartbleed).

The main issue he points out is you can press Shift + F10 and get a Command Prompt during the install/upgrade process, which has been true dating back to at least 2006 with Windows Vista. So not exactly new, and it’s not a “CRAZY bug”, it’s by design, as it’s frequently incredibly useful. When you’re running in a minimal Windows environment (WinPE), if something goes wrong in the early setup, it’s going to be one of the few and possibly only options available to you to figure out what’s going wrong. It’s effectively the Windows equivalent of swapping to a different tty during a Linux or BSD setup. More importantly, it can be disabled, and this isn’t hard to do for enterprise deployment scenarios using tools like SCCM (System Center Configuration Manager). In fact, for memory the checkbox that enables it in SCCM is marked “Test mode only”. But if you’re in an unmanaged environment, you probably don’t want to have to hack your setup media to be able to access basic troubleshooting tools.

As for the BitLocker point, this is again not a bug but documented behaviour. The issue is that BitLocker doesn’t just encrypt your system and ask for a password at boot, but verifies the execution chain and boot environment up to the point where it prompts for that password. Upgrading the OS means that many of those binaries that are part of that trust chain are going to change. Disabling BitLocker protectors keeps everything encrypted but with a null key, so the binaries can be updated without requiring a BitLocker recovery, then the protectors can be re-enabled once the upgrade is complete. It definitely should be improved, as it feels like a bit of a kludge, but it’s a tricky problem to solve elegantly, particularly with respect to unattended upgrades. It doesn’t cause me to lose sleep, as the only attack scenario this is useful in again requires physical access to a system during an OS upgrade, and while I’d like this process handled better, it’s pretty low on my threat assessment.

In short, both of these issues could probably do with more awareness, but they’re really only pertinent I think to enterprise scenarios, and the people who know what they’re doing are aware of both of these issues, and mitigate them if it’s worth the effort.

We find you guilty of ideological impurity.

Not a fun read, and as the author acknowledges, they’re rightly ashamed of their part in the development of the site. That said, I applaud him for taking the time to write about it. It takes courage to publicly document your professional failings, and much more so when they venture into the deeply unethical. Hopefully, other developers, young and old, will read tales like this and apply a greater deal of introspection on such questionable tasks than they may otherwise have done.

So glad I started my Sunday morning by reading this. I often feel I work in an industry that’s particularly brutal w.r.t. its treatment of mistakes or even those simply lacking in experience. It’s nice to see a post highlighting an incredibly reasonable and productive response, instead of the abuse and mockery I often see.

Semi-related to this: In the limited amount I’ve been exposed to containers at my work, the suggested practice is to run everything in the container as root because you’re just going to run one thing in your container anyways, so giving it access to everything is just fine.

Does anyone with more experience have an opinion on this?

Incredibly disappointing. Irrespective of the consequences they suffer, and I think Mozilla’s proposal of a year-long ban on new certificates is both reasonably punitive without being disproportionate, I’ll be moving all the networks I manage off of StartCom. Which is a shame, as I did like their service, but integrity and security comes first, and they’ve failed.

On a related note, across my half-dozen StartCom accounts, I have not received any notification of a change of business ownership at any point. That may not be legally required, but I’d certainly suggest it’s ethically important that customers are apprised of such a change, particularly given the business operates in the security industry.

A problem with stow is that, very often, I only want the files to be symlinked, with the directories created rather than symlinked. Otherwise, too many applications have a habit of writing to temporary and log files within the config directories, and these files appear inside the dotfile repository, which I do not want.

For example, my configuration file for foo is .foo/config. Unfortunately, foo will also write a file .foo/history. If I create a foo/.foo/config directory in my dotfile repo, and stow it, the ~/.foo is made into a symlink to the directory foo/.foo. So, the file ~/.foo/history actually appears under foo/.foo/log

Stow unfortunately does not support making directories (it makes directories only if the directory is shared between another application). I currently get by with some scripting on top of stow, but it would have been nice if this could have been implemented.