It's not a proper fix, there are still cases when correct escaping is impossible and the function simply returns a error. I don"t know if if this possible at all to escape any string or if it is just because of lack of documentation, but anyway i wouldn't call this a thing that is easy to fix.
bizdelnick
joined 1 year ago
Options. We've got lots of them. So many in fact, that you need two strong people to carry the documentation around. So many that it will be a cold day in hell before half of them are used. So many that you are probably not going to do your work right anyway. However, the number of options isn't all that important, because we picked some interesting values for the options and called them ...
Defaults. We put a lot of thought into our defaults. We like them. If we didn't, we would have made something else be the default. So keep your cotton-pickin' hands off our defaults. Don't touch. Consider them mandatory. "Mandatory defaults" has a nice ring to it. If you change them and your system crashes, tough. See Figure 1.
it should be an easy fix
But it's not. Have you read the article?
Only if this does not mean that all dependencies are bundled.
Software opens a symlink the same way as a regular file. The kernel reads a path stored in a symlink and then opens a file with that path (or returns a error if unable to do this for some reason). But if a program needs to perform specific actions on symlinks, it is able to check the file type and resolve symlink path.
To determine how some specific software handle symlinks, read its documentation. It may have settigs like "follow symlinks" or "don't follow symlinks".
Security fixes are backported to ESR releases so they are not less secure than bleeding edge.
Because nobody can be sure there are no other backdoors. And, I guess, they wanted to stop distribution of affected source code.
Nope. There were checks of build environment.
Anyway the xz backdoor was enabled only in rpm and deb packages.
Have you ever upgraded debian? If both local config and default config have changed, it suggests you review the changes and choose which config to use or merge it manually.
Package managers.
Jenkins is not a modern CI. It is a historical milestone, but if you read an article you should see that it was replaced by other tools. Now I don't recommend considering Jenkins for new projects. It it fast to set up but extremely hard to support and full of old bugs and legacy code. Writing Groovy pipelines is much harder than pipelines in gitlab/github/forgejo/etc. Tens of plugins you have to use even for simple tasks have inconsistent syntax, many of them are buggy, they often become unsupported or deprecated. This all consumes lot of resourses: I maintain an instance that eats ~4G of RAM being idle.