u/schlenk

Thats not bugs. Thats documented and Windows applications can call APIs to reserve their own ports. It might be surprising for plain BSD socket apps.

https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-createpersistenttcpportreservation

Thats just a totally different ressource management model to what Linux does.

WSL is actually quite nice, if you typically run Windows and just need some Linux apps present. Much easier than setting up dual boot, complex VMs or other stuff.

Software Development on Linux is only easier for ecosystems that are Linux nativ. But as that comprises pretty huge parts of development these days (web, JS, AI, python, k8s etc) the argument looks plausible.

But for .NET and C# or C++ with Visual Studio, Windows works just fine as a dev platform. Even some of the tooling is actually fairly good (e.g. WPA/WPR and the system tracing stuff works pretty good). Its just super clumsy and slow for tools that expect Windows is Linux or POSIX compliant. For example, process creation and stat() calls are pretty slow on Windows, as Windows uses Threads for a lot of the tasks where Linux creates processes, and the stat and i/o parts are typically hidden behind IO completion ports, something that Linux only gained with io_uring.

At least they didn't use TeV/s or something.

Just finished implementing the notification stuff properly. Its not that hard for a company to be compliant if you actually spend the time reading the available docs. But some of the regulation (especially OSS) is still a bit weird. And it is visible from the pre-AI age, so some ideas look strange from todays viewpoint.

It really depends where you start from. If your company has no good processes to start from, your in for quite the change. But if you already have some kind of secure development lifecycle going and a few other things, its not that bad, actually.

The EU commisions guidance document (from 27. july) is really a must read to set things into perspectives. It finally adds useful examples and context. The regulation can be read in a terribly broad way, but the guidance adds a lot of common sense to it again, shooting down most of the absurdly broad interpretations.

The EU handling of the SRP notification platform rollout was a bit clumsy. No test servers. No API. No preregistration of accounts. Very scarce documentation and a barely functional platform that fails to support even the mandatory fields of the regulation at the start. Lets see how it holds up under load.

For OSS things are still way too blurry, but for companies in the EU it is manageable. Just another certification exercise basically.

Sounds like someone was anticipating the next rewrite in language XYZ.

Reminds a bit of Tcl's starkits/starpacks with their transactional database, internal VFS and so on, where you could query and update the running program, just layed lower onto the OS layer with binfmt_misc.

With some extra tinkering, the ELF he builds could probably also be multi-arch, like starkits. Just add an arch column somewhere.

Try Cool VL Viewer, its trivial to compile it yourself (or use the provided binaries). https://sldev.pages-perso.free.fr/ It is foremost done on Linux and works pretty well, if you can stand the dated V1 UI layout and style. The internals are shiny and new, just the exterior and comfort features may lack a bit compared to Firestorm.

Upvar allows you to bind a name to a different scope of your callstack.

e.g. kind of import local variables that are available in a different call frame. Thats a very powerful primitive for writing your own control structures and advanced metaprogramming, but can lead tot total spaghetti code when not used skillfully.

We solved this by adding a generic secrets layer to our python runtime system.

Its pluggable and offers a secrets tree with mountable wallets that override parts of the tree. So you can mount environment variables, K8s secrets, encrypted files with unlock secrets stashed into different files, some wallet that produces access_tokens for Microsoft Graph on demand and so on.

The developers just see a unified secrets infrastructure and just do store.resolve(secrets_path) anywhere they need a secret. The simply do not need to think about it.

And the admin/devops/local developer teams mount the appropriate wallets for the necessary security level. Like plain files for local dev or K8s secrets when running in a cluster or some Vault style stuff when needed.

Keeps it nicely agnostic and multi cloud/on-prem capable.

Its a bit like Secretsspec actually, but older (wrote it like 2020 or so). Maybe i should write a backend to from/to secretsspec.

Neither should cybersecurity, unfortunately.

Neither should payed for cybersecurity.

Don't plan with other peoples unpaid time.

Define feasible and shopping addiction.

If you expect to go to some event sale faire and simply grab 100% of all Fatpacks that match your body there every month, it might work if you still use Slink Hourglass (then it is close to zero expenditure...), but for e.g. Reborn it would be thousands of L$.

With some skill in content creation for the markteplace, you may get some lowish income. Higher income usually needs so much investment in time and skill, that it is in no way competitive to spending the time for some RL work and just buying L$ from RL money, unless your local economy is poor in some way.

So if your skills are worth decent RL $ in your place of living, you are better off using them in RL and just buying L$. But if you just do some hobby things because you are curious and good enough to make something halfway interesting, you can put it on the Marketplace and get some L$ from time to time. Does help for mild shopping addiction but not for severe ones.

