DirectAdmin v1.63.5 has been released
- Thread starter fln
- Start date
- Joined
- Aug 30, 2021
- Messages
- 923
Hi everyone, just to clarify DA version 1.63.3 does have security issues that were fixed in 1.63.5. However this is managed risk considering
Automatic update was pushed to old DA installations because we are depreciating old licensing system. It is not because of severity of security fixes.
Keeping
For keeping the system most up to date we recommend using
stable will get an update, but later on. There will be some security fixes in 1.63.6 as well.Automatic update was pushed to old DA installations because we are depreciating old licensing system. It is not because of severity of security fixes.
Keeping
stable stale also allows gives downgrade path for anyone who has issues with breaking changes in current.For keeping the system most up to date we recommend using
current release channel.I guess I'm playing devil's advocate here, but that sounds like a flawed system if you ask me.
The point of stable is to be... well... stable.
How can a known security vulnerability be stable?
Stable means that you don't have the latest and greatest "features" and probably less frequent updates. But shouldn't security updates be applied to stable?
I would propose something like kernel updates where odd numbers are stable and even numbers are more frequently developed (or vice-versa, can't remember which way kernel versions go).
DirectAdmin 1.x.x would be stable with security updates.
DirecAdtion 2.x.x would essentially be the "current" channel, with new features and more frequent updates.
Perhaps line those up with minor version numbers... i.e. DirectAdmin 1.7 is the same as DirectAdmin 2.7, with DirectAdmin 1.7 being in the stable channel and DirectAdmin 2.7 being current. Then features and all kinds of new stuff is added to DirectAdmin 2.7.1, 2.7.2 ... 2.7.108. Eventually you merge the two channels with DirectAdmin 1.8.0 (stable) and DirectAdmin 2.8.0 (current).
Otherwise, there's no point in having stable. If stable is not going to have security fixes then there's just no point.
Isn't this a risk itself: I could take a branch with security issue fixed and a branch with no security issue fixed and compare it to find the Security issue that isn't disclosed yet and thus where admins don't know how to fix it yet or how to find out if it was abused already?
- Joined
- Feb 27, 2003
- Messages
- 623
Maybe there is no problem here -- we are just interpreting the word differently? Stable branch was requested by those wanting older, time-tested code. It's not that the stable branch doesn't get fixes/features/updates. It certainly does, but at the slowest rate. Our docs define it as the most delayed branch. Even fixes are subject to human error, and can introduce new bugs, so this branch is for those who demand *everything* pass the test of time.
Maybe it's not perfect (and sounds political) but let's use vaccines as an analogy. Like a software bug-fix, they might (or might not) introduce new problems. There are some people who want the solution right now, and will be the first to take it, even though there may be side effects (alpha channel). Some people are totally the opposite. They know it might be good for them, but they want to sit back and wait a long time to see that everything is fine with the solution (stable channel). Of course, both these groups are taking some kind of risk (being too early, or being too late).
Most people are somewhere in the middle. This is why we suggest (and default to) the current channel. As @fln pointed out, keeping the stable channel true to its definition guarantees an instant downgrade path in the event of any sudden problems with an update. You never want to become trapped if an update causes some devastating incompatibility or downtime.
So @sparek I hope my effort made some sense here, and explains why latest fixes would be delayed in the stable channel. Of course, there is still the matter of common sense. If there was some truly terrible & urgent exploit discovered, then of course we'd force it into every branch, immediately, among other actions.
Otherwise, it is a contradiction to ask why newest/untested things are not in a branch devoted to oldest/time-tested things. I do understand how the name could cause confusion. "Stable channel" sounds a lot nicer, but I suppose "delayed channel" might be more accurate and then nobody would ask why things in it are... well... delayed.
Maybe @fln or @smtalk would be more qualified to answer this one, but I believe it would be a matter of discernment. No two issues are ever the same, and not every security fix is an emergency situation where update channel specs are ignored. I get what you mean, though. You don't want a situation where comparing 2 versions is an obvious giveaway for hackers.
You would really need to define the differences between "security fix", "bug fix", and "feature", wouldn't you?
I don't know what the security fix in 1.63.5 fixes. I just know that Patrick from Rack911 on WHT strongly recommended that everyone apply that fix. And it seems the only way to apply that fix is to bust out of the stable channel.
I don't know if what Rack911 is referring to is a "security fix" or a "bug fix" - it sounds more like a security fix to me.
Kind of like a home security system that has a security flaw: "We know there's a security flaw in the security system, we have a fix... but you can't have it!"
That's why I like my idea of completely different version numbers for stable and current. That way there can be a "security fix for stable" and a "security fix for current".
In my opinion security fixes should be pushed out regardless of channel and regardless of wait times. It makes absolutely no sense to know about a security flaw, know about a fix... but stall in pushing out that fix to everyone.
For "bug fixes", sure these can be delayed in stable. I probably would not delay them too long, a week? The idea being that whatever "feature" the "bug" applies to - it would have significant time for the "feature" to be publicly audited in current and also for the "bug fix" to be publicly audited in current.
For "features" I really don't care that much about them. That's what stable would lack the most on purpose.
The changelog for stable would consist almost exclusively to "security fix", "bug fix", and "merge with current"
On the flipside of this... if you get too many people running stable then you lose out on the number of folks that can publicly audit features and bugs in current. So you may need to incentivize people running current more than stable, but as it stands right now, you either have very few people using stable or very few people using stable that frequent these forums or WHT (or care that they are exposed to a security hole).
I don't know what the security fix in 1.63.5 fixes. I just know that Patrick from Rack911 on WHT strongly recommended that everyone apply that fix. And it seems the only way to apply that fix is to bust out of the stable channel.
I don't know if what Rack911 is referring to is a "security fix" or a "bug fix" - it sounds more like a security fix to me.
Kind of like a home security system that has a security flaw: "We know there's a security flaw in the security system, we have a fix... but you can't have it!"
That's why I like my idea of completely different version numbers for stable and current. That way there can be a "security fix for stable" and a "security fix for current".
In my opinion security fixes should be pushed out regardless of channel and regardless of wait times. It makes absolutely no sense to know about a security flaw, know about a fix... but stall in pushing out that fix to everyone.
For "bug fixes", sure these can be delayed in stable. I probably would not delay them too long, a week? The idea being that whatever "feature" the "bug" applies to - it would have significant time for the "feature" to be publicly audited in current and also for the "bug fix" to be publicly audited in current.
For "features" I really don't care that much about them. That's what stable would lack the most on purpose.
The changelog for stable would consist almost exclusively to "security fix", "bug fix", and "merge with current"
On the flipside of this... if you get too many people running stable then you lose out on the number of folks that can publicly audit features and bugs in current. So you may need to incentivize people running current more than stable, but as it stands right now, you either have very few people using stable or very few people using stable that frequent these forums or WHT (or care that they are exposed to a security hole).
My understanding is the only difference is time. There is no deep method to the madness.
Alpha (was called prerelease?) is today real time, now, and user untested. No production user should use this.
Current is the the Alpha from last week or month. Seems to be ok by directadmin. Untested by users until installed. Although a few users may have tested Alpha a month ago. Most wouldnt do this. It is in general the first time a license holder see bugs. It is the Default when you do an install. Which is why most use this channel they don't change it..
Stable is older code from 2 months ago or more. Was ok in alpha. ok in current. Now just older.
Right based on time not Testing process. I think this is the real issue. Delayed is not the definition of Stable. Stability is much more than time tested. Stable infers well tested, audited, hardened, and solid. Like a house built on a rock not sand.
I will say it again software companies need bug reporting and tracking systems. I agree if there is a need for a Security fix all channels should get it. If "stable" doesnt get security fixes asap then its not Stable it not possible for it to be. Its just still older flawed code. Also all users should be notified via many channels for security issues. We all should have gotten and email letting us know there is a fix and it a security issue.
To keep with the theme is like knowing a virus exist, annoucing you have the cure, and only giving it to young people. I will say it a differnet way Always prefer Order not Chaos.
If there is a hole in the dam plug it no mater is the dam is old or new.. stable or current just plug the hole.
Perhaps you need to change the name of "stable" to "previous" if it's only purpose is to be an agent of downgrade.
Apparently there's no separate development for "stable".
I'm not sure if the term "release channel" is being used properly in this case.
There's just no reason to run anything except for current. Not really sure what the point of having a "release channel" option is.
Basically - "everybody needs to run current unless you encounter a problem with current then you need to go back to previous"
There's just a lot of misunderstood terms or communication with DirectAdmin. I guess if you've been with DirectAdmin from the beginning it all makes sense to you. But it kind of hinders you when trying to identify with new users. Maybe it's a language barrier thing?
In regards to this particular security issue - I just wish this would have been made clearer earlier on. I was really expecting a fix for stable to come out soon after the fix for current was. And I waited, and waited, and waited. Then I thought, maybe 1.63.3 wasn't affected by this - because again it's not clear when the security hole was introduced. Nothing was communicated that clearly to me. I guess I'm the only one that feels that way though.
Apparently there's no separate development for "stable".
I'm not sure if the term "release channel" is being used properly in this case.
There's just no reason to run anything except for current. Not really sure what the point of having a "release channel" option is.
Basically - "everybody needs to run current unless you encounter a problem with current then you need to go back to previous"
There's just a lot of misunderstood terms or communication with DirectAdmin. I guess if you've been with DirectAdmin from the beginning it all makes sense to you. But it kind of hinders you when trying to identify with new users. Maybe it's a language barrier thing?
In regards to this particular security issue - I just wish this would have been made clearer earlier on. I was really expecting a fix for stable to come out soon after the fix for current was. And I waited, and waited, and waited. Then I thought, maybe 1.63.3 wasn't affected by this - because again it's not clear when the security hole was introduced. Nothing was communicated that clearly to me. I guess I'm the only one that feels that way though.
Yes appears as such. Not good.
correct my understanding as well. They used to only have prerelease and released (current) not sure it have a name. Stable is some new channel they created. I never switched to Stable since all we ever had was the 2 above.
agreed.
Well I am not old like some but it doesn't make sense to me.
They are Canadian they speak English
It might be shocking but for once I think we agree..
Apparently there are channels: alpha, beta, current, and stable.
Now... I'm not sure what the use case differences wold be for someone to use alpha vs. beta. Not disputing that there isn't a need for one of these or both. The names alpha and beta would infer that those users are aware of that those channels haven't been tested or adequately tested. I would surmise that users of these channels would probably be plugin developers? Or people with a very firm understanding of what's under the hood of DirectAdmin. Maybe some DirectAdmin hobbyists or DirectAdmin fanboys that wants to stay as close to the development as possible. Just not exactly clear on what the in-use case for alpha versus beta would be... but it's really splitting hairs because neither is expected to be production use.
I would also surmise that alpha and beta channels would have their own development team or at least their own separate development queue. Because again, the terms would imply that new features are tried all the time in these development channels, some make the cut, some don't. The ones that do get pushed up to current - where there is another development team or queue.
Undoubtedly there would be features in alpha/beta that you try to add that either take up too much time or just don't work. That's what makes these development channels so much more fluid. For any of the software any of us use in our everyday life, there's no telling what features were tried and failed in alpha/beta and we the general public are none the wiser about those failed features because we're not alpha/beta users.
That's where I get my definition of release channels (i.e. development team, development queue). If alpha/beta and current have their own release channels... why doesn't stable?
Granted... you can have too many release channels (see that ... *ahem* ... other control panel). If DirectAdmin wants to have just the one release channel (i.e. current) ... while I don't necessarily like that... it is what it is if that's the route they want to go. I just think it's causing confusion (at least for me) when I see "release channels" and "current" and "stable". When really it just means "the current version" and "the version before the current version." There's not really any separate channels and there's not really any added benefit to stability.
Now... I'm not sure what the use case differences wold be for someone to use alpha vs. beta. Not disputing that there isn't a need for one of these or both. The names alpha and beta would infer that those users are aware of that those channels haven't been tested or adequately tested. I would surmise that users of these channels would probably be plugin developers? Or people with a very firm understanding of what's under the hood of DirectAdmin. Maybe some DirectAdmin hobbyists or DirectAdmin fanboys that wants to stay as close to the development as possible. Just not exactly clear on what the in-use case for alpha versus beta would be... but it's really splitting hairs because neither is expected to be production use.
I would also surmise that alpha and beta channels would have their own development team or at least their own separate development queue. Because again, the terms would imply that new features are tried all the time in these development channels, some make the cut, some don't. The ones that do get pushed up to current - where there is another development team or queue.
Undoubtedly there would be features in alpha/beta that you try to add that either take up too much time or just don't work. That's what makes these development channels so much more fluid. For any of the software any of us use in our everyday life, there's no telling what features were tried and failed in alpha/beta and we the general public are none the wiser about those failed features because we're not alpha/beta users.
That's where I get my definition of release channels (i.e. development team, development queue). If alpha/beta and current have their own release channels... why doesn't stable?
Granted... you can have too many release channels (see that ... *ahem* ... other control panel). If DirectAdmin wants to have just the one release channel (i.e. current) ... while I don't necessarily like that... it is what it is if that's the route they want to go. I just think it's causing confusion (at least for me) when I see "release channels" and "current" and "stable". When really it just means "the current version" and "the version before the current version." There's not really any separate channels and there's not really any added benefit to stability.
I think everyone should calm down... If there really is an urgent matter, they will push an update, like mentioned by @DirectAdmin Sales .
If they rule it not urgent enough, the matter is done. This is the same as Microsoft releasing a fix outside patch tuesday (or what day is it again?) or not..
Why the different channels? In the past you had to do this on the command line, now you can just do it from inside DA. Why it was used? When you report a bug and they fix it, the fix is available in the 'alpha' channel right away, you can update it and be happy and move on. No need to wait for a proper release. You wanna test a release candidate? Go for the beta channel.
You are right the 'current' channel is good for most people. You wanna be sure nothing crazy is going on? Then you go for stable. But you have to wait longer, maybe even for some security fixes. And like I said at the beginning, if there is something urgent, they will push it. I see you pointing at the one discovering it telling people to update, my anwser is, if it was there all this years and isn't exploited yet, it probably is something you can't just exploit that easy, or all other hackers are stupid...
If they rule it not urgent enough, the matter is done. This is the same as Microsoft releasing a fix outside patch tuesday (or what day is it again?) or not..
Why the different channels? In the past you had to do this on the command line, now you can just do it from inside DA. Why it was used? When you report a bug and they fix it, the fix is available in the 'alpha' channel right away, you can update it and be happy and move on. No need to wait for a proper release. You wanna test a release candidate? Go for the beta channel.
You are right the 'current' channel is good for most people. You wanna be sure nothing crazy is going on? Then you go for stable. But you have to wait longer, maybe even for some security fixes. And like I said at the beginning, if there is something urgent, they will push it. I see you pointing at the one discovering it telling people to update, my anwser is, if it was there all this years and isn't exploited yet, it probably is something you can't just exploit that easy, or all other hackers are stupid...
If you are this paranoid you should go for alpha, I'm sure the fixes are already in there.
Do you also ask this at other companies you use software from? When you read release notes (if there are any) and see security related stuff chances are you have no idea how much time they took before it made it's way to a release...
Do you also ask this at other companies you use software from? When you read release notes (if there are any) and see security related stuff chances are you have no idea how much time they took before it made it's way to a release...
Do you vet everyone that accesses your servers? I guess you've physically met every single person that logs into DirectAdmin on your servers? You've had beers with all of these people and know exactly what type of person they are. Congrats!
There's a difference between software that I, and I alone, use and software that is delegated out to other users.
You tell me that there's a security flaw in a desktop OS or desktop application or something that's not directly connected to the Internet, no I'm not as concerned about that flaw - because I can vet who has access to my desktop. I have a door at my house, I have a lock on my door, I can put a password on my computer. All prevents potential malicious users from exploiting that flaw. Even if the desktop application is connected to the Internet it's just more inherently unlikely for someone to spend the time tunneling into my network to exploit. Possible? Sure! Absolutely! ... but compare it to a piece of software that runs on a web server... where everybody has access, no doors, no locks.... it's a different comparison.
I've obviously ruffled some feathers with this. And I've learned that my voice doesn't care much, if any, weight. So I'll shut up and let whatever happens happen.
There's a difference between software that I, and I alone, use and software that is delegated out to other users.
You tell me that there's a security flaw in a desktop OS or desktop application or something that's not directly connected to the Internet, no I'm not as concerned about that flaw - because I can vet who has access to my desktop. I have a door at my house, I have a lock on my door, I can put a password on my computer. All prevents potential malicious users from exploiting that flaw. Even if the desktop application is connected to the Internet it's just more inherently unlikely for someone to spend the time tunneling into my network to exploit. Possible? Sure! Absolutely! ... but compare it to a piece of software that runs on a web server... where everybody has access, no doors, no locks.... it's a different comparison.
I've obviously ruffled some feathers with this. And I've learned that my voice doesn't care much, if any, weight. So I'll shut up and let whatever happens happen.
LawsHosting
Verified User
Has this "security flaw" been released to the public yet? I think not, hence any delay for a fix.... I'm not defending anyone and I, too, think proven security flaws should be fixed regardless ASAP.
counting to 10 backwards. Deep Breaths... Oh wait I updated my servers long ago
I get that.
DA is nicer than Microsoft by a mile.
If you do though you get a exploit because Stable isn't patched unless its deemed BIG or major. No body likes exploits. We don't know is it big or something we don't care about. Again if it flawed, exploited, CVEed whatever you want to call it. Its not Stable.
Then its shouldn't be called Stable. The should call it the Older channel.
Yes you did twice and so did they.
I dont care if they are stupid or it been there 2 days or 2 years. If its a discovered security flaw it should be fixed.
You must be talking to Sparek. I am totally sane and would never use Alpha.
Yes I do. I file bug reports and ask for updates. I cant really do that with DA because they dont have a published bug reporting or tracking system.
Like I said DA is a good company I don't have a issue there. We are talking about an issue. The code defect ssue has already been fixed.
The issue for me is the misuse of standard industry terms that mean something like Stable. Stablity is not defined by Time passing. Its defined by testing and a process of determining stability. It doesnt matter where the Code is on the time continuum. If the code is flawed and that flaw is related to security, performance, crashing and other critcal factors. Once a fix is found that fix used be handed to all branches especially Stable. Because the defintion of stable doesnt have the word flaw or defect in it.
More counting more deep breathing 10 9 8
Okay, so I guess everyone here is following the development of all used server software on a daily basis and skims the commits to hunt down security fixes? When PHP fixes a security bug and the release takes place in the monthly cycle, you still have to wait (and yes there are php releases that get the 'This is a security release.' notice), but those are just the monthly releases, not a special one to patch it asap...
But maybe they should delete 'stable' and only keep 'alpha', 'beta' and 'current'.
But maybe they should delete 'stable' and only keep 'alpha', 'beta' and 'current'.