Why memorize a different command? I assume sudoedit just looks up the system’s EDITOR environment variable and uses that. Is there any other benefit?

I don’t use it, but, sudoedit is a little more complicated than that.

When invoked as sudoedit, the -e option (described below), is implied.

       -e, --edit
               Edit one or more files instead of running a command.   In  lieu
               of  a  path name, the string "sudoedit" is used when consulting
               the security policy.  If the user is authorized by the  policy,
               the following steps are taken:

               1.   Temporary  copies  are made of the files to be edited with
                    the owner set to the invoking user.

               2.   The editor specified by the policy is run to edit the tem‐
                    porary files.  The sudoers policy  uses  the  SUDO_EDITOR,
                    VISUAL  and  EDITOR environment variables (in that order).
                    If none of SUDO_EDITOR, VISUAL  or  EDITOR  are  set,  the
                    first  program  listed  in the editor sudoers(5) option is
                    used.

               3.   If they have been modified, the temporary files are copied
                    back to their original location and the temporary versions
                    are removed.

               To help prevent the editing of unauthorized files, the  follow‐
               ing  restrictions are enforced unless explicitly allowed by the
               security policy:

                •  Symbolic links  may  not  be  edited  (version  1.8.15  and
                   higher).

                •  Symbolic links along the path to be edited are not followed
                   when  the parent directory is writable by the invoking user
                   unless that user is root (version 1.8.16 and higher).

                •  Files located in a directory that is writable by the invok‐
                   ing user may not be edited unless that user is  root  (ver‐
                   sion 1.8.16 and higher).

               Users are never allowed to edit device special files.

               If  the specified file does not exist, it will be created.  Un‐
               like most commands run by sudo, the editor is run with the  in‐
               voking  user's  environment  unmodified.  If the temporary file
               becomes empty after editing, the user will be  prompted  before
               it is installed.  If, for some reason, sudo is unable to update
               a file with its edited version, the user will receive a warning
               and the edited copy will remain in a temporary file.

tldr: it makes a copy of the file-to-be-edited in a temp directory, owned by you, and then runs your $EDITOR as your normal user (so, with your normal editor config)

note that sudo also includes a similar command which is specifically for editing /etc/sudoers, called visudo 🤪

The primary purpose of those buttons is of course to let those sites track everyone’s browsing activity across every site that uses them, which does not require that anyone ever click on them.

Even if less than 0.0001% of people click them, anyone with an SEO/spammer “grindset” will assure site operators that the potential benefit of someone sharing a link they otherwise wouldn’t have is still at least theoretically non-zero. And, since there is absolutely no cost at all besides an acceptable number of extra milliseconds per pageload, really, it would be downright irresponsible not to have them there!

These articles were stolen, by the paywall operators. Elbakyan rescued them from the thieves. 🎉

encryption would prevent the modem from seeing it when someone sends it, but such a short string will inevitably appear once in a while in ciphertext too. so, it would actually make it disconnect at random times instead :)

(edit: actually at seven bytes i guess it would only occur once in every 72PB on average…)

As more data becomes available

Then we can start doing more with it

And as we do more with it

That that creates more data

Delta is the only U.S.-based mainline carrier where flight attendants, fleet service, and mechanics are not represented by a union

you could edit your post title

Have you tried https://mike-fabian.github.io/ibus-typing-booster/ ?

I have not, but I think it does what you’re looking for.

The demo video emphasizes its use as an emoji picker but it was originally created for typing Indic languages.

At first i thought, wow, cool they’re still developing that? Doing a release or two a year, i see.

I used to use it long ago, and was pretty happy with it.

fyi: GNU coreutils are licensed GPL, not AGPL.

there is so much other confusion in this thread, i can’t even 🤦

Apple makes the source code to all their core utilities available

Apple makes the source code for many open source things they distribute available, but often only long after they have shipped binaries. And many parts of their OS which they developed in-house which could also be called “core utilities” are not open source at all.

Every Linux distro uses CUPS for printing. Apple wrote that and gave it away as free software.

As others have said, it depends on the city but probably yes.

For example, in San Mateo, California, it would be an offense under title 11 of the Municipal Code:

11.12.050 EXCESSIVE ACCELERATION OF MOTOR VEHICLES.

It is unlawful for any person operating a motor vehicle within the City to so accelerate the same as to cause audible noise by tire friction on pavement or to cause the tires of said vehicle to leave skid marks upon the pavement, except when such acceleration is reasonably necessary to avoid a collision. Any person violating this section shall be guilty of a public offense.

for example, on a linux distro, we could modify the desktop environment and make it waaaaay lighter by getting rid of jpg or png icons and just using pure svg on it.

this has largely happened; if you’re on a dpkg-based distro try running this command:

dpkg -S svg | grep svg$ | sort

…and you’ll see that your distro includes thousands of SVG files :)

A ctrl-d does nothing on a non-empty line.

ctrl-d actually is flushing the buffer regardless of if the line is empty or not.

See my other comment for how you can observe it.

Note: for readers who aren’t aware, the notation ^X means hold down the ctrl key and type x (without shift).

ctrl-a though ctrl-z will send ASCII characters 1 through 26, which are called control characters (because they’re for controling things, and also because you can type them by holding down the control key).