My favourite nonsense starts when you have mandatory pre-commit checkers that are too dumb to understand the logic there and flag this as "always true, remove".

Depends.

Some sites have no alternative routes to recovery. So if you loose your MFA and have no OTP emergency codes, your account is irrecoverably dead. Those must have emergency codes as a fallback (often they require a mobile phone number as a secondary fallback too).

But if you have alternative reset routes, e.g. in a company environment or when you have payment info identifying the customer, you do not need to provide "self service recovery" options like backup codes.

For TOTP it is a bit silly to have backup codes anyway, as you can just write down the TOTP seed number to enroll a second authenticator as needed. So you already have a backup code, you just need to notice it.

LL may have other means to establish identity, at least for people with payment info on file. So recovery from a MFA loss incident is not automatically dramatic, just inconvenient.

Sure, in DOS / Win 3.11 times it worked by default. Only stuff like Windows DOS Consoles would need some help to be vulnerable.

There usually is no way to write actual executable code to the log file. But sometimes the attack is against the program used to look at the logfile instead.

I do not know if it works for SL logfiles, but for text logfiles a prank was to embed ANSI sequences that would redefine your keyboard sequence and bind a RETURN to "format c:/ /yes". That worked in DOS consoles that loaded ansi.sys. Similar attacks pop up from time to time for different editors and log viewers. Its rare though.

It's not the name, but a so called 'signature' (=a specific pattern of bytes typical for the virus), but basically yes, like that.

There is even a special text string, the EICAR test virus (a harmless test string for testing virus scanners), that triggers this kind of thing.

The article sounds like the point is to help debugging and reporting bugs.

Just look at all the upstream OSS maintainers that complain about bug reports against their packages that are actually against distro specific version.

So, yes they tend to have versions, but many users tend to ignore the suffixes or distro details reporting bugs.

It's a hard problem.

Basically all the company world has tried do it with SBOMs for compliance reasons soonish, but versions are hard.

The point is, what are you actually trying to do with the version anyway? The only thing a version hints is showing if two programs (that you acquired from the same channel) are identical. And not even that, if someone tampered with the download.

You don't want a version alone. You want stuff like typical SBOM standards like OWASP CycloneDX or Linux Foundation SPDX allow to describe a component:

• Where did you get it?
• Where where the sources for it?
• Where is the support documentation for it?
• Where is the homepage of the manufacturer, importer, whatever...?
• Where is the bug tracker?
• What exact hash did the component have?
• What was the download URL?
• How was it built?

A simple version number doesn't tell you all that much, unless you have a lot of context to fill in the gaps.

For example, take PostgreSQL and compare the patchsets for Debian, OpenSuse or the Windows distribution for a given short "version number". Can vary wildly if you just use the naked version without distro qualifier.

Automated CI/CD pipelines and package creep.

If you push all your commits to a package repo nearly continously, you have no buffer zone for sanity checks.

When doing manual package releases, you had a least someone taking a look at the changelog/changes and spotting obvious badness.

But that doesn't scale, as packages get smaller and smaller (with ever more ratio of boilerplate & CI config to actual code) and you have a proliferation of packages due to package managers.

Once you go over about 20 dependencies (and transitive dependencies) most people stop to look closer. They just accept any updated version, because reviews would be too expensive. Even if most updates just fix totally unimportant stuff (e.g. for Python many updates are just fixing CI breakage due to tool evolutions, e.g. setuptools, mypy, pip, etc.).

ps. As a Windows packager, you're most likely used to stateful environments, whilst OBS is strictly declarative and isolated so that's a culture shock I'm sure.

I would not consider the e.g. WiX buildchain for MSI/MISX packages to be stateful. Its mostly declarative as well. The old style setup.exe things tend to be more stateful, but MSI is very declarative. Same goes for most MSBuild files.

. With Linux all libraries are “system libraries”.

There is the /opt tree in FHS, so anything you place there isn't system libraries stricly.

And if you look at Windows Manifest files, thats not that different to Linux library versioning with .so versions etc.

The primary difference is that Linux packages often need to be compiled for a specific ABI version, as the Linux userspace ABI stability is pretty bad if compared to Windows ABI stability. With the usual stopgap methods like containers, flatpacks etc.

What is your threat model?

If you have an inactivity policy, with a 15 minute idle timer, why do you have a different policy when the person walks away from their desk?

For critical systems, just have a smart card or token, use it as the keycard for your doors as well. If someone wants to grab a coffee, the card has to move with him/her. And you can auto-lock the system.

Well, if you look at a stream of security vulnerabilities in packages, the category "bad regexp performance / denial of service" pops up multiple times a week. Killing off this whole class of issues would have been nice.