Live data from Hacker News

Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

pbxscience.com

401–410 of 421 posts

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#401

Earlier quoted context omitted.

Well, if leaking the length of the password is such a big deal, why not just use a reasonably long password? Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?

Again looking back at the history of Unix, it used a 56 bit variant of DES encryption that used the user's password as the key. So only the first 8 characters of the password were used and the rest was silently unused, for example "password" and "password123" would have been the same password on early Unix. And although most BSDs and Linuxes moved in the mid 90s to PAM (and hence md5, etc) most SVR4s didn't move unti…

My lab at university was like this, well into the 2000s. I remember a guy just smashing keys on his keyboard and then the login worked and I was amazed at how complex his password was and how he could manage to type it that fast

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#402
post #273

Earlier quoted context omitted.

> If you have Capslock set to change your keyboard language, and your computer locks with Capslock enabled How would your computer lock with capslock enabled? I.e. if capslock on that computer is set to change keyboard language?

Maybe they're saying the key rebound to serve as capslock doesn't work on the lock screen?

If yes, perhaps there are relatively easy ways to address this.

I.e. configure the custom binding to also work on lock screen. Karabiner supports this I think.

Alternatively, rebind caps lock with a custom binding and not os settings (i.e. don’t rebind keys in both a custom tool and the OS). Then, if custom bindings don’t work on lock screen, you get the default, working keyboard on lock screen.

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#404

Earlier quoted context omitted.

When the IME inserts the character, it'll be made up of multiple bytes because of the nature of UTF-8, so it may appear as multiple asterisks regardless.

Most software, traditional sudo included, would respect the LC_CTYPE being set to an UTF-8 (or any of the older multi-byte encodings), and do proper character counting. At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.

Having LC_CTYPE bit set to utf8 would be my worry. Would suck to not be able to logging because the LC* lang changed.

Hmmm, hopefully sudo-rs respects LC* env vars. I recall reading a few years back that some Rust Unix tools skipped that and won big on benchmarks until folks realized they weren’t handling NC localization properly.

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#405

The number of times I've been stuck wondering if my keystrokes are registering properly for a sudo prompt over a high latency ssh connection. These servers I had an account setup too were, from what I observed, partially linked with the authentication mechanism used by the VPN and IAM services. Like they'd have this mandatory password reset process and sometimes sudo was set to that new password, other times it was w…

If you have high latency wouldn't extra echoing use more bandwidth and worsen the situation?

In any case, I don't understand the issue. TCP is "reliable" so it's not like you'll get dropped keystrokes. Just type the password and hit enter, and the entire string will go through when it goes through

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#407
post #35

This is such a good decision. It's one of those things that's incredibly confusing initially, but you get so used to it over the years, I even forgot it was a quirk. In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.

Typed passwords can be reliably determined only through timing, so exposing the timing of the input can be exploited. e.g. screen sharing, or anyone who can see your screen

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#408

Fascinating . . . reading the comments, it seems like the vast majority think this is a long overdue change. For myself, it never occurred to me that there was any issue and I'm slightly unsettled by the change (i.e. it is far from obvious to me that it's a good thing). It is not something I've thought deeply about, of course.

Because you long forgot how confusing it was, that you can't see if your keystrokes are accepted by the machine. This is a change for people, that are new to Linux/Unix

It's something that is confusing exactly once for a few seconds. It is at the bottom of the list of UX problems for either Linux or non-Linux systems.

Alternatively, if it's confusing, you shouldn't be doing whatever it is you're doing with sudo because you copy pasted a command from God knows where with zero understanding.

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#409

Earlier quoted context omitted.

I wonder if it'll stick though? Some years ago FreeBSD changed their setup so the initial password you set on install was echoed back to you so you could verify that the thing that'll completely lock you out of the system if you get it wrong is correctly set up. The response was total hysteria. Apparently people were setting up their 1U rack-mount servers while riding the No.8 bus and were worried other passengers we…

Did that echo the password back on the screen or just asterisks?

The password, otherwise you have no way to check you've got it right.

Re: Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

#410

Earlier quoted context omitted.

Did that echo the password back on the screen or just asterisks?

The password, otherwise you have no way to check you've got it right.

Oh yeah, I can see why some might freak out about that.
Post reply on HN