^D is the EOF character.

$ stty -a | grep eof
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
$ man stty |grep -A1 eof |head -n2
       eof CHAR
              CHAR will send an end of file (terminate the input)

Nope, Chuck Testa: there is no EOF character. Or, one could also say there is an EOF character, but which character it is can be configured on a per-tty basis, and by default it is configured to be ^D - which (since “D” is the fourth letter of the alphabet) is ASCII character 4, which (as you can see in man ascii) is called EOT or “end of transmission”.

What that stty output means is that ^D is the character specified to trigger eof. That means this character is intercepted (by the kernel’s tty driver) and, instead of sending the character to the process reading standard input, the tty “will send an end of file (terminate the input)”.

By default eof is ^D (EOT), a control character, but it can be set to any character.

For instance: run stty eof x and now, in that terminal, “x” (by itself, without the control key) will be the EOF character and will behave exactly as ^D did before. (The rest of this comment assumes you are still in a normal default terminal where you have not done that.)

But “send an end of file” does not mean sending EOT or any other character to the reading process: as the blog post explains, it actually (counterintuitively) means flushing the buffer - meaning, causing the read syscall to return with whatever is in the buffer currently.

It is confusing that this functionality is called eof, and the stty man page description of it is even more so, given that it (really!) does actually flush the contents of the buffer to read - even if the line buffer is not empty, in which case it is not actually indicating end-of-file!

You can confirm this is happening by running cat and typing a few characters and then hitting ^D, and then typing more, and hitting ^D again. (Each time you flush the buffer, cat will immediately echo the latest characters that had been buffered, even though you have not hit enter yet.)

Or, you can pipe cat into pv and see that ^D also causes pv to receive the buffer contents prior to hitting enter.

I guess unix calls this eof because this function is most often used to flush an empty buffer, which is how you “send an end of file” to the reader.

The empty-read-means-EOF semantics are documented, among other places, in the man page for the read() syscall (man read):

RETURN VALUE
      On success, the number of bytes read is returned (zero indicates end of
      file), and the file position is advanced by this number.

If you want to send an actual ^D (EOT) character through to the process reading standard input, you can escape it using the confusingly-named lnext function, which by default is bound to the ^V control character (aka SYN, “synchronous idle”, ASCII character 22):

$ man stty|grep lnext -A1
       * lnext CHAR
              CHAR will enter the next character quoted
$ stty -a|grep lnext
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;

Try it: you can type echo " and then ctrl-V and ctrl-D and then "|xxd (and then enter) and you will see that this is sending ascii character 4.

You can also send it with echo -e '\x04'. Note that the EOT character does not terminate bash:

$ echo -e '\x04\necho see?'|xxd
00000000: 040a 6563 686f 2073 6565 3f0a            ..echo see?.
$ echo -e '\x04\necho see?'|bash
bash: line 1: $'\004': command not found
see?

As you can see, it instead interprets it as a command.

$ echo -e '#!/bin/bash\necho lmao' > ~/.local/bin/$(echo -en '\x04')
$ chmod +x ~/.local/bin/$(echo -en '\x04')
$ echo -e '\x04\necho see?'|bash
lmao
see?

sure. first, configure sudo to be passwordless, or perhaps just to stay unlocked for longer (it’s easy to find instructions for how to do that).

then, put this in your ~/.bashrc:

alias sudo='echo -n "are you sure? "; for i in $(seq 5); do echo -n "$((6 - $i)) "; sleep 1; done && echo && /usr/bin/sudo '

Now “sudo” will give you a 5 second countdown (during which you can hit ctrl-c if you change your mind) before running whatever command you ask it to.

to answer this question: if you’re on a dpkg-based system, check /var/log/dpkg.log (or /var/log/dpkg.log.2.gz to get logs from January, if your system rotates them once a month).

Nice post, but your title is misleading: the blog post is actually titled “Supply Chain Attacks on Linux distributions - Overview” - the word “attacks” as used here is a synonym for “vulnerabilities”. It is not completely clear from their title if this is going to be a post about vulnerabilities being discovered, or about them actually being exploited maliciously, but the latter is at least not strongly implied.

This lemmy post however is titled (currently, hopefully OP will retitle it after this comment) “Supply Chain Attack found in Fedora’s Pagure and openSUSE’s Open Build Service”. edit: @OP thanks for changing the title!

Adding the word “found” (and making “Attack” singular) changes the meaning: this title strongly implies that a malicious party has actually been detected performing a supply chain attack for real - which is not what this post is saying at all. (It does actually discuss some previous real-world attacks first, but it is not about finding those; the new findings in this post are vulnerabilities which were never attacked for real.)

I recommend using the original post title (minus its “Overview” suffix) or keeping your more verbose title but changing the word “Attack” to “Vulnerabilities” to make it clearer.

TLDR: These security researchers went looking for supply chain vulnerabilities, and found several bugs in two different systems. After responsibly disclosing them, they did these (very nice and accessible, btw - i recommend reading them) writeups about two of the bugs. The two they wrote up are similar in that they both involve going from being able to inject command line arguments, to being able to write to a file, to being able to execute arbitrary code (in a context which would allow attackers to perform supply chain attacks on any software distributed via the targeted infrastructure).