The first time I saw perfectly valid Unicode take down an RSS reader (in ~2003), it was an ü that did it. I have taken to calling that the kaboomlaut in unit tests.
The are quite a lot of "gotchas" with passwords being Unicode though. One of my favourite tricks is to include a null byte in passwords and see what happens. Sudo treats it as the end of the string. Passwd gives "token manipulation error" and nopes out. Many websites seem to fail in interesting ways...
I've run into a service where having a password longer than 15 characters _truncates_ it but the password change dialog does not so it's stuck in limbo.
The PayPal forgot password form had this bug just a couple years ago. I changed my password to a generated one. And it was too long. But it didn’t tell me. Just silently truncated.
I used the password reset to change it. This time I used a pretty short password I could type (to rule out a weird copy-paste bug or something). Logged in, went to the change password option and THAT page informed me there was a character limit.
I would consider setting a (high) limit for a password a good practice. No one wants an attacker to run a megabyte of password data through your slow password hash. It should be a limit that normal users never reach, but something like 100 chars seems entirely reasonable.
Some web frameworks have such limits built-in.
Django for example has a limit of 4096 characters for password input, which should be more than enough for anyone, including people using long random-generated passwords from password managers
The reasonable thing to do is to prehash the user password on the client with a Unicode normalization and a SHA-512 pass.
This way you can have strong input validation server side but also allow almost arbitrary inputs client side.
PS: you likely could also salt the client side hashing and use bcrypt, but bcrypt has a quite short maximum length and I am not sure if it would provide significantly better security here.
I know of banks which, in 2023, requires exactly 8 digits, the first four being numbers, the other four later letters. No digit can be repeated. Also no consecutive numbers.
It's like they're deliberately trying to reduce the pool of valid inputs.
Not only this, but they also have a sadistic trait against their users. My password on another site (a bank too, IIRC) requires the password not to have my email username and consecutive, or repeated letters. My email username is "u" (as is u@example.com) and I usually generate a 50 or 70 characters long password. There is usually a "u" (they check the case, too). And come characters are repeated in the whole password.
So I reduce the length, significantly, sometimes to 8 characters.
The people who make rules in security in some areas are complete idiots.
A bank I used until about 2018 (no idea if they've fixed this yet - I left) had an exactly 6 character password, and when you used telephone banking it just needed the 6 digits that corresponded to that word. Those 6 numbers also worked online, so at best they were turning all passwords into numbers before hashing them, ensuring there are less than 900000 different possible passwords, which was trivially easy to brute force in 2015, nevermind today.
Bruteforcing should not work as the attempts are either throttled, or lock the account. Provided that they are in place, otherwise the account is wide open.
This i what happens with the 4 digits of a CC PIN and the 3 attempts before the card switches into PUK mode.
One site I went to lowercased my password before storing it unencrypted in the DB, which I only discovered after failing to log in and asking for a password reset mail, so it helpfully emailed me my clear text lowercased password.
I worked at a place that did this, case-insensitive passwords and all. The worst part? They had unencrypted production database backups on all of their dev laptops, the majority of which left the premises after every night. I couldn't get a figure of how many laptops were lost but statistically speaking there had to have been at least 3 lost laptops with unencrypted production database backups per year using industry statistics.
Eventually I convinced leadership to invest in basic security after conservative but still embarrassingly high 6-to-7-figure estimates of annual loss expectancy that only took a measly 5 figures a year to eliminate 75% of the risk, but the company only went around to it a long while after I left the place.
I think the lesson is "stop asking for permission and just do want is right". It's rare that a manager needs to approve a PR - would be a culture smell for me in an org.
It was an online store I bought something from quite a few years back. I would hope most stores are using more modern back ends nowadays that doesn't allow this to happen.
This was, at least a few years ago, the case with Blizzard's Battle.net passwords. I picked a nice secure passphrase, but had to cut it off mid-word because of this truncation. (I think the behavior was for it simply to take the first 16 characters of whatever you typed in the password field, so typing the full passphrase didn't fail, but I wasn't confident that that would remain true in all cases, so I made a habit of only typing the first 16 chars.)
I believe the British Airways site still does something similar to this, or it did until very recently if it's been fixed. Add a password that is too long, it gets truncated and the truncated version saved with no warning or error.
It took me several password reset attempts to realise what was going on, as my literally just set and password manager-saved password didn't work.
I think in BA's case the password input also had a character limit on it, which is ultimately how I realised what was happening, even though there was no info anywhere that such a limit existed.
In C, strings are nul terminated. Thus when at some point your password is passed along a tool written in C (or any language with the same behaviour) it’ll be truncated at that position.
A bigger deal happens with ambiguities concerning composed versus decomposed characters. Linux and Windows tend to prefer writing composed characters, whereas Mac OS will prefer writing decomposed characters. The letter é will have two distinct byte sequences to represent the same character (more precisely, the same grapheme).
If Unicode weren't broken it wouldn't need any "normalization functions".
And no, I don't have anything better to propose at the moment. Unicode is a mess, but currently without realistic alternatives.
Still I would like to live long enough to see that we finally manage to create some proper text format without all kinds of crazy gotchas and deficiencies.
Are you suggesting that a better version of Unicode does not allow combining characters? [1]
Some languages have an explosive amount of characters if you regard each possible modifier in combination with each base character, some of which aren't practically used. By allowing the composition of modifiers and base letters, all the historically used ones are available, and all the odd ones are technically expressible.
I'm not sure how you encode all the world's languages, live and dead ones, without a few gotchas and deficiencies.
What would an always-normalized Unicode look like, if not either having really, really many characters, or having a non-trivial syntax?
One solution to allow combination characters, but only in a normalised way is to only allow one of the same modifiers, and only allow modifiers in the normal order. This makes parsing Unicode quite complex. If you allow for non-normalised Unicode and write a post-processor that normalises, you get to status quo.
So either you are suggesting to disallow non-normalised Unicode with the current definition, or something different altogether. I can't imagine what that alternative looks like.
(Also, I'm a Unicode fanboy. Sorry for the intensity.)
I think normalization and compound glyphs are orthogonal concepts.
The point would be to have only one canonical binary representation. A representation that is also free of all kinds of "compromises" which are only there for legacy reasons…
Additionally the whole madness should be resolved that Unicode mixes content, representation, and layout (especially as it fails miserably at all of them).
Than there are the problems that Unicode is actually incapable of representing all kinds of scripts. (Just think for example about stuff written top-to-bottom, and not LTR / RTL). Some "unimportant" things like Math can't be represented in Unicode also…
And I won't even talk about the issue that the committee was taken over by some political movement, namely the woke fraction.
I think it's actually a kind of joke that we still didn't mange to invent some sane text format for computers. Unicode doesn't cut it.
But frankly I admit that we won't get anywhere — as even Unicode is full of madness it works "good enough" by now through even more layers of madness on top, so we won't get rid of it ever again. That ship sailed I fear. Still I can't stop banging my head when I hear about things like issues with normalization, something that shouldn't exist in the first place in a sane world.
It depends on the encoding: In UTF-16, a lot of characters have 0x00 as part of their encoding. That's the null byte, even if the software isn't technically supposed to see it that way, so it's a valid test. (Easy, too: Any character that's also in ASCII will be represented with a 0x00 byte in UTF-16.) Of course, UTF-8 solves that problem, plus the problem of surrogate pairs.
When AOL 4.0 came out they added the ability to embed images in emails, and there was a super fun bug where you could put a certain unicode char into the file name of an image and it would blue screen the recipient if they opened the email. Fun times.
Sounds 'normal' if the website was built in a recent stack in recent years.
The shipping backend might run on a mainframe, almost if not fully unchanged from 40-50 years ago and blissfully unaware of anything but the mainframe quivalent of your standard ASCII.
You can see large stores run all their inventory and such on mainframes. If you ever look over someone's shoulder. My insurance also does but it looks like they don't because it has a nice standard Windows look on the 'inside' of the window. Looked at the title bar and yep, it's just a 3270 terminal emulator that renders fields as nice standard windows input fields that follow whatever theme your computer is set to instead of your telltale black background "DOS" look.
As I remember it, the RSS readers under test did not correctly handle encodings, blissfully ignorant of the difference between UTF-8 and Latin-1. Many had processing pipelines that did not preserve encoding.
What was the point of this post? No, this program isn't a replacement for sudo; it's closer to a reimplementation of su. The post links to 3 CVEs and talks about Rust, but only one of the CVEs was a memory safety bug, the others are a logic error and a race condition, neither of which are protected by Rust (sadly).
That's a memory safety issue that caused by a race condition. Rust prevents memory safety issues, but not race conditions. The race condition in one of the CVEs is in the filesystem, not in sudo.
Rust does prevent memory race conditions, but of course, only within the address space of the process and only for memory read and written to exclusively by rust code.
I feel obliged to mention doas[1], which is a sudo alternative from openBSD. It is written in c, but tries to be smaller and easier to configure. I am not qualified to vouch for or against it, but it is interesting.
I have moved over to doas a while back and it is really amazing. Why? Because it JUST WORKS. I do not need to learn a configuration language to understand what is going on. It does very little and that is exactly what 80% of the users need. We should use more software like that. Simplicity is the best design pattern.
My existence is split between OpenBSD and Linux. What I really want is OpenBSD than runs Steam and Proton—nothing more.
OpenBSD has maintained exceptionally good taste when it comes to change. When they rip out and replace a "classic" utility, they invariably make a modern classic: openssh, pf, doas
When others rip out a system and replace wholesale, they often just do the hard work to secure the existing thing: Wayland vs. Xenocara
I don't know that there's any objective way to know ahead of time whether replacement or repair is the right approach. But the fact that such a relatively small project such as OpenBSD has managed such outsized positive impact across the open source landscape speaks volumes to their intuitions here.
I noticed and enjoy that both sudo and doas use each side of a standard qwerty keyboard to type, though doas uses 3 keys on the left while sudo has two on the left and two on the right. It made the transition a little easier for my muscle memory.
I didn’t learn anything from this post about why to use this sudo replacement except that it’s written in Rust and that it handles errors. Am I missing something?
I was thinking the same. But then I thought about it more and wondered why you need to enter your own password if you're already logged on. If an attacker is already in the system, it can install key logger and whatnot without the root password. And the xn--ts9h program can have the Unix permission so that only the user can run it.
Insider threat, attacker not in the system, you leave your terminal unlocked and are away. Someone walks passed and tries to install something from you terminal?
While it leads to slightly more chance of traceability, I've seen one line "curl | sh" which install a tool which transmit everything you type, or just your password (when you next type it) off to a remote server, so once you've left a terminal unattended you are in trouble anyway.
This is one place when windows can be much better, as users can't catch ctrl+alt+del, so you can always press that before logging in.
There is the mental function signalling "hang on, you're about to do something unsafe. Are you sure you want to do this?"
But I think there are some scenarios where it serves a practical security purpose as well:
- You're in an office, went away to grab a coffee and left the screen unlocked (bad!). Without sudo, a malicious person could indeed quickly install a backdoor or keylogger and take over your system.
- you're executing a third-party script on your user account. Without a password prompt, that script could trivially escalate its privileges by embedding sudo commands. With a password prompt, you'll hopefully stop and ask yourself why the script is asking for your password.
Basically, you actually cannot assuming that every running on a user account is really authorised by that user. So asking for the password is an attempt to reaffirm that it's really the user who gave that command.
> If an attacker is already in the system, it can install key logger and whatnot without the root password.
Yes, but that would require the attacker to, well, run sudo...
If I'm not mistaken, especially with x11, it is trivial to install a keylogger without root password. Just a process in the background that listen to your keys and send them over the wire.
(And you can add that program in the list of program to run while logging in)
For some more serious alternatives, I have heard of many people finding doas to be a drop in replacement. Furthermore, I've heard some people suggest neither doas nor sudo, but instead using an SSH server to gain root access to your local machine. It could listen on localhost and use key-based auth to allow root logins...
Using key-based auth without encrypting the key with a password sounds like a bad idea, as then any program running on the host can trivially gain root privileges.
Any program running as your user on your personal machine can trivially gain root privileges, by dropping a program called "sudo" in your personal PATH, putting a "sudo" command in your .bashrc, man-in-the-middle a shell (how do you know that last command actually completed?), or hijacking any of the graphical programs that trivially ask you for your UNIX password to do anything (Discord/Slack/... updater, Steam, ...)
When do any of those programs ask you for your password? I've never had any of them ask for my Unix password, ever. Is that just a macOS thing with self-updaters?
I'm using Ubuntu/KDE/Plasma. "Discover" is the GUI app that prompts you to install system updates, and will ask for your password when you do (to run apt/dpkg as root). Discord doesn't directly ask for my password, it downloads a .deb from somewhere and opens it, and I get prompted for my password then. Not much different IMHO.
I'm using Debian(Testing)/KDE/Plasma. (What was the point here?)
I don't have any "Discover" installed as it's not needed for anything. There's aptitude…
Regarding Discord: Discord is a virus. I try to avoid it. (And since you can't register without getting naked and showing the virus your telephone number it's not difficult to avoid ;-)).
That just means you're fully transparent to them. (Likely they have linked other accounts / IIP data behind the scenes; using it form a phone will have that effect obviously).
It's almost impossible to register an anonymous account there. Even if you find a throw-away SMS number that works to register (which is hard enough) a few hours later they will block that account again and require a fresh number to unlock. I've given up even trying to register there; but plan to fill out some GDPR complains soon. Thanks for reminding me to do so…
More likely it just means they have an old account from when they weren’t as hung ho about it all and now they don’t delete it on a whim because it’s longstanding without issue. Same thing with mine, beyond it’s desperate for that phone number for things lately.
Those are poklit popups, similar to UAC on Windows. The program doesn't get your password, but depending on what kind of access it requested, it could give it root access. If implemented correctly, the popup should say "wants to install a package" or "wants to mount drive X", which runs a predefined action on behalf of the app and doesn't actually give it any elevated permissions.
Of course, like UAC, an app could just make its own prompt that looks like the real deal and steal the password, but that seems to be an unsolved problem on every platform.
You can close some gaps, but at the end of the day you can't expect that you'll run malicious code but it won't do this or that. For example the X server allows any client to listen for key events or hook into other windows.
In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves.
For them ssh certificates are much better because you can simply revoke them, and new certs don't have to be added to each server.
At home I still use keys though, but as an enterprise admin I see the issues. Even at home it's kinda annoying having to add a new yubikey to 20 servers.
You can, but you still need to set up a secure infrastructure to manage all the requests going back and forth.
And most enterprises already have a completely functional and secured PKI, usually with the whole HSM deal and everything. It's plug and play and works with your existing infra.
Last month's electricity bill was about 75€ including electric heating, VAT and fixed charges. I do get 2 hours free per day during which I run the heading full blast at the moment, and other high energy stuff.
Most of my servers are not always on, some are in the cloud and some are virtual.
The ones that run 24/7 are NUCs which have excellent idle energy usage. The bigger ones are HP microservers but like I said those just run when I need them (there's about 100 TB of archive storage in them).
And then I have some raspberries to run my home Assistant and some other stuff. All in All I have about 10 real 'servers', 5 running 24/7, the rest are remote or virtual (one of the NUCs is an ESXi). Plenty of resources for a decent home lab.
With the recent increase in electricity prices I did move one of the microservers from 24/7 to on-demand.
> Last month's electricity bill was about 75€ including electric heating, VAT and fixed charges.
Damn, I'm double+ that a month with turning everything off at the plug each night and during the day when not on. Just one of the benefits of living in post-brexit UK, with a lame useless gov... Anyway nevermind. Always wanted to do the home assistant thing with one of my rpi, but can't afford it just now.
It is not as much the enterprise security industry as it is better security for all. Problem with the current implementation with ssh keys is that there are non-trivial problems with it. For example how do you revoke a key? It is not possible in a central AAA service to revoke access for a user like it is possible for other kind of auth systems. Ssh and ssh keys were designed in an era where security was not really the primary concern. I think Facebook DevOps team had some detailed article how they manage ssh access to fb production with keys.
The main problem with SSH keys is that they are good at small scales, but at larger scales the abstractions start to be really leaky. Distributing SSH keys across hundreds of machines is a nontrivial task. Not to mention the lack of audit logging in opensshd and the lack of session recording (these requirements suck but acronym compliance means you need them anyways).
It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
> It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
On the other hand, if you knew what I'd need to do with the servers, I probably wouldn't need to do it. It's really hard to investigate problems without tools. Nobody is going to make a graph for how much cpu poorly configured docker/datadog are wasting rereading the same 1GB of json logs once or twice a minute, because nobody thought it would be meaningful, but watching top in one window, and running lsof at the right time to see what's being read, and whatever performance tools are hanging out to confirm.
Ah the dream of easy to administer, perfectly adapted fine grained access permissions that can predict the future of exactly what an authorized user can run and needs to do.
It never works because of the lack of precog, ticket walls, escalation over policy requiring reviews, and other bureaucracy.
What they end up replacing ssh with (teleport or aws ssm are the two I've been forced to use) are slow, spotty, crash frequently, and who knows what vulnerabilities they have.
If all these companies trying to get rid of sshd want to slap their own daemon on to replace it, why not keep sshd and simply have a deamon that manages the keys and not throw out the entire tool chain?
The most fun thing with teleport and aws-ssm: to use it you had to bring up a web page to authenticate. There goes any hope of automation at scale. Because in a world where you're supposed to treat servers like cattle, let's impose (and I mean impose) a regime that forces you to access them one at a time manually, especially in critical situations.
> Distributing SSH keys across hundreds of machines is a nontrivial task.
In what sense? If you're distributing public keys to hundreds of servers, go nuts. Put them in git repos and clone them.
If you're distributing private keys to hundreds of clients, why do you ever need to do this? Assuming you do (and I'm just missing something), then I see your point but if you ensure they're encrypted with the user's pass phrase and you have a procedure for ensuring their permissions are set to 0x600, what's the problem?
Yeah, the trickiest part is getting new users to check in their keys to git if git is authenticated with ssh keys. And if you need sudo to install keys, you've gotta use autopw[1] or something similar, and at least autopw is single threaded, so if you've got more like thousands of servers, it's a bit messy. Smarter people than I setup full automation for this kind of stuff, but then you have to trust the automation.
> what would happen if you gave a company an unpronounceable name and it took off.
As long as it's an actual company taking money/paying for services, you'll have to register it, so it will have a pronounceable name.
Reminds me of "Love symbol" formerly know as "Prince". The symbol is great, but you'll have to register as an artist to get the money, you'll be signing contracts, etc., so whatever clever symbol you find, at some point a standard writable name will be settled on.
If there's a 1:1 mapping from some emoji to one of the basic Chinese logograms, we should just reuse the pronunciation of the latter as the name of the emoji. This one could be "qiu", for example.
The wechat shortcode for their similar face is 可怜.
As far as I know, it is not used for begging (and therefore couldn't be called 求); the one time it was used to me, it seemed to express something more like "ouch!".
It does have a name. The most common of which being being ぴえん (pien). The English name is pleading face, but I hear the Japanese word for it much more in practice.
I just always login as root. No sudo or other programs needed, no security vulnerabilities, no complexity. Clearly the most secure solution as it's widely known that using the setuid bit is a security problem.
Yes, OTOH I don't mind others using sudo or setuid root permissions. I once hacked a payment terminal because someone thought it would be a good idea to put setuid root on pppd :) (we needed to do a bit more than the official SDK api allowed us)
Usually the majority gets it. And the worst that can happen is that some people will downvote you, or call you an idiot. I'm not especially concerned about this.
I don't see how it's an accessibility issue, except to help out those with a deficient sense of humour.
regarding accessibility..from what I have heard, other cultures have much different styles of sarcasm which might impede their ability to understand that something you have said is sarcastic. e.g. Japan is known to have a reputation of not understanding American sarcasm, but has it's own style of sarcasm. (see https://linguaholic.com/linguablog/sarcasm-in-japanese/)
so, I guess announcing your sarcasm makes sense in an international accessibility sense, particularly when some of the normal cues are not present (tone of voice, facial expression, eyes rolling)
Communicating across cultures is always bound to lead to the occasional misunderstanding, even more so over text. When writing something "dry" such as documentation it's probably a good idea to keep that in mind, but making jokes worse just so that a few more people can perhaps maybe possibly understand it is where I draw the line.
I always liked Debian’s really. The first thing it does is make one system call to see if you can open a file in /etc with write permissions. If you can’t then it crashes immediately without doing anything else. The attack surface is very small.
sudo’s notion of some people being able to do some things but not others just doesn’t seem very relevant these days, and never really sat nicely with me in my multi user Unix host days either. I was much more in favor of giving people multiple system accounts and letting the system auth (ssh) handle who can do what.
Now of course we all have umpteen complete hosts each, and the security boundaries are at the virtualisation layer. Passwordless sudo all ‘round!
Typing emoji is a pain, but the chat suggests that that might be an advantage:
> Using this program requires you to be able to type an emoji. Most attack code is of such poor quality that they are unable to run commands named with emoji.
The best part is that it's a joke that has enough merit to it that it's worth being taken seriously. That makes for good satire. I love writing surrealism, it's a very hard balance to meet.
> The best part is that it's a joke that has enough merit to it that it's worth being taken seriously. That makes for good satire. I love writing surrealism, it's a very hard balance to meet.
> This comment section not understanding where I was being satirical.
That means you didn't meet it[1].
[1]That balance you were talking about. You missed it. If too few people understand your content, it's not the people that's the problem. As someone attempting to present an argument, the onus is on the presenter to make the argument readable, not on the reader to squint until it gets readable.
IOW, if you can't be bothered to write your message well, why did you expect other people to be bothered to read it at all?
What makes you say "too few" understood? It's a balance, right? So if plenty of people understand, and the right people didn't understand, then it's right on target.
And it looks to me like lots of people understood.
Yeah! First I read the HN comments and saw how pissed many people were. That helped set the tune for the article (read: it helped me handle my own triggers) and it was a lot more fun that way.
I think the author intended it as a valid criticism, though it's hard to tell given the passé stylistic choice that calls back to early internet (I am nostalgic for those days sometimes). However I disagree with that as it's just one more, fairly silly, obstacle to overcome. If this "replacement" ever did, theoretically, been seen as suitable, all that would happen would be that attack code would suddenly see an increase in quality.
If you've done any research into quality malware, exploits and the like (both domestic and foreign), the quality and often elegant solutions they come up with will not be somehow kneecapped by an emoji. It also only needs to support inputting one emoji in the event that someone uses this out in the field; not hard to do in shellcode.
> If this "replacement" ever did, theoretically, been seen as suitable, all that would happen would be that attack code would suddenly see an increase in quality.
This is where I believe security-through-obscurity is underrated. As long as you're small enough that targeted attacks aren't part of your threat model, merely being unique affords a great deal of safety. Your wierdo jerry-rigged authentication system may not be particularly robust, but it's more likely than any mainstream product to repel an automated attack.
In the event that something is seen as suitable; i'm assuming it would see some adoption (that's the assumption I wrote the comment under).
However I do agree, at least against automated attacks; there will be a bit more security. Though if you are doing anything serious that draws attention, at that point obscurity is all but putting off the enevitable failure if you are ever targetted.
For anyone wondering, this is basically a young millennial / gen z meme. The emoji is usually pronounced "pwease", as in a childlike pronunciation of "please"
Therefore the command is basically just asking very nicely, hoping to get one's way
Alternatively, a good chunk of my twitter feed would call this the bottom emoji, without attempting to give it a pronunciation. I don't think any particular pronunciation has consensus, but various groups of people imbue it different meanings.
Yeah, I always read this as "bottom emoji" in my internal monologue, and that is how I search for it if I need to copy & paste it on a laptop or desktop lol.
At least among Gen-Z, it's less an indicator of sexual orientation, and more so one's sexual position. I am friends with a (hetero) couple where the male is the bottom. She pegs him because that what they like. He is not attracted to men, but also does not enjoy being sexually dominant.
I'm on the spectrum, and I can't tell 99% of these things apart. Looks like a sad face to me. no different then the 500 other sad face emoji's I find.
I'll stick with =(
> I'm on the spectrum, and I can't tell 99% of these things apart
If it's any consolation, I'm not, and I don't know exactly what a lot of the face-emojis are supposed to be expressing unless I see a text representation of them or otherwise have them explained.
Yeah, many are just too small to distinguish clearly. I actually thought it was "rolling eyes". That's kind of how it renders for me in Firefox anyway, but if I zoom in a lot I see it's not.
I also find tiny body-text-sized emojis hard to grok. A thing that’s helped me is heavily focusing on context and trying to imagine the human speaker/writer making the same face in said context—i.e. relating it to their apparent emotional state or other clues in their language. It’s like learning vocabulary from scratch all over again, with some prior learning pathways as a shortcut.
I don’t know if that’ll help you (or anyone), and I have other problems with meatspace facial expressions (partial face blindness, probably partly attributable to finding eye contact uncomfortable; although weirdly enough trying to “get” emojis has helped on both these fronts to some small extent). So … idk if this will help but I took all this time typing it so here we are.
> I also find tiny body-text-sized emojis hard to grok.
This depends a lot on emoji font. Apple's 3D-ish, highly colorful, rasterized emoji are very difficult to discern at small sizes, for example, unless you already know what they are.
More stylized emoji fonts, like EmojiOne or emoji that are drawn basically the same way as text glyphs, like in Symbola, are way, way easier to read, especially at small sizes.
If you're on an Apple device, though, you're close to fucked, since the operating system just ignores your font choices when it comes to emoji. The best you can do is carefully hack the actual files for the Apple Color Emoji font on macOS, which requires you to disable SIP and will cause lots of app crashes if you do it wrong. But if you're using an OS that has some respect for you and your choices, try a different emoji font!
Wait what, this is some kind of emoji/face? It shows up as a grey solid box that is slightly wider than tall for me, so not even the typical "glyph missing" thing...
Edit: ok apparently this is indeed the placeholder for missing emoji in Firefox for Android at least.
> I'm on the spectrum, and I can't tell 99% of these things apart. Looks like a sad face to me. no different then the 500 other sad face emoji's I find. I'll stick with =(
If it's any consolation, I don't think anyone could infer that from the emoji itself. The meaning is like a subculture's slang.
I don't use emojis, so I only know the very basic ones (which I consider to be obfuscated emoticons).
It is pretty obvious that it is a face doing the sad puppy eyes, like the one a young niece might do after I refuse to buy her some ice cream. I didn't even know it's meant to be underground, impenetrable slang.
It might be an emoji-font thing. Might be easier to tell what's up in some than others. I know I've seen emoji I sent from Apple devices on Android phones and been all "LOL WTF that's not what I sent at all" so that is sometimes a factor.
Anyway, this is one reason why I prefer images and anigifs for expressing emotion in chats.
The Twitter version of it is what I'm seeing from this blog (Firefox on Ubuntu), which to me does look a lot more like "exasperated eyeroll" than "puppy-dog-eyes pleading".
If you don't already know, you can usually copy/paste to your favorite search engine and one of the first results is often the page explaining the unicode character, including those all-caps formal names of them.
The nice thing about emojis being in Unicode is that you can copy/paste them and look them up, unlike embedded images. The reference name in the Unicode database conveys the original intent of the people who submitted it for standardization, at least.
$ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
$ fuck
sudo apt-get install vim
[sudo] password for nvbn:
Reading package lists... Done
Judging just from that, I'd have taken the meaning as "verge of crying" or "my pet just unexpectedly died"
Until I read that comment I was having real trouble figuring out WTF it had to do with running commands. I thought it might be some practical joke tool that automatically modifies your commands such that they'll make you sad when they run.
people have different perceptions, interpretations, and understandings of things. Your comment comes across as pretty insulting. clear communication is necessary and helpful
Would like to note that I happened to see someone I know use this over the weekend and it was unambiguously intended as the "verge of crying" meaning I guessed previously, not "puppy dog eyes". LOL.
To me at 2–3 mm it looked more like sleep deprived baggy eyelids (or maybe candy corn eyes, but what does that mean?). I read the whole post thinking the program was named after exhaustion, not pleading.
I just polled the room and most guesses were that it’s sadness/sorrow.
Depending on font. Inside my web browser, it appears to be looking up. On my web browser's title bar (so rendered by my window manager...), it appears to be looking down, or maybe straight forward. Fonts make a big difference on interpretation too.
I remember a few years back, there was a problem where Apple implemented "GRINNING FACE" in such a way that Apple users interpreted it as a sarcasm indicator, but most others would look just like a standard smiling face, leading to quite a number of awkward exchanges when non-Apple users would read things such as "Yes, let's burn it all down :)" instead of "Yes, let's burn it all down :|"
Disregarding the "browser" column (could be anything, it's what your browser renders the text as), only the Twitter font has the "looking up" variant that you think is normal. I'd rather say the straight-ahead look is the norm for most font designers when interpreting the "FACE WITH PLEADING EYES" description of the character.
They wrote it in 1980 for unix; what exactly would you like them to have used?
> (as far as I can tell) have no intention of rewriting it in Rust
Since it will be less than a paragraph before you start ranting about how "obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things", I trust you, who would surely never be a "leech", have written an actual replacement or submitted patches to start improving the situation? Or perhaps are funding such efforts?
> I did write an actual replacement. It's what TFA is about :)
That is obviously not a replacement; either we take the serious approach of "sudo allows only authorized users to run things as root" and yours doesn't control access, or we take the nonserious approach of "sudo has so many bugs that it just gives people access" in which case we hardly need to bother rewriting it.
And then use su or whatever to control access to the actual root account? You'll always need some amount of access to it, although I suppose you're correct that in a truly well-functioning system it would be needed much less since everybody would be in enough groups to get access to the stuff they actually need.
Because the entire value-prop of sudo is ubiquity and mindshare. There are as many replacements for sudo as there are Rust developers. Any one of them is probably fine.
The hard part is solving the coordination problem among millions of humans to just pick one and standardize on it. All that work is eliminated in an instant if you just convince the sudo maintainers to bless and ship one.
I think there's a security problem with this command. The command does not verify it's called as [xn--ts9h], it really needs to verify args[0] equals the name of the command, otherwise you could call it though a link or mapping, etc. The article states that the name is important for security, so I'm submitting this bug as critical.
Wait? it doesn't make any sense. So any userspace program can call `setuid(0)` and `execv()`? Why is there sudo in the first place? I am not getting it.
Sudo exists as an elaborate ACL scheme implemented in user-space which takes advantage of the setuid+root permission scheme implemented in the Unix kernel to allow granularly granting root access to non-root users.
But any program can be setuid and/or setgid to any user/group and it will then run as that effective user/group by any user with permission to execute that program.
There are handful of programs that are setuid root because they need to do things like open raw sockets that non-root users can't do, ping being the canonical example. Finding buffer overflows in these programs has been a source of privilege escalation security bugs.
Fortunately these days programs like ping can use more focused alternatives to setuid, like CAP_NET_RAW, to greatly reduce attack surface.
But also we’ve largely given up on Unix users as a security barrier in many places, instead using things like VMs as the interface between different tenants in hosting providers and clouds and such. The age of untrusted shell accounts shared Unix servers is ending, if not over already. Passwordless sudo on a cloud VM is probably the norm now.
Presuming charitably that you mean the more interesting question of "why is this a program rather than a thing other programs do internally when they realize they need elevation": well, two reasons:
1. any program can call fopen(2) and fwrite(2), and yet cat(1) exists. Unix plumbing is mostly there for cases where you're linking programs together in ways those programs didn't expect.
2. Privilege separation. You don't want big, complex programs running as root. You want big, complex programs running as your user, speaking to tiny little well-hardened programs running as root over a pipe, where the tiny-little program can only do one thing.
For example, you might have seen the pattern of piping things into `sudo tee [file owned by root]` in order to be able to write to a file that's owned by root. This fits both of the above considerations: moving the privilege into "tee" rather than having whatever command is generating the text, exposes less of a vulnerability surface; and also, it's `sudo tee` rather than tee(1) itself performing elevation, because tee(1) itself was written a decade or two before this pattern emerged, and so has no idea it could be used this way.
