sudo cve 2021-3156 fix.
john hammond walks you though how to update sudo to the latest patched version…
the official page. https://www.sudo.ws/
sudo cve 2021-3156 fix.
john hammond walks you though how to update sudo to the latest patched version…
the official page. https://www.sudo.ws/
The thing I don’t like about rolling release is that I have to run updates so often. The thing I like about rolling release is that I normally don’t need to care about stuff like that because I receive the most up to date version of software in a minimal time window. I checked and of course I already run the patched version .
Stable distros apply security fixes, they just won’t bump you to an API incompatible version to do so.
doas > sudo
Just updated Void.
sudo update 1.9.5p1_1 1.9.5p2_2 1008KB
I should probably migrate to doas on all my Linux installs. I’ve wanted to do it for a while. Baron Samedit may have been discovered, but who knows what other bugs are lurking around.
I do not understand this part, can you elaborate please?
I do not understand this part, can you elaborate please?
Say that you’re a software developer, and you want your application to make use of current encryption standards when making remote connections. Instead of writing your own cryptography software (very complicated!), you use an open source software component called a library.
That library will define how your code should be structured in order to interact with the library and use the features it provides. Data formatting and typing, ordering of fields, et cetera.
When you built your app, you used version 1.2 of that library and formatted your code appropriately. Now version 2.0 has been released and that update changes the structure of the library.
In rolling distros, updating your system switches from version 1.2 to 2.0 and suddenly your app is broken. In a stable distro, version 1.2 was shipped and that version will remain the version in use until the next release of the distro. Instead of updating to a new version to fix security issues, the flaws are fixed in the 1.2 version and the updated version of 1.2 is pushed out to users.
This is why distros favored by companies are almost never rolling. Their in-house app investment could be rendered useless by incompatible changes, and it might be months before they can reassign their engineers to make the needed updates.
who knows what other bugs are lurking around.
The OpenBSD developers didn’t replace sudo because they found it to be buggy; they replaced it because they found sudo to be poorly designed. It’s easy to misconfigure sudo and grant permissions you didn’t intend to, and difficult to correctly configure a hardened setup.
I just prefer simplicity, secure-by-default and most importantly portable software. I have no idea how I came to like portability, but I guess it’s because I like migrating my configs and expect things to work. Simplicity and portability usually go hand in hand.
As for sudo, it may be good for all kinds of complicated setups, but I’m a single user. I prefer using the simplest software I can get away with as long as they are supported. I’m even trying to move away from bash, but this is because of “bashism” that I got used to and sometimes when working on freebsd (usually pfsense, opnsense and truenas core) I make a lot of mistakes and I want to reprogram my typing. It also helps to get rid of GNU core-utils stuff, like “sed -i,” because this is only available in Linux. I’m currently testing oksh on Fedora (my work laptop) (edit: my mind was confused, actually it’s) Void (on a remote server that I use as my main scripting and ssh-ing VM, that I connect to from my work laptop) and I quite enjoy it, I may install it on everything I own. I mostly go with OpenBSD ports that aim to be just ports with feature parity, not the “improved versions.” Will try to do the same with doas (and avoid opendoas). I’ve done my homework, I’m just too lazy to implement it.
First of all thank you for your explanation, now I understand what you are saying.
Does this happen often in your experience? I have never developed anything where I was unable to install the library version I needed. I see your point however, that from a developer perspective it can be a problem and require the work to keep your software customized to the external libraries version you want to use.
However as an end-user on rolling release I never had the issue that I was unable to install packages because of incompatibilities to other packages. I was always the other way around that point releases used packages to old to be compatible with the new version of a certain software I wanted to manually install or compile.
“Technical debt”, not laziness.
Does this happen often in your experience?
Experienced developers and distro maintainers generally understand the problem pretty well, and version packages to match the API version. python
will usually be a metapackage that depends on whatever version (say, python3.7
) the distro maintainers have set as their default.
This structure also permits having multiple versions installed at once, so most mature distros use that naming strategy and defend against the problem. About a decade ago, both Gnome and KDE made major version changes and distros hadn’t adopted that versioning pattern. Everything broke, everywhere, for weeks at a time.
Test-driven development methodologies and continuous delivery have also done a lot to reduce the frequency of this being a problem for users. It’s a lot easier to detect this kind of breakage now.
Not all software is mature, though. Even developers with experience run into this kind of breakage in the early stage of a project. They’re just more likely to experience it with a language package manager, rather than the distro package manager.
Short version: security fixes are backported/applied in a manner that won’t break anything (and that generally includes UI so that your workflow stays the same - something MS need to learn with Windows 10).
Sure, running bleeding edge you get the new shiny, but for the vast majority of users, Linux from 10 years ago is “good enough” in terms of UI, APIs, etc. and a stable platform might give you less headaches
If you want to see this happen (even as an end user), run Debian Sid and upgrade every day.
I haven’t done that since the late 90s/early 00s, so maybe its different today, but back in the day, I was working for a smaller ISP and we had a Debian contributor/hacker on staff.
We were running SID in production on admin workstations and various other (less critical) servers and there was breakage from time to time. We ran SID back then because we were making use of various bleeding edge features, but now things are a lot more mature in the stable distributions. Most of the core functionality has been there for a decade or more at this point.
Sometimes breakage as simple as the package source not including all of the required dependencies to complete an upgrade for example.
It isn’t just software API version in packages that can screw you on rolling release - at any given time of day, a fully rolling distro like SID might just happen to have a broken repository at the moment you’re trying to do an upgrade - but fully functional 15 minutes earlier or 2 hours later. Sometimes fixing the packages on your box that got munted by the broken source repository could take a bunch of dpkg/apt voodoo magic and/or waiting for upstream to be fixed to resolve.
This isn’t a problem with Sid btw, it’s the nature of the beast; and also why i expect it still sees the occasional similar problem today. It’s not really something you can prevent from happening in a distro that “moves fast and breaks stuff”.
Backports has been promoted to being an official thing, and has become much more robust. As a result, the need to run Sid for bleeding edge features has been greatly reduced. You can pull the updated packages you need and have an otherwise stable system. Apt is also smart enough by default to keep those packages selectively updated from backports.
Unless you’re a Debian developer working on release engineering, you probably don’t need to move all of your packages at once. If you’re building a derivative distro, sid+experimental is where there be dragons.