slrz

Still no reason to force-push this onto users. If you are going to set up and maintain SharePoint servers and what not, you can surely change that browser preference yourselves, no?

> upgrades from eg CentOS 6 to 7 are unsupported.

Upgrades from EL7 to EL8 are supported, though.

For Container Linux/Fedora CoreOS, in-place updates don't make much sense. Those are intended as immutable OS images. They get their configuration from a remote source specified on the kernel command line.

The migration work is dealing with changes in the configuration language.

Replication covers durability (and availability) in face of system or media failure but does nothing whatsoever against software bugs or human error.

> I think so, this is what Google does with Android, but IANAL.

Google doesn't ship any proprietary kernel code as part of Android. It's all GPL and available to the public at large.

Some Android kernel parts are maintained separately from the kernel.org mainline tree (i.e. they maintain a fork) but that's not a legal issue (and they're getting better at it anyway).

You can manipulate boot settings using BMC commands. No need to mess with Grub or the running system. Instead, tell the system to boot up from an emulated USB drive (image can be attached from some remote server, often including your web browser).

Now wait for the machine to get rebooted (or do it yourself using the BMC, e.g. 'racadm serveraction powercycle' for Dell/iDRAC machines).

Even SecureBoot won't help as you can just turn it off using the BMC.

See here for a bunch of examples for Dell machines using the BMC's HTTP API:

https://github.com/dell/iDRAC-Redfish-Scripting/tree/master/...

As long as the allocation size is bounded (due to alloca/VLAs lacking any mechanism to signal allocation failure), what's the problem with that?

Just set up your code as a boot-once config and wait for the owner to reboot their machine. Make your code end by booting the installed OS (or even by just rebooting again, most people will just curse about the damn slow server boot process).

A lot of regulations are actually a lot more reasonable than one might think and refrain from mandating any specific technical measures.

Yet, people always seem to point to regulations to justify all kinds of snake oil salesmen garbage, even if obviously unfit to fulfill the stated objective.

Change monitoring with inotify is going to hit limits quickly.

I recently wanted to take a look at VSCode and it immediately shat itself over the maximum number of inotify watches being too low (the kernel I'm running restricts this to 8k for non-root users).

I then bumped the limit to the max (512k, I think, or about 7 copies of linux.git)…still no luck. Now imagine you have a Google-scale number of files.

Libbsd includes it.

https://libbsd.freedesktop.org/

No, of course not.

> Indeed, for a while, the Go compiler was written in this special dialect of C, and so building Go required building a C compiler (!) that could compile this custom dialect of C, and using that to compile the Go compiler [2].

I don't think that's true. The build process used GCC to compile the Go and C compilers. The Plan-9-derived C compiler was used for compiling those parts of the runtime that were written in C back then and were supposed to follow the conventions of Go program code.

As you can tell from Inferno (or even Plan 9 from userspace), GCC can compile the Plan 9 C dialect, given the right options.

Software licenses don't really matter if you implement the Go language spec with your own code.

It's only when you want to share code with other implementations that software licensing enters the picture. Gccgo manages to share most of the standard library with the golang.org implementation, so they appear to have the licensing figured out.

Most such mail tends to be not just HTML but rather multipart/alternative with an HTML but also a text/plain part.

Luckily, HTML only (or its bastard cousin: including a text/plain part that is horribly broken or just says "please enable HTML viewing") isn't seen that often around here.

The vulnerability can often be discerned from the patch. Burying it amidst lots of unrelated bogus changes and not calling out its security relevance is going to annoy your users.

Thanks for the explanation. It's just a bit frustrating to not get any reply for weeks when your license is going to expire in...looking at calendar...3 days from now.

Any ETA on when renewals will be possible again?

Next up on my wishlist: GitLab battling the scalability of their license renewal process for academic users.

Shouldn't mktemp -d -t name.XXXXXX do it? Possibly in combination with setting TMPDIR if you want to create the directory somewhere else than within the default temp directory.

Works with GNU mktemp, the old BSD variant on macOS and also Busybox. Current Android uses Toybox, I think? Its mktemp implementation looks like it takes the same flags as Busybox mktemp.

https://landley.net/toybox/help.html#mktemp

You can invoke mktemp(1) in ways that work across most contemporary systems. At least if you don't care that the resulting names are going to look a bit weird (have lots of XXXXXX in them due to name prefix vs. template differences among implementations).

The normal support period for a RHEL release is 10 years. RHEL8 came out earlier this year.

Which breaking changes do you mean? Got an issue link?

Pretty sure that it wasn't Google doing the suing. I remember it being Opera. Did Chrome even exist back then?

Ansible does require that some flavour of Python is available on the target hosts. Without a Python interpreter, you're basically restricted to using the raw module (which, of course, you may use to bootstrap Python by invoking the package manager).

Still, I guess most people don't bother with that and just assume the presence of Python (at least on Linux, the bootstrap-using-raw approach is already required on FreeBSD and others).

https://docs.ansible.com/ansible/latest/modules/raw_module.h...

Sure, but not across a security boundary.

Being able to override some library function such that running my text editor does $BADTHING isn't very interesting from a security perspective: if I have the capability to do that, I could also just run a program that does $BADTHING directly. Why bother with additional contortions to involve the text editor?

I'd guess most of them, if you actually consider the whole world.

Probably not enough to matter, if you are only looking at the UK.

Of course, as long as you're one of the parties involved in the SMTP communication.

The problem is that even though you're trivially able to detect that TLS is not in use, the vast majority of mail providers won't act on that knowledge by refusing to send mail unencrypted (except maybe for some hosts explicitly whitelisted for that approach).

Why? Too many broken TLS setups, historically. Might be better now, I vaguely remember some push towards that from the big providers.

Or just stuff them into the DNS in the form of SSHFP records, where the OpenSSH client will read it from.

This assumes authenticated DNS data, of course. Not at all a given today, sadly.

OTOH, neither is the ARM ISA. Yet, once you try to bring a non-ARM Android device to the masses, you will soon discover the rule of Hyrum's Law.

How is it even remotely hard to not use timesyncd or resolved? Just don't enable them (or disable them, if your distro ships them enabled by default) and use your preferred alternatives instead.

The linked post notes that, even on a default Windows install, you already have a sizable stack of filter drivers active. Not sure whether that only applies to the C: volume or to other ones as well